A design flaw found in a threat model costs a conversation. The same flaw found in a penetration test costs a sprint. Found in production, it costs an incident. That gap is the entire argument for threat modelling, and it is why the practice survives despite most organisations doing it badly.
Four questions
Strip away the frameworks and threat modelling asks four things:
- What are we building? A shared picture of the system - components, data flows, and where trust changes hands.
- What can go wrong? The threats against that design.
- What are we going to do about it? Mitigate, accept, transfer or redesign.
- Did we do a good job? Validation that the mitigations landed.
Everything else - STRIDE, attack trees, kill chains - is a technique for answering question two. Teams that get stuck usually got stuck on question one, because nobody could agree what the system actually was.
Trust boundaries are where the value is
Draw the data flow, then mark every point where data crosses from one level of trust to another: browser to server, service to service, your code to a third-party API, application to database, tenant to tenant.
Almost every serious design flaw lives on a trust boundary. If you only have time for one thing, enumerate the boundaries and ask what happens when the other side is hostile - that alone finds more than a generic checklist will.
STRIDE, briefly
A prompt list for question two: Spoofing (is it really them?), Tampering (can data be altered?), Repudiation (can they deny it?), Information disclosure (can they see what they should not?), Denial of service (can they exhaust it?), Elevation of privilege (can they become someone else?).
Run it against each boundary rather than the whole system. "Can this API be spoofed?" is answerable; "what are the threats to our platform?" is not.
Connect design decisions to your control set
GRC Copilot links identified risks to the controls that treat them and the evidence that proves they work, so design findings do not vanish into a backlog.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
When to model
- New system or major feature, at design - before the code exists and changing it is still cheap.
- Architectural change - a new integration, a new data store, a new tenant model.
- After an incident, to find the class of flaw rather than the instance.
- Not on every ticket. This is the mistake that kills programmes.
Why most programmes die
They die of ceremony. A mandatory four-hour workshop with a template, a facilitator and a formal report becomes something engineers route around within two quarters.
What survives is lightweight: a whiteboard, the four questions, the people who are actually building it, and forty minutes. Write the findings as ordinary backlog items rather than a separate document nobody re-reads. If your threat model output cannot be worked on in the same tracker as everything else, it will not be worked on.
Who should be in the room
The engineers building it - they know where the shortcuts are. Someone with security depth to prompt. Ideally someone from operations who knows how it will actually be run. Not a large audience; four or five people is plenty, and a security person facilitating rather than dictating gets far better results than one delivering a verdict.
What good output looks like
Not a report. A short list of concrete, assigned items: "authenticate service-to-service calls, currently trusted by network position", "the tenant ID comes from the request body and should come from the token", "rate-limit the password reset endpoint". Each one a ticket, each one owned.
Frequently asked questions
Do we need a tool?
No. Whiteboards and diagrams work. Tools help at scale and with reuse, but buying one before the practice exists produces diagrams nobody discusses.
How long should it take?
Under an hour for a feature; a half day for a significant new system. Anything longer and attendance quietly stops.
Does it replace penetration testing?
No - they find different things. Threat modelling finds design flaws; testing finds implementation flaws. Frameworks generally expect both.
Who owns it?
Engineering, with security facilitating. A model owned by security and imposed on engineering gets treated as an audit rather than a design activity.
Key takeaways
- Four questions; everything else is technique for answering the second.
- Enumerate trust boundaries - that is where the serious flaws live.
- Keep it under an hour and output ordinary backlog tickets.
- Engineering owns it; security facilitates rather than judges.