Invite the people who build and run the system: developers, operations or SRE, and whoever owns the feature. Add one person who knows attacker behaviour, and a reviewer who was not in the room. OWASP guidance says all stakeholders should review the model, not only security or engineering.
What a threat model needs from the room
A threat model answers four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. Each question needs a different kind of knowledge.
The builders know how data actually moves. Operations knows what breaks at three in the morning. A security person knows which attacks are common and which mitigations hold up. A product owner knows which failures would hurt the business most.
Roles at a glance
| Role | What they bring | When they matter most |
|---|---|---|
| Developer who owns the feature | True data flows, edge cases | Drawing the diagram |
| Operations or SRE | Deployment, logging, failure modes | Finding what can go wrong |
| Security voice | Threat knowledge, mitigation options | Ranking threats and choosing responses |
| Product or business owner | Impact of a failure | Ranking and accepting risk |
| Reviewer from outside the team | Fresh eyes | Checking the model at the end |
| Facilitator | Keeps time, records decisions | Throughout |
The OWASP community page says threat modeling is done by the people who build and run the application, and that developers, operations and SRE can model each story. Its sample model lists a document owner, participants and a reviewer, which is a handy shape to copy.
Keep the group small, widen the review
Four to six people is a comfortable working size in practice. More voices make the diagram slower to agree on. Instead of inviting everyone to every session, let a small group draft the model and send it to the wider set of stakeholders for review.
The OWASP Threat Modeling Cheat Sheet also notes that brainstorming lets every team member, including non-technical ones, contribute. That is useful when the group mixes engineers with support or product staff.
Avoid the hero pattern
The Threat Modeling Manifesto names the Hero Threat Modeler as an anti-pattern: relying on one person's innate ability or mindset. If a single expert runs every session, the team learns nothing and the work stops when that person is away. Rotate the facilitator, and have the security person coach rather than own the model.
A simple invitation checklist
- Name a facilitator and a note taker before the meeting.
- Invite the feature owner and one operations voice.
- Ask a security colleague to join for the threat and response steps.
- Book a reviewer for the last ten minutes or for an async read.
- Share the draft diagram first so the meeting starts at "what can go wrong".
Quick check
Do I need a security specialist in every session?
No. Guidance says developers and operations can model their own work. A security person helps with threat knowledge and mitigations, but the model should not wait for their calendar.
How many people is too many?
There is no fixed number in the sources. In practice, a working group above about six tends to stall on the diagram. Keep the drafting group small and widen the review.
A note on tooling
Threat modeling is a design activity done by people. Safeguard covers adjacent work once code exists: dependency scanning, SBOMs, reachability analysis and policy gates. You can try a free scan on a repository after the session to check the dependencies behind the components you drew.
Sources
Last reviewed: 19 October 2026.
