Who should be in the room for a threat modeling session, and why each?
answer
- the room decides what you can find
- design intent plus implementation reality
- who operates it, not only who drew it
- someone who knows which flows carry value
- four to seven, not twenty
basics
~20 sA threat modeling session needs whoever knows the design and whoever knows reality: the architect or tech lead, the developers building it, an ops or SRE voice, and a product owner who knows which flows carry value.
solid answer
~50 sThe room should hold four kinds of knowledge. The architect or tech lead explains what the design is meant to do. The developers building it know what the code actually does, including the shortcuts. Ops or SRE know how it runs in production - the interlocks, the manual overrides, the support access paths that never appear on a design document. Product knows which flows carry value, so the room can tell an annoying threat from an expensive one; on a subscription-billing rewrite the product manager may be the only person who knows which calls move money. Someone facilitates, and that person need not be from security. Keep it small - four to seven people - because a room of twenty produces discussion, not findings. The failure to watch for is a session held inside the security team alone, which models the design as documented rather than the system as it exists.
go deeper
Be ready to name the roles and give one reason each: architect for design intent, developers for what the code really does, ops for how it runs, product for what the damage would cost. Say that you would rather have a small room than a full one.
Explain what each role contributes that the others cannot, and why a security-only room models the documentation instead of the system. Have an answer for the size question and for who facilitates.
Show that you treat the invite list as a decision you make days in advance, and that you have a policy for a missing key participant: move the session, or run it and label the unexamined area with an owner and a follow-up rather than pretending the gap is not there.
Own the organisational version: which teams can staff a session without you, how you avoid rooms so senior that engineers stop volunteering the awkward truth, and when to split one large system into several scoped sessions instead of assembling an unworkable twenty-person meeting.
## Why the attendee list is the decision that decides the session A threat modeling session finds threats that someone in the room has enough knowledge to imagine. Everything else about facilitation - the agenda, the clock, the notes - only shapes how efficiently that knowledge is drained. So the invite list is the highest-leverage decision the facilitator makes, and it is made days before the session starts. ## The four kinds of knowledge to get into the room **Design intent.** The architect or tech lead can say what the system is supposed to do, which components are new, and what assumptions the design rests on. Without them the room argues about what the picture means instead of what could go wrong with it. **Implementation reality.** The developers who are writing or will write the code know the difference between the design and the thing. They know that the internal call is unauthenticated because it was easier, that the retry path writes to a second store, that an admin script exists. Excluding implementers to save their time is the most common way to produce a model of a system that does not exist. **Operational reality.** Ops, SRE or platform engineers know how the system behaves once deployed: the break-glass access, the shared credential in the runbook, the batch job nobody owns, the physical or process interlocks. Consider a hospital pharmacy integration with a dispensing robot. The design document shows an order service calling a device gateway. The one ops engineer who understands the dosing interlocks - what the robot refuses to do, and which of those refusals are enforced in software the team controls - was not invited, so the session never asks what happens when a malformed or replayed order reaches the device, and the asset actually at stake, the safety of a physical process, is never modeled at all. Whoever runs it belongs in the room. **Business value.** A product owner or product manager tells the room which flows matter and what a bad outcome costs. This is what turns a flat list of technical possibilities into something rankable. On a subscription-billing rewrite, the product manager may be the only person who can say which of six endpoints actually moves money, which refunds are irreversible, and which report is the one finance reconciles against. ## Who facilitates, and who does not need to be there A facilitator runs the session; a scribe (sometimes the same person) captures. Neither role requires a security title, and mature programmes deliberately hand facilitation to the delivery team. Security expertise in the room is valuable but it is not the qualifying condition - a session run by a team on its own design is far better than a session that never happens because no security engineer was free. People who usually should not be there: large stakeholder audiences, managers attending for visibility, and anyone whose presence makes engineers reluctant to admit what the code really does. Psychological safety is functional here, not decorative - the value of the session comes from people volunteering the embarrassing detail. ## Size and the practical shape Roughly four to seven participants is the workable range. Below that you lose a perspective; above it, air time per person collapses and the session becomes a presentation. If a system genuinely spans many teams, run several sessions scoped to parts of it rather than one session with twenty attendees. ## When a key person cannot come Do not silently proceed as if the gap does not exist. Two honest options: move the session, or run it and explicitly record the areas that could not be examined - for example, mark the device-interlock flows as unexamined, with a named person and a short follow-up booked. A model with a labelled hole is useful; a model that quietly omits the riskiest subsystem is worse than none, because it creates confidence that was never earned. ## What interviewers are listening for They want to hear that you treat the invite list as a design decision with named roles and reasons, that you include the people who operate and who own the business outcome rather than only architects, that you keep the room small, and that you have a stated policy for the case where the one person who knows the dangerous part is missing.
- The one ops engineer who understands a dispensing robot's dosing interlocks cannot attend. Do you run the session anyway?Either move it or run it with the gap made explicit. If you run it, model everything else, then record the interlock flows as unexamined with that engineer named as owner and a short follow-up booked. What you must not do is produce a model that silently omits the most dangerous subsystem, because the team will read the absence of threats there as evidence there are none.
- Why does a product owner belong in a technical threat modeling session?Because impact is a business fact, not a technical one. Engineers can enumerate what is possible; product says which flows move money, which actions are irreversible, and which data would be genuinely damaging to expose. Without that, everything on the list looks equally severe, and the team spends its sprint on the cheapest threat to fix rather than the one that matters.
- Does the facilitator have to come from the security team?No. Facilitation is a running-the-room skill: asking questions, keeping the clock, capturing decisions. A trained tech lead facilitating their own team's design will usually outperform a security engineer who sees the system for the first time that morning, and it scales - security cannot attend every session. Security's leverage is training facilitators and reviewing the highest-risk models afterwards.
saying these in an interview costs you the question
- Says the security team runs the session by itself
- Invites architects only, no implementers
- Leaves ops out because it is not deployed yet
- Excludes product as too non-technical
- Fills the room with twenty stakeholders and observers
- Proceeds silently when the key subsystem owner is absent