Threat modeling for a small team is one hour at a whiteboard: draw how data moves through your product, mark every place it crosses from one level of trust to another, and ask what an attacker on the other side of each line could do. You rank what you find by how bad it would be, not by how likely it feels, and you leave the room with three items in the backlog. Frameworks help large organisations make this repeatable; you do not need one to get most of the value.
What threat modeling is once you strip the methodology away
Search for threat modeling and you land in enterprise territory fast: formal processes, specialist tools, diagram notations, and a security architect to run it all. For an engineering lead with a team of five to twenty and no security specialist, that reads like a reason to postpone it indefinitely.
Underneath the ceremony, the idea is simple. Every system has places where it accepts input from something it does not fully control: a browser, a phone, a partner’s API, an internal user with fewer rights than an admin. Those places are your attack surface. The line between “something we control” and “something we do not” is a trust boundary. Threat modeling is the habit of finding those lines on purpose and asking, at each one, “what if the thing on the other side is hostile?”
That question is the product. Everything else in a formal threat modelling process — templates, scoring matrices, risk registers — exists to make the question get asked consistently in big organisations. In a small team, the people who built the system already know where the sharp edges are. What they lack is an hour where those edges are the only topic.
It also works as security requirements gathering for teams that never had a formal version of it. Instead of someone writing “the system must be secure” into a spec, you end up with concrete statements: “a guest session must not be able to read another table’s order”, “the POS sync must reject prices it cannot match to a known item”. Those are testable. “Secure” is not.
How to run a threat modeling session in one hour
You need the people who know the system — the lead, the engineers who own the main parts, ideally someone who knows how the product is used day to day — and a whiteboard. No template.
1. Draw the flow
Start from the user’s first action and follow the data. Boxes for the things that run (the mobile web app, the API, the database, the admin panel, the external system you integrate with), arrows for what moves between them. Keep it rough: the goal is a picture everyone agrees is roughly true. If someone says “oh, and there’s also…” halfway through, the session is working — undocumented flows are exactly where things go wrong.
2. Mark the trust boundaries
Now draw a line wherever data crosses from one level of trust to another. Typical places:
- between any client device and your backend;
- between an anonymous user and an authenticated one;
- between one internal role and another (a waiter and a manager are not the same person);
- between your system and any third-party system;
- between your backend and anything that runs code or stores data you do not own.
Each arrow that crosses a line is a question you are going to ask.
3. Name the worst case at each crossing
For every crossing, ask: “if whoever sits on the other side of this line wanted to cause harm, what is the worst thing they could do through this arrow?” Write the answer as an abuse case — a short sentence in the shape of a user story, but from the attacker’s side. “As a guest, I change the table ID in the request and see another table’s bill.” “As a staff member, I export the whole guest list.”
If the room goes quiet, this is where STRIDE helps as a prompt. The acronym stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. Read the six words out at a crossing and see which triggers an idea — a prompt, not a form to fill.
4. Rank by consequence, not probability
Small teams are good at talking themselves out of risks: “nobody would bother”. Probability estimates in a one-hour session are guesses dressed up as analysis; consequence is easier to agree on. Would it leak personal data? Let someone pay less, or not at all? Stop the business from operating? Corrupt data in a system you cannot roll back?
Sort the abuse cases by how bad the outcome would be. The top of that list is what you act on.
5. Write three actions into the backlog
Before anyone leaves, pick the three highest-consequence items and turn each into a ticket with an owner. Each ticket describes a mitigation — a check, a constraint, a test, a log — not a vague intent. “Validate that every order request belongs to the session’s table, with a test that tries a foreign table ID” is a ticket. “Look into authorisation” is not.
Three is deliberate: small enough to actually ship soon, and it forces the team to choose. The rest stays in the notes for next time.
Example from our practice: three trust boundaries in one product
MyRest is a hospitality platform for restaurants, built for myREST Sp. z o.o., a Polish company working since 2023. It has a guest side that runs on QR codes and an admin panel for staff, with guest profiles, a stop list for dishes that have run out, and analytics on top-selling items and peak hours. One requirement shaped the whole architecture: it had to work with the restaurant’s existing POS system, with no new hardware.
It is a good teaching example because its trust boundaries are visible without any training. Draw it on a whiteboard and three lines appear almost immediately.
Boundary 1: the guest’s phone. A guest scans a QR code with their own device. That could be anyone, on any device, free to edit requests — so everything from this side is untrusted. The questions at this crossing: can a guest act on a table or order that is not theirs by changing an identifier? Can they change a price or a total before it reaches the backend? Can they flood the system with orders? Can a QR code be swapped or reused somewhere it was not meant to be?
Boundary 2: the staff in the admin panel. Known people, but with different jobs and rights. The panel holds guest profiles and analytics and controls the stop list guests see. The questions: can one role see or do more than its job requires? Who can export guest data? If a staff account is compromised, what is the blast radius? Can someone mark items as unavailable, or change them, without a trace of who did it? This is where the advice from our hospitality security baseline on separating staff, manager and admin roles from day one becomes concrete.
Boundary 3: the POS system. This one is easy to miss because it does not feel like an attacker. But it is a system we do not control and cannot change, at the centre of the restaurant’s money flow. Data coming from it — item IDs, prices, availability — crosses a trust boundary just like guest input does. The questions: what happens if it sends something unexpected or malformed? What if it is slow or unavailable at peak hours? What if an order goes in and the POS answers “OK” but never actually processes it? Our article on POS and kitchen integration makes the same point from the operations side: a 200 OK from the POS doesn’t tell you the order actually reached the kitchen.
Three boundaries, three very different sets of abuse cases: one anonymous and hostile by default, one trusted but with uneven rights, one automated and outside your control. Most products that connect customers, staff and a legacy system have this shape. Integrations of the third kind are the core of our API integration services, and they are where an unasked “what if” tends to cost the most later.
What to watch out for
The document that nobody opens
The most common way threat modeling fails is a good session whose output lives in a document nobody opens again, while the risks in it stay exactly as open as they were. If the result is not in the security backlog, next to the feature work, with owners and estimates, it did not happen. Treat the session notes as a source for future tickets, not as the deliverable.
Turning it into a methodology anyway
Some teams overcorrect: they adopt a full framework, every feature needs a model, and the process becomes the thing people avoid. The value is the question at each boundary, not completeness.
Modeling the system you wish you had
Draw what is deployed, including the cron job someone added in a hurry and the admin shortcut that was supposed to be temporary. Modeling an idealised architecture misses the problems you actually have.
Treating it as a replacement for design decisions
A session finds risks at boundaries. It does not decide what data you should never collect or where secrets live — those are cheaper to settle earlier. Our piece on the security decisions that cost nothing before the first release covers that side; the two practices work best together.
When to run it again
You do not need a calendar reminder. Repeat the session when the trust map changes: when you add a new integration (a payment provider, a new POS, a partner API), or when you add a new type of user (a new staff role, a partner portal, a public API for third parties). Both create new boundaries, where old assumptions stop holding. A redesign of authentication is also a good trigger; routine feature work inside existing boundaries usually is not.
Conclusion
Threat modeling does not need a framework, a specialist, or a week. It needs one hour, the people who built the system, and a whiteboard where every trust boundary is drawn and questioned. Rank what you find by consequence, put three concrete mitigations into the backlog, and come back when you add an integration or a new kind of user. If you want a second pair of eyes on the boundaries you have drawn — or on the ones you might have missed — that is part of our QA and security audit work.
