A first threat modeling workshop usually fails in one of two ways, and both are avoidable. Either it is scoped so broadly — "let's threat model the platform" — that ninety minutes produce a list of generic anxieties nobody can act on, or it turns into an architecture review, where the room spends an hour re-litigating a design decision from last quarter and never gets to a single threat. The difference between a session that produces owned, tracked work and one that produces a photo of a whiteboard is almost entirely decided before anyone walks in: how narrowly you scoped it, whether the diagram already exists, and whether the room knows what it is being asked to do.
This is a playbook for that first session specifically. It assumes nobody in the room has done this before, that you have ninety minutes and will not get a second booking if the first one goes badly, and that your goal is not a perfect threat model but a real one — a short list of concrete threats, each ranked, each with a name and a date attached. Get that, and the second workshop books itself.
The short version: Scope to one feature you can draw on a single screen. Draw the data flow diagram before the meeting, not during it. Invite five to seven people, including someone who built the thing and someone who operates it. Spend the session sweeping each diagram element with STRIDE. Leave with every high-ranked threat scored, owned, and written into the risk register — not with a promise to write it up later.
Prepare before anyone walks in
The single highest-leverage decision is scope, and the instinct of a first-time facilitator is almost always to scope too wide. Pick one feature, one service, or one flow — "password reset," "the customer data export," "the payment webhook" — small enough that the diagram fits on one screen without scrolling, and write down explicitly what is out of scope. That second half matters as much as the first: an unwritten boundary is one the room will drift across within twenty minutes, usually toward whichever adjacent system somebody in the room already dislikes. Being able to say "that's outside today's scope, into the parking lot" without it feeling arbitrary depends on having said so in advance.
Then draw the diagram yourself, ahead of time, and get it roughly right rather than perfectly right. Drawing a DFD from scratch in a room of seven people is slow, and the first twenty minutes of a session are the ones you can least afford to lose. A diagram that is 80% correct is better preparation than a blank canvas, because correcting something concrete is fast and social, while producing something from nothing in front of an audience is neither. Mark the trust boundaries as best you understand them and expect to be corrected — being wrong about a boundary is one of the most productive things that can happen early in the session, since it means the room has just discovered that two people held different beliefs about where data crosses from trusted to untrusted.
Decide the framework in advance too, and tell people what it is. For a first workshop, use STRIDE. It has six categories, they map cleanly onto diagram elements, and a room can learn it in five minutes — which matters more than whether it is the theoretically best fit, because a framework nobody in the room has internalised will consume the session. PASTA and LINDDUN are both excellent and neither belongs in a first session. Finally, spend ten minutes naming two or three plausible threat actors for this feature — an unauthenticated internet user, a logged-in customer probing another tenant's data, a contractor with database read access. Threats generated without an actor in mind drift toward the theatrical; threats generated against a named actor stay grounded in what that actor can actually reach.
Who should be in the room
Five to seven people is the working range. Below four you lose the perspective that makes threat modeling work — the whole method depends on someone knowing a thing the others do not. Above eight, people stop contributing and start attending, and the session slows to the pace of the most talkative participant.
| Role | What they bring | What you lose without them |
|---|---|---|
| Someone who built it | How the code actually works, including the parts that never made it into the design doc. | You threat model the intended system rather than the real one. |
| Someone who operates it | What breaks in production, what has access to what, which alerts nobody reads. | Every threat gets rated as if monitoring and response work perfectly. |
| Product or business owner | What the data is actually worth and which failures are genuinely unacceptable. | Impact ratings become engineering guesses, and nothing gets prioritised credibly. |
| A facilitator | Timekeeping, the STRIDE prompts, and the authority to park a tangent. | The session becomes an architecture review roughly twenty minutes in. |
| A security specialist, if you have one | Attack patterns the team has not seen, and realistic difficulty estimates. | Not fatal — a well-run session without one still beats no session. |
One structural note: the facilitator should not also be the main subject-matter expert. Running the clock, working through the prompts, and capturing threats verbatim is a full job, and the moment the facilitator starts defending a design choice they stop facilitating. If you are the only security person on the team and also the person who knows the system best, hand the clock and the note-taking to someone else for the day.
A ninety-minute agenda
| Time | Segment | Output |
|---|---|---|
| 0–10 | Frame the session: scope, what is out of scope, the six STRIDE categories, and the two or three threat actors. | A room that knows what question it is answering. |
| 10–25 | Walk the diagram. The builder narrates one request end to end; everyone corrects the drawing as it goes. | An agreed diagram, with trust boundaries where they really are. |
| 25–65 | The STRIDE sweep, element by element. This is the session; protect the time. | A raw list of threats, unfiltered and unranked. |
| 65–80 | Rank. Merge duplicates, drop the ones the room agrees are not credible, score the rest. | An ordered list with a clear top handful. |
| 80–90 | Assign. Every top threat gets a named owner and a date. Read the list back aloud. | Register entries, not intentions. |
Forty minutes for the sweep sounds generous until you try it. With six or seven diagram elements it works out to under six minutes each, which is the right pressure: enough to find the obvious threats against an element, not enough to design the fix. If you are running behind at minute 65, stop the sweep anyway. An unranked list of thirty threats is worth less than a ranked list of twelve, because nothing in an unranked list can be assigned, and anything unassigned at minute 90 will still be unassigned next quarter.
Running the sweep
The mechanic is simple and deliberately repetitive: take one element of the diagram, then ask the six STRIDE questions against it. Can something pretend to be this? Can its data be changed in transit or at rest? Could someone do something here and later deny it? What can leak? What happens when it is flooded or made unavailable? Can someone here end up with more privilege than they should have? Then move to the next element and do it again.
Some categories will be nonsense for some elements, and saying "not applicable, next" quickly is a skill worth modelling early. What makes the sweep productive is that it is mechanical — nobody has to be clever or arrive with a security background, because the prompt does the work. Start with the elements that touch a trust boundary. That is where the majority of real findings live, and it means that if you run out of time, the part you skipped is the part least likely to have mattered.
Capture threats in the form "[actor] can [action] because [weakness], resulting in [impact]". It is a slightly pedantic format and it is worth insisting on, because it forces the room to name a mechanism rather than a mood. "Session handling is weak" is not a threat and cannot be assigned to anyone; "a logged-in customer can replay a captured session token because tokens do not expire on logout, exposing another tenant's export files" is a threat, and it more or less contains its own fix. Write it in whatever the room can see live — the shared document, the tool, the projected screen — because threats captured in one person's private notes are the ones that get quietly reworded into vagueness afterwards.
Facilitation rules that keep it on the rails
- No solutioning during the sweep. The instant someone proposes a fix, five minutes evaporate into implementation debate. Write the fix idea next to the threat and move on — you are not throwing it away, you are deferring it.
- Park the architecture debate. "We should never have built it this way" is sometimes true and never useful in the next eighty minutes. Parking lot, revisit at the end if time allows.
- No blame, ever, including implied. The person who wrote the flawed code is usually the person who can find three more flaws like it, and they will stop talking the moment the session starts feeling like an audit.
- Write threats down verbatim. Do not summarise in the moment. Compression is the facilitator's job afterwards, and doing it live loses exactly the specifics that make a threat actionable.
- Timebox each element out loud. "Five minutes on the export service" changes the room's behaviour more reliably than any amount of gentle steering.
- Deliberately ask the quiet people. The operations engineer who has said nothing for forty minutes is frequently the one who knows the credential is shared across three environments.
Rank and assign before anyone leaves
Ranking in the room, however roughly, is what turns a list into a plan. A simple high/medium/low on likelihood and impact is enough for a first session — CVSS is built for vulnerabilities in a generic context rather than threats in yours, and reaching for it in minute 70 will cost you the assignment step. What you actually need is enough separation to identify the top handful, plus the room's agreement that those are in fact the top handful.
Then assign. Every threat above your cut line gets a named individual and a date, spoken aloud and confirmed by that person while everyone is still present. This is the step first-time facilitators most often skip, usually because time is short and it feels like something that can be tidied up afterwards over email. It cannot. An unowned threat has no mechanism by which it ever becomes work. The output of the workshop is not the threat list — it is the set of risk register rows, each with an owner, a score, and a next action, which is also what makes the session legible to an auditor or an exec who was not in the room.
Done looks like: a corrected diagram everyone agrees with; a written threat list in actor-action-weakness-impact form; a ranking with a visible cut line; a named owner and date on every threat above it; and a decision about when the next session happens. If you have all five at minute 90, the workshop worked — even if the list is short.
Where first workshops go wrong
- Scope too broad. "The whole platform" yields generic threats. One feature yields specific ones, and specific ones get fixed.
- Drawing the diagram live. Burns the session's best twenty minutes on something you could have done alone the day before.
- Nobody from operations. The room over-credits controls that only work on paper, and every likelihood rating drifts optimistic.
- The list is the deliverable. A list with no owners is a record of a conversation. Owners and dates are the deliverable.
- Treating it as one-and-done. A threat model reflects the system on the day it was made; the system changes weekly and the model does not follow on its own.
- Chasing exhaustiveness. A first session that finds the eight most obvious threats and fixes three of them has done more for the system than one that generated forty and closed none.
Turning one workshop into a habit
The strongest signal that the first session worked is that a second one gets scheduled without anyone having to campaign for it, which in practice means the threats found in the first session became visible work — tickets in the same backlog as everything else, not a separate security document nobody opens. Once that has happened, tie subsequent sessions to triggers rather than to the calendar: a new external integration, a new data store holding customer data, a new trust boundary, a change in who can reach what. Those are the moments the model actually goes stale, and they are far better prompts than a recurring quarterly invite that gets declined twice and then quietly disappears.
It is also worth revisiting the diagram itself at the start of every subsequent session, briefly. Systems accumulate attack surface without anybody deciding they should, and the two-minute "what's changed since last time" question at the top of a follow-up session routinely surfaces a new flow that nobody thought to mention. For the highest-value threats, the ones you keep coming back to, promoting them into an attack tree is the natural next step: the workshop tells you what an attacker might want, and the tree tells you how many independent things have to fail before they get it.
Regulated environments add structure to all of this — who must attend, what evidence the session has to produce, and how often it has to happen. See threat modeling by industry for how the workshop output maps onto specific regimes, or start from the pre-labelled DFD and risk register in the free threat modeling templates if you would rather not prepare the diagram from an empty canvas.