Most threat modelling sessions end with a whiteboard photo and a list of concerns that nobody owns, so the same design flaws reappear at the next release. This template is the artefact that turns a session into a record: a system description, assumptions, a data flow inventory with trust boundaries, a STRIDE threat table, a mitigation tracker with owners and dates, and sign-off. It follows the four questions from the Threat Modeling Manifesto and the document structure OWASP describes (subject, assumptions, threats, mitigations, validation). It is for application security engineers, architects and development leads who need a reusable document for a new service, a major change or a periodic review. The method itself, including how to run the session, is in the Threat Modelling Guide.
How to use this template
- Copy one document per system or major change. Keep it in the same repository or wiki space as the design documents, with access limited to people who need it: a threat model is a map of your weaknesses.
- Replace every placeholder in square brackets, such as [System name] and [Owner]. Delete guidance notes in italics once completed.
- Fill sections 2 to 4 before the session (description, assumptions, data flows). The session itself fills sections 5 and 6.
- Use the IDs consistently: elements E-nn, data flows DF-nn, trust boundaries TB-nn, threats T-nn, mitigations M-nn, assumptions A-nn. Every threat must reference at least one element or flow, and every mitigation at least one threat.
- Track mitigations in your backlog and link the ticket IDs in section 6, so the document shows live status rather than intentions.
- Revisit the document when any trigger in section 8 occurs. The Manifesto's point applies: the model is refined over time, not delivered once.
1. Purpose and scope
| Field | Entry |
|---|---|
| System name and version | [System name] [v1.4] |
| Document ID and version | [TM-2026-014] v[1.0] |
| Business owner | [Name, role] |
| Technical owner | [Name, role] |
| Threat model facilitator | [Name, AppSec] |
| Participants | [Developers, architect, operations, product, privacy where personal data is processed] |
| Scope of this model | [Whole system / feature X / change CR-123] |
| Explicitly out of scope | [e.g. corporate IdP, covered by TM-2025-003] |
| Data classification handled | [Public / Internal / Confidential / Restricted] |
| Regulatory drivers | [e.g. GDPR personal data, PCI DSS cardholder data, none] |
| Date of session and next review | [2026-11-08] / [2027-05-08] |
Guidance: a narrow scope done well beats a whole-platform model that never finishes. Model a feature or a change when the system is large, and reference earlier models for shared components.
2. System description
Answer "What are we working on?" in plain language that a new team member could follow.
- Purpose: [What the system does and for whom, in two or three sentences.]
- Users and actors: [Customer, administrator, support agent, partner system, scheduled job.]
- Architecture summary: [Front end, APIs, services, data stores, queues, third-party services, hosting platform and region.]
- Authentication and authorisation: [How users sign in, how services authenticate to each other (mTLS, workload identity, API keys, OAuth client credentials), where authorisation decisions are made.]
- Non-human identities: [Service accounts, API keys, tokens, CI/CD credentials and where their secrets are stored.]
- Key assets: [Customer records, payment tokens, signing keys, admin functions, availability of the checkout path.]
- Diagram reference: [Link to the data flow diagram, version and date.]
3. Assumptions and dependencies
OWASP describes assumptions as statements to be checked or challenged as the threat landscape changes. Record them so they can be tested later.
| ID | Assumption | Why it matters | How it will be validated | Owner |
|---|---|---|---|---|
| A-01 | [The cloud platform's network isolation between tenants holds] | [Underpins TB-01] | [Provider attestation reviewed annually] | [Name] |
| A-02 | [All internal service calls go through the service mesh with mTLS] | [Spoofing threats on DF-04 to DF-09 rely on it] | [Mesh policy in strict mode, checked in pipeline] | [Name] |
| A-03 | [Administrators use phishing-resistant MFA] | [Reduces likelihood on T-03] | [Conditional access report] | [Name] |
4. Data flow inventory and trust boundaries
Model the system as a data flow diagram using the four element types in the OWASP Threat Modeling Cheat Sheet (external entities, processes, data stores, data flows) and mark trust boundaries where the level of trust changes. Threats concentrate at boundaries.
4.1 Elements
| ID | Name | Type | Description | Runs as / identity |
|---|---|---|---|---|
| E-01 | [Customer browser] | External entity | [Untrusted client] | [End user session] |
| E-02 | [API gateway] | Process | [Terminates TLS, validates tokens] | [Gateway workload identity] |
| E-03 | [Orders service] | Process | [Business logic] | [svc-orders service account] |
| E-04 | [Orders database] | Data store | [Customer and order records, Confidential] | [DB role orders_rw] |
| E-05 | [Payment provider] | External entity | [Third-party API] | [API key in secrets manager] |
4.2 Data flows
| ID | From | To | Data | Protocol and port | Authentication | Crosses boundary |
|---|---|---|---|---|---|---|
| DF-01 | E-01 | E-02 | [Login, order requests] | [HTTPS 443, TLS 1.2+] | [OIDC session token] | TB-01 |
| DF-02 | E-02 | E-03 | [Validated requests] | [gRPC over mTLS] | [Workload certificate] | TB-02 |
| DF-03 | E-03 | E-04 | [Order records] | [PostgreSQL 5432, TLS] | [Short-lived DB credential] | No |
| DF-04 | E-03 | E-05 | [Payment tokens] | [HTTPS 443] | [API key] | TB-03 |
4.3 Trust boundaries
| ID | Boundary | Between | Controls expected at the boundary |
|---|---|---|---|
| TB-01 | [Internet to edge] | [Untrusted clients and gateway] | [WAF, rate limiting, token validation, input validation] |
| TB-02 | [Edge to internal services] | [Gateway and service network] | [mTLS, authorisation per call] |
| TB-03 | [Organisation to third party] | [Orders service and payment provider] | [Egress allow list, secret rotation, response validation] |
5. Threat register (STRIDE)
Answer "What can go wrong?" by walking each element and each flow that crosses a boundary through the six STRIDE categories. Use the category reference below, then record each credible threat in the register.
| STRIDE category | Property violated | Prompt question for the session |
|---|---|---|
| Spoofing | Authentication | Can someone or something pretend to be this user, service or caller? |
| Tampering | Integrity | Can data in this flow or store be changed without detection? |
| Repudiation | Non-repudiation (accountability) | Could an actor deny an action because we cannot prove who did it? |
| Information disclosure | Confidentiality | Can data be read by someone who should not see it, in transit, at rest or in logs? |
| Denial of service | Availability | Can this element be made unavailable or degraded for legitimate users? |
| Elevation of privilege | Authorisation | Can an actor gain rights it should not have? |
Record threats in this format. Rate likelihood and impact on your organisation's risk scale (for example 1 to 5) so ratings match the Risk Register Template.
| ID | Element / flow | STRIDE | Threat description | L | I | Risk | Response | Mitigation IDs |
|---|---|---|---|---|---|---|---|---|
| T-01 | DF-01 | S | [Attacker replays a stolen session token to place orders as the customer] | [3] | [4] | [High] | Mitigate | M-01, M-02 |
| T-02 | E-03 | E | [Missing object-level check lets a customer read another customer's order by changing the ID] | [4] | [4] | [High] | Mitigate | M-03 |
| T-03 | E-05 key | I | [Payment API key committed to source or printed in logs] | [3] | [5] | [High] | Mitigate | M-04 |
| T-04 | E-03 | R | [Refunds issued by support staff cannot be attributed to an individual] | [2] | [3] | [Medium] | Mitigate | M-05 |
| T-05 | E-02 | D | [Unauthenticated endpoint flooded, exhausting gateway capacity] | [3] | [3] | [Medium] | Transfer | M-06 |
| T-06 | DF-03 | T | [Over-privileged DB role allows schema changes if the service is compromised] | [2] | [4] | [Medium] | Accept | Risk acceptance RA-[nn] |
Guidance: response options follow the OWASP cheat sheet: mitigate, eliminate (remove the feature), transfer (to another party, with residual risk recorded) or accept (with a named approver). For privacy threats such as linkability or identifiability, add a LINDDUN pass: see the LINDDUN Guide. For abuse of business logic, see the Security Requirements and Abuse Cases Guide.
6. Mitigation tracker
Answer "What are we going to do about it?" Each mitigation needs an owner, a ticket and a way to verify it.
| ID | Mitigation | Threats | Owner | Ticket | Target date | Verification | Status |
|---|---|---|---|---|---|---|---|
| M-01 | [Short-lived access tokens (15 minutes) with refresh token rotation] | T-01 | [Name] | [APP-412] | [2026-12-01] | [Integration test on token expiry] | [Open] |
| M-02 | [Bind sessions to device; re-authenticate for address changes] | T-01 | [Name] | [APP-413] | [2027-01-15] | [Pen test case] | [Open] |
| M-03 | [Object-level authorisation check in orders service for every read] | T-02 | [Name] | [APP-414] | [2026-11-30] | [Unit tests plus DAST rule] | [In progress] |
| M-04 | [Store key in secrets manager, rotate every 90 days, secret scanning in CI, log redaction] | T-03 | [Name] | [APP-415] | [2026-11-20] | [Scanner report, rotation log] | [Done] |
| M-05 | [Named accounts for support, refund events logged with user ID to SIEM] | T-04 | [Name] | [APP-416] | [2026-12-15] | [Log sample review] | [Open] |
| M-06 | [Provider DDoS protection and rate limits per client] | T-05 | [Name] | [OPS-88] | [2026-12-01] | [Load test] | [Open] |
Guidance: a mitigation is not closed until its verification evidence exists. Secrets and service credentials found in section 2 usually generate several of these rows: see the Secrets Management Guide.
7. Residual risk and sign-off
Answer "Did we do a good enough job?" The OWASP cheat sheet's review points become the sign-off criteria.
| Check | Result |
|---|---|
| Data flow diagram matches the system as built (or as designed for this release) | [Yes / No, notes] |
| Every element and boundary-crossing flow walked through all six STRIDE categories | [Yes / No] |
| Every threat has an agreed response and, where mitigated, a tracked mitigation | [Yes / No] |
| Accepted risks have a named approver and expiry date | [RA-nn list] |
| Assumptions have a validation method and owner | [Yes / No] |
| Document stored with restricted access | [Location] |
| Role | Name | Decision | Date |
|---|---|---|---|
| Technical owner | [Name] | [Approved / Approved with conditions] | [Date] |
| Application security | [Name] | [Approved / Rejected] | [Date] |
| Risk owner (for accepted risks) | [Name] | [Accepted RA-nn] | [Date] |
8. Review triggers and version history
Review this threat model when any of the following occur, and at least every [12] months:
- A new external interface, trust boundary, data store or third-party service.
- A change in authentication, authorisation or how services hold credentials.
- A new data classification or regulatory requirement.
- A security incident or penetration test finding affecting the system.
- An assumption in section 3 is found to be false.
| Version | Date | Author | Change |
|---|---|---|---|
| [1.0] | [2026-11-08] | [Name] | [Initial model] |
Implementation guidance
Rolling the template out
- Pilot on two teams: one new service, one existing system with a pending change. Time-box the session to 90 minutes and measure how long sections 2 to 4 take to prepare.
- Agree when a model is required: for example new internet-facing services, changes crossing a trust boundary, and systems handling Restricted data. Lighter changes can use a short delta model that only updates sections 4 to 6.
- Connect to delivery: mitigations become backlog items with a label (for example "threat-model") so status and age can be reported.
- Add a design gate: the release checklist asks for the threat model ID and confirms high-risk mitigations are done or accepted.
- Review quality, not just presence: AppSec samples completed models each quarter against section 7.
Metrics
- Coverage: share of in-scope systems with a current threat model (reviewed within the period).
- Mitigation closure: median days from threat identified to mitigation verified, by risk rating.
- Overdue high risks: number of high-rated mitigations past target date.
- Escapes: penetration test or incident findings that a current threat model should have caught.
Framework mapping
| Framework | Reference | How this template supports it |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SA-11(2) Threat Modeling and Vulnerability Analyses | Documented threat modelling for systems under development |
| NIST SP 800-53 Rev. 5 | SA-8 Security and Privacy Engineering Principles; PL-8 Security and Privacy Architectures | Design-time analysis of boundaries and controls |
| NIST SP 800-53 Rev. 5 | RA-3 Risk Assessment | Rated threats feed the risk assessment |
| NIST SSDF (SP 800-218) | PW.1 Design software to meet security requirements and mitigate security risks | Threat modelling as a design practice |
| ISO/IEC 27001:2022 Annex A | 8.25 Secure development life cycle; 8.27 Secure system architecture and engineering principles | Evidence of security in design |
Common failure patterns
- Diagram without boundaries: a boxes-and-arrows picture with no trust boundaries hides where threats concentrate.
- Threats with no owner: the register fills up but no mitigation is tracked, so nothing changes.
- Machine identities left out: service accounts, API keys and CI/CD credentials are omitted from section 2, so spoofing and disclosure threats against them are never considered.
- One-off exercise: the model describes the system as designed two years ago.
- Acceptance by default: risks marked "accept" without a named approver or expiry.
For systems built around AI agents, use the AI Agent Threat Model Template, and for tool selection see Threat Modelling Tools.
Standards and references
- OWASP: Threat Modeling Cheat Sheet
- OWASP: Threat Modeling
- Threat Modeling Manifesto
- Microsoft Learn: Threat Modeling Tool threats (STRIDE)
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Threat Modelling Guide · Secure Software Development Lifecycle (SSDLC) Guide · Security Architecture Review Guide · Data flow mapping for security and privacy