How to Run a Threat Modeling Session: The 90-Minute Meeting That Actually Works
Threat modeling has a reputation problem. It is either the two-day workshop that produces a 40-page document nobody reads, or the informal 'let's think about security' conversation that produces nothing. Neither scales.
The version that works is a 90-minute meeting for one feature or service at a time, with a specific attendee list, a live-drawn data flow diagram, six questions applied to each component, and an output that goes directly into the sprint backlog.
This guide is the repeatable playbook: the calendar invite template, who needs to be in the room, how to facilitate the DFD drawing in real time, the exact STRIDE questions to ask, how to prioritize what you find, and how to turn findings into tickets that engineers will actually close.
When to Run a Threat Model (and When Not To)
Run a threat model for:
- Any new feature that handles authentication, authorization, or sensitive data
- Any significant architectural change (new service, new data store, new external integration)
- Any feature that accepts external user input and processes it server-side
- Any feature involving payment, PII, health data, or credentials
- Pre-launch review of a new product or major release
Skip the formal threat model for:
- Pure UI changes with no backend logic changes
- Bug fixes that do not change data flow or trust boundaries
- Internal tooling with no access to sensitive data
- Changes already covered by a recent (last 6 months) threat model for the same component
The trigger: Build threat modeling into your SDLC as a ticket type. When an engineer creates an epic or design doc for a new feature, a threat model task is automatically added to the definition of done. The security team is not the gatekeeper -- the engineering team runs the meeting and the security engineer participates as a facilitator and subject matter expert, not as an approver.
The Calendar Invite: Who to Include and What to Send
Required attendees:
- The engineer or tech lead who designed the feature (they know the actual data flow)
- The product manager (they know the business logic and edge cases)
- One security engineer (facilitator)
Optional but valuable:
- A second engineer from the team (catches gaps in the tech lead's description)
- A QA engineer (good at finding edge cases)
- A representative from the team that will own the system in production (ops, SRE)
Maximum attendees: 6. More than 6 and the meeting becomes a performance rather than a working session.
Pre-meeting email template:
Subject: Threat Model — [Feature Name] — [Date] 90 min
Hi all,
We are threat modeling [feature name] before it ships.
This is a 90-minute working session, not a presentation.
Before the meeting, please:
1. Read the design doc or PRD: [link]
2. Be ready to walk through the data flow out loud
(no slides needed -- we will draw it together)
We will produce:
- A data flow diagram
- A list of threats, each with a severity and owner
- Jira tickets for anything above 'informational'
Location: [room / Zoom link]
Facilitator: [security engineer name]
What to prepare as facilitator:
- A blank Miro, Lucidchart, FigJam, or whiteboard
- The STRIDE threat table template (see below)
- Read the design doc before the meeting -- you should understand the feature well enough to ask good questions, not well enough to explain it
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The 90-Minute Session Structure
Minutes 0 to 15: Draw the data flow diagram
Do not start with threats. Start with the system.
Ask the tech lead: 'Walk me through what happens when a user does [the core action of this feature].'
As they talk, draw. Use four symbol types:
- Rectangle: External entities (user browser, mobile app, third-party service, another team's API)
- Circle or rounded rectangle: Processes (your application code, your service, a Lambda function)
- Parallel lines: Data stores (database, S3 bucket, Redis cache, message queue)
- Arrow: Data flows (label each arrow with what data moves and in which direction)
- Dashed box: Trust boundaries (where data crosses from one trust level to another -- internet to your server, your server to the database, user-controlled to server-controlled)
The trust boundaries are the most important thing to draw correctly. Every arrow that crosses a trust boundary is a candidate for a threat.
Common DFD for a typical SaaS feature:
[Browser] ---(HTTPS: login request + credentials)---> [Auth Service]
[Auth Service] ---(SQL: user lookup)---> [Users DB]
[Auth Service] ---(JWT token)---> [Browser]
[Browser] ---(HTTPS + JWT: API request)---> [API Service]
[API Service] ---(SQL: data query)---> [App DB]
[API Service] ---(JSON response)---> [Browser]
Trust boundaries: internet/browser to your services; your services to the databases.
Minutes 15 to 65: STRIDE analysis
For each arrow and each component on the diagram, ask the six STRIDE questions. Do not try to ask all six for everything -- focus on the arrows crossing trust boundaries and the data stores.
| Threat | The question to ask | Example |
|---|---|---|
| Spoofing | Can an attacker pretend to be someone they are not? | Can someone replay a stolen JWT token? |
| Tampering | Can an attacker modify data in transit or at rest? | Can a user modify the API request to change someone else's order ID? |
| Repudiation | Can an attacker deny they did something? | If an admin deletes a record, is there an audit trail? |
| Information disclosure | Can an attacker read data they should not? | Does the error message expose a stack trace with internal paths? |
| Denial of service | Can an attacker make the service unavailable? | Is there rate limiting on the login endpoint? |
| Elevation of privilege | Can an attacker gain more access than intended? | Can a regular user access admin-only API endpoints? |
For each threat you identify, record it immediately in the threat table. Do not evaluate severity during the meeting -- just capture. Evaluation comes at the end.
Minutes 65 to 80: Prioritization
For each identified threat, assign:
- Severity: High / Medium / Low
- Likelihood: High / Medium / Low
- Priority: High x High = P1, High x Medium = P2, everything else = P3 or informational
Use DREAD or a simple 2x2 matrix. Do not spend more than 2 minutes per threat on prioritization -- the goal is a rough sort, not a precise calculation.
Minutes 80 to 90: Ticket creation
For every P1 and P2 threat, create a Jira ticket before the meeting ends. Assign it to the engineer who owns the affected component. The ticket needs three things:
- What the threat is (one sentence)
- What the impact would be if exploited
- A proposed mitigation direction (does not need to be the final solution)
Do not leave the meeting without tickets. A threat model that produces a document but no tickets produces zero security improvement.
Draw before you analyze
Spend the first 15 minutes drawing the DFD together -- analysis without a shared diagram produces abstract threats nobody owns
Focus on trust boundary crossings
Every arrow that crosses from one trust zone to another is a candidate threat -- these are where the most real attacks occur
Capture first, evaluate after
Write down every threat as it is mentioned; evaluate severity as a batch at the end, not one at a time as you go
Create tickets before leaving
A threat model that ends without Jira tickets produces no security improvement; P1 and P2 tickets must be created in the session
Assign owners in the room
Every ticket gets an owner before the meeting ends -- 'team' is not an owner
The Threat Table Template (Copy This)
Use this table structure during the session. Fill it in a shared Google Doc, Confluence page, or Notion so everyone can see it in real time.
| ID | Component / Data Flow | STRIDE Category | Threat Description | Impact | Likelihood | Priority | Owner | Ticket |
|----|----------------------|-----------------|-------------------|--------|------------|----------|-------|--------|
| T1 | Login endpoint | Spoofing | Stolen session tokens can be replayed -- no token expiry or revocation | High | Medium | P2 | Backend | JIRA-1234 |
| T2 | Auth -> Users DB | Information disclosure | SQL error messages returned to client expose table structure | Medium | High | P2 | Backend | JIRA-1235 |
| T3 | API endpoint | Tampering | BOLA: user can modify `userId` param to access other users' data | High | High | P1 | Backend | JIRA-1236 |
| T4 | Login endpoint | Denial of service | No rate limiting on login -- brute force possible | Medium | High | P2 | Infra | JIRA-1237 |
| T5 | App DB | Information disclosure | DB backup stored in same S3 bucket as app assets -- no access separation | High | Low | P2 | Infra | JIRA-1238 |
Standard mitigations by STRIDE category (to reference during the session):
| STRIDE | Common mitigations |
|---|---|
| Spoofing | Strong authentication, JWT expiry and rotation, session invalidation on logout, PKCE for OAuth |
| Tampering | Input validation, parameterized queries, HMAC for data integrity, signed JWTs |
| Repudiation | Immutable audit logs, write-once log destinations, log all security-relevant events with user identity |
| Information disclosure | Encrypt at rest and in transit, sanitize error messages, minimize data in API responses, least-privilege DB access |
| Denial of service | Rate limiting, request size limits, connection timeouts, circuit breakers |
| Elevation of privilege | Enforce authorization on every endpoint (not just the UI), RBAC, test every API call with lower-privilege credentials |
Scaling Threat Modeling Across a Team
A single security engineer cannot run threat models for every feature at a company growing faster than one feature a week. The solution is to train engineers to run the sessions themselves.
The security champion model:
Identify one engineer per team who is interested in security (not necessarily an expert). Train them to:
- Recognize when a feature needs a threat model (the trigger criteria above)
- Facilitate the DFD drawing session
- Ask the STRIDE questions
- Fill in the threat table
- Escalate any P1 findings to the security team for review
The security engineer reviews the completed threat table asynchronously, not in the meeting. This shifts the ratio from 'one security engineer required per meeting' to 'one security engineer reviews ten meetings per week.'
Lightweight threat modeling for smaller changes:
For minor features that do not warrant a 90-minute session, use a three-question async review in the design doc:
Security self-review (complete before marking design doc as ready for review):
1. What sensitive data does this feature handle?
(Credentials, PII, payment data, health data, access tokens)
2. What are the two most plausible ways an attacker could abuse this feature?
(Think about: spoofing users, accessing other users' data, bypassing rate limits,
injecting malicious input, escalating privileges)
3. How does this feature mitigate each of those attack paths?
(Note: 'we will add it later' is not a mitigation)
If the engineer cannot answer question 3, the design is not ready for implementation review.
Storing and referencing past threat models:
Store all threat model outputs (DFD + threat table) in your engineering wiki, linked from the design doc. When similar features are built later, the prior threat model is a starting point. Over time, you build a pattern library of threats for your specific architecture -- new engineers learn the security model of the system by reading prior threat models.
The bottom line
The threat model that works is not a compliance exercise. It is a 90-minute conversation where engineers learn to think like attackers about the thing they built. The DFD is the forcing function: you cannot draw the data flow without understanding the trust boundaries, and once the trust boundaries are visible, the threats are obvious. The meeting produces tickets. The tickets get fixed. That is the entire model.
Frequently asked questions
Do I need specialized tools to run a threat model?
No. A whiteboard or a shared Miro/FigJam board is sufficient. Microsoft Threat Modeling Tool and OWASP Threat Dragon are purpose-built tools that enforce DFD notation and generate STRIDE threats automatically, but they add process overhead that often discourages adoption. Start with a blank whiteboard and the threat table template above. Switch to dedicated tools once the process is established and the team is running sessions independently.
How is STRIDE different from a security code review?
Threat modeling happens at design time -- before code is written -- and focuses on the architecture and data flows rather than the implementation. It asks 'what can go wrong with this design?' rather than 'what bugs are in this code?' A security code review happens at implementation time and looks for specific vulnerabilities in the code itself. They are complementary: threat modeling finds design flaws that code review misses (BOLA, missing rate limiting, wrong trust model), and code review finds implementation bugs that threat modeling does not see (specific injection vulnerabilities, memory safety issues).
How long should a threat model document be?
The DFD plus the threat table. Two to four pages maximum. A threat model that grows beyond that is covering scope that should be broken into multiple sessions. Long documents are not read; a two-page threat table linked from the design doc will be referenced by every engineer who works on that system afterward.
What do I do with Low priority findings?
Log them in the threat table and do not create tickets. Review the accumulated list of Low findings quarterly -- if a pattern emerges (the same type of Low finding keeps appearing across multiple features), it indicates a systemic gap worth addressing. Individual Low findings rarely warrant sprint priority; systemic patterns do.
How often should a threat model be updated?
Revisit the threat model whenever the architecture changes significantly: new external integrations, new data stores, changes to authentication or authorization, or changes to trust boundaries. A threat model for a feature that has not changed in 12 months does not need updating. A threat model for a feature that gained a new API integration last quarter should be reviewed against that change.
What is the most common mistake in threat modeling sessions?
Starting with threats instead of the data flow diagram. When you skip the DFD and jump directly to STRIDE questions, you get abstract generic threats ('an attacker could inject SQL') rather than specific, actionable ones ('the search parameter on the /api/orders endpoint is concatenated into a query without parameterization'). The DFD is what makes threats specific enough to assign to an owner and fix.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.