Guide · STRIDE · Compliance

The threat model template that gets past auditors

Someone — a SOC 2 auditor, an enterprise security questionnaire, a bank partner — just asked your team for a threat model, and nobody has written one before. This guide gives you the exact structure to use, explains what reviewers actually check, and includes a copyable template.

1. What a threat model is (and isn't)

A threat model is a structured document that answers four questions, in order: what are we building, what can go wrong, what are we doing about it, and did we do a good job?That framing comes from the Threat Modeling Manifesto and it's the skeleton every serious methodology shares.

It is nota penetration test (that's evidence of exploitability), not a vulnerability scan (that's a tool output), and not a risk register for the whole company. It's an engineering artifact about one system: its parts, its trust boundaries, and the specific ways an attacker could abuse it. Auditors ask for it because it proves your security posture is designed, not accidental.

2. STRIDE in five minutes

STRIDE, developed at Microsoft in 1999, remains the default methodology because it's a checklist your team can actually apply without a security specialist. For each component of your system, you ask whether an attacker could achieve each of six outcomes:

3. The template

Copy this structure. Every section exists because a reviewer will look for it.

# Threat Model: <system name>
Version, date, authors, review cadence (e.g. "re-review quarterly
or on major architecture change")

## 1. System overview
2-3 paragraphs: what the system does, who uses it, what data it
holds. Include or link an architecture diagram.

## 2. Components
Each deployable/trust-relevant part: frontend, API, database,
queue, third-party services (payment provider, email, LLM APIs).

## 3. Trust boundaries
Every place data crosses a privilege or ownership line:
internet -> app, app -> DB, tenant <-> tenant, you <-> vendor.

## 4. Assets
What an attacker wants: credentials, PII, payment references,
API keys, business data. Rate each: low/medium/high/critical.

## 5. Threats (the core)
For EACH threat:
  ID          T-01, T-02, ... (stable, referenceable)
  Title       one specific sentence, not "hackers attack API"
  STRIDE      S/T/R/I/D/E
  Component   which part it targets
  Scenario    concrete attack narrative an engineer can follow
  Likelihood  1-5   Impact 1-5   Risk = L x I
  Mitigations 1-3 concrete controls, each with effort estimate
              and current status (planned / in place)

## 6. Assumptions
What you took as given ("RDS encryption at rest is enabled").
Auditors read this section closely.

## 7. Out of scope
What this model deliberately excludes, and why.

4. Scoring risk honestly

Use likelihood × impact on a 1–5 scale each, giving a 1–25 risk score: 20+ is critical, 12–19 high, 6–11 medium, below 6 low. The number matters less than the honesty. A threat model where every threat scores 25 reads as fear; one where everything scores 4 reads as denial. Reviewers trust documents that contain real judgment: an unauthenticated-webhook tampering threat on a payments flow deserves a 16–20; a denial-of-service against an internal admin panel probably deserves a 6.

Rank the register by score, descending. The first page of your threat table should read like your actual nightmare list. If it doesn't, re-score.

5. What auditors actually look for

• Specificity to your system. Generic threats ("SQL injection may occur") signal a template that was filled in without thought. Threats should name your components.
• Mitigation status, not just intent. SOC 2 (CC3.2, CC6-series) and ISO 27001 (clause 6.1.2, Annex A) both frame this as risk assessment feeding treatment. Each threat needs a control that exists or a dated plan.
• Control mapping. For SOC 2, map mitigations to Trust Services Criteria (e.g. tenant isolation → CC6.1); for ISO 27001:2022, to Annex A controls (e.g. webhook signing → A.8.24, use of cryptography). This turns your threat model into audit evidence instead of an appendix.
• Recency and ownership. A threat model dated three years ago, or with no author, is worse than none — it proves the process is dead.
• An assumptions section. It shows you know where your model's edges are. Its absence is the fastest tell of an inexperienced author.

6. Five mistakes that get threat models rejected

1. Modeling the org chart, not the system. "Employees might be phished" belongs in your ISMS risk register, not the product threat model.
2. No trust boundaries. If the document never says where data crosses a privilege line, STRIDE was applied blind.
3. Mitigations without effort or status. "Implement rate limiting" forever-pending is not a control.
4. Uniform scores. See section 4 — flat scoring means no judgment was exercised.
5. Write-once documents. State a review cadence on page one, and honor it.