Threat Model Template
What it is
A threat model is a structured security analysis document that identifies what could go wrong with a system from a security perspective: who might attack it, what assets they might target, what techniques they might use, and what mitigations are in place or needed. It is the primary artifact of threat modeling — the practice of proactively identifying security risks before a system is built or deployed, rather than discovering them after a breach.
The most widely used framework for structuring threat analysis is STRIDE, developed at Microsoft. STRIDE is a mnemonic for six categories of security threat: Spoofing (impersonating something or someone), Tampering (modifying data without authorization), Repudiation (denying that an action occurred), Information Disclosure (exposing data to unauthorized parties), Denial of Service (making the system unavailable), and Elevation of Privilege (gaining capabilities beyond what is authorized). By systematically working through these six categories for each component and trust boundary in a system, teams surface threats that might otherwise be overlooked.
A threat model is not a one-time exercise. It should be updated whenever the system architecture changes materially, new data types are processed, new integrations are added, or new threat intelligence suggests that existing threats have changed in severity. For systems subject to regulatory compliance (GDPR, HIPAA, PCI-DSS, SOC 2), threat models provide evidence of a functioning security design process.
Why it exists
Security vulnerabilities are cheapest to fix before a system is built. Discovering a fundamental architectural flaw — such as the absence of authentication on an internal API or the transmission of sensitive data without encryption — during a design review is a documentation change. Discovering the same flaw after deployment is a potential breach, a rebuild of production systems, regulatory notification obligations, and customer trust damage. Threat modeling is the practice that makes early discovery possible.
Threat modeling also produces better systems beyond strict security requirements. The discipline of articulating data flows and trust boundaries forces teams to make implicit security assumptions explicit. Engineers who have never thought about what happens if their message queue is compromised think differently about authorization and audit logging after completing a threat model. Security thinking becomes embedded in architectural decisions rather than appended as a compliance checklist after the fact.
For organizations pursuing security certifications or handling regulated data, threat models are often a required deliverable. SOC 2 Type II audits expect evidence of security design processes; ISO 27001 requires risk assessment documentation. A well-maintained threat model archive satisfies both requirements while also serving as a foundation for penetration testing scope definition and security incident response planning.
When to use
- During the design phase of any new system or service that handles sensitive data, processes financial transactions, manages authentication, or has privileged access to infrastructure.
- When making a significant architectural change — adding a new integration, changing authentication mechanisms, or exposing a service to a new network boundary (e.g., moving from internal-only to internet-facing).
- As part of a security review before launching a new product feature to external users, especially one involving user-provided data, file uploads, or third-party service integration.
- Annually or when threat intelligence changes — the threat landscape evolves and previously acceptable risks may become unacceptable as new attack techniques emerge.
- When preparing for a penetration test, to scope the engagement and brief the testers on the system's architecture and known trust boundaries.
When NOT to use
- As a box-checking exercise that is never actually reviewed by anyone with security expertise — a threat model written for compliance and never acted upon provides no security value.
- For trivial internal tools with no sensitive data access, no external network exposure, and no privileged system access, where the overhead of a full threat model exceeds the risk.
- As a substitute for professional penetration testing or a security audit on high-risk systems — a threat model is a design-time exercise that complements but does not replace runtime security testing.
- When the scope is so broad (the entire company's system) that meaningful analysis is impossible — scope threat models to specific systems, services, or features with clear boundaries.
Template
# Threat Model: [System / Feature Name]
**System:** [Name of the system or feature being modeled]
**Version:** [e.g., v1.0 — increment on each review]
**Status:** Draft | Under Review | Approved | Outdated
**Author(s):** [Name(s)]
**Security Reviewer:** [Name — from security team if available]
**Date:** [YYYY-MM-DD]
**Next Review Date:** [YYYY-MM-DD]
**Scope:** [What is in scope for this threat model — be specific]
**Out of Scope:** [What is explicitly excluded — e.g., "Physical security of data centers"]
---
## System Overview
**Purpose:** [What the system does in 2–3 sentences]
**Users / Principals:**
- [User type 1 — e.g., "Authenticated end users (web and mobile clients)"]
- [User type 2 — e.g., "Internal admin users (company employees)"]
- [User type 3 — e.g., "Automated services (CI/CD pipeline, cron jobs)"]
**Technology stack:**
- Frontend: [Framework / hosting]
- Backend API: [Language / framework / hosting]
- Data stores: [Databases, caches, object storage]
- External integrations: [Third-party services accessed]
---
## Data Flow Diagram
**DFD:** [Link to Excalidraw / Lucidchart / draw.io diagram or embed image]
### Key Data Flows
1. [User] → [Frontend] → [API Gateway]: [Authenticated HTTPS request]
2. [API Gateway] → [Order Service]: [Internal mTLS request]
3. [Order Service] → [PostgreSQL]: [Encrypted connection, parameterized queries]
4. [Order Service] → [Payment Provider]: [HTTPS, API key auth]
### Trust Boundaries
| Boundary | Description |
|----------|-------------|
| Internet / DMZ | Separates public internet traffic from internal services |
| Internal services / Database tier | Separates application layer from data layer |
| Employee / Admin zone | Separates privileged administrative access from regular operations |
---
## Assets
| Asset | Sensitivity | Consequence of Compromise |
|-------|-------------|--------------------------|
| User PII (name, email, address) | High | Regulatory fines (GDPR), customer churn, reputational damage |
| Payment card data | Critical | PCI-DSS violation, financial fraud liability |
| Authentication tokens / session cookies | High | Account takeover, unauthorized access to user data |
| Internal service credentials (API keys, DB passwords) | Critical | Full system compromise |
| Audit logs | Medium | Inability to detect or investigate breaches |
| Order data (non-PII) | Medium | Competitive intelligence if exposed at scale |
---
## Threat Actors
| Actor | Motivation | Capability | Likely Vector |
|-------|------------|------------|---------------|
| External attacker | Financial gain, data theft | Low–High (varies) | Public-facing API, phishing |
| Malicious insider | Data theft, sabotage | High (has system access) | Direct database access, credential theft |
| Compromised third-party | Supply chain attack | Medium | Malicious dependency, API abuse |
| Automated scanner / bot | Credential stuffing, scraping | Low (automated, low sophistication) | Authentication endpoints, public APIs |
---
## STRIDE Analysis
### Threat Scoring
| Score | Likelihood | Impact |
|-------|------------|--------|
| 1 | Very unlikely | Negligible |
| 3 | Possible | Moderate |
| 5 | Very likely | Catastrophic |
---
### [Component/Flow: User Authentication]
#### S — Spoofing
**Threat:** An attacker presents a forged or stolen credential to authenticate as a legitimate user.
**Likelihood:** 4 | **Impact:** 5 | **Risk:** 20 (MITIGATE)
**Mitigation:** Multi-factor authentication required for admin accounts; rate limiting on login endpoint; account lockout after 10 failed attempts; anomalous login detection (new device/location).
**Status:** Implemented — see [link to auth implementation]
#### T — Tampering
**Threat:** An attacker intercepts and modifies an API request in transit to alter the intended action.
**Likelihood:** 2 | **Impact:** 4 | **Risk:** 8 (ACCEPT with monitoring)
**Mitigation:** All API traffic requires HTTPS/TLS 1.2+; HSTS enforced; request signing on sensitive endpoints.
**Status:** Implemented
#### R — Repudiation
**Threat:** A user denies performing an action (e.g., placing an order or changing account settings) that they actually performed.
**Likelihood:** 3 | **Impact:** 3 | **Risk:** 9 (MITIGATE)
**Mitigation:** Immutable audit log of all authenticated actions, including user ID, IP address, user agent, and timestamp. Logs retained for 12 months.
**Status:** In progress — TICKET-1234
#### I — Information Disclosure
**Threat:** Verbose error messages expose internal system details (stack traces, database errors, internal hostnames) to unauthenticated users.
**Likelihood:** 4 | **Impact:** 3 | **Risk:** 12 (MITIGATE)
**Mitigation:** Error responses sanitized in production; internal errors logged server-side and returned to caller as generic reference IDs only.
**Status:** Implemented
#### D — Denial of Service
**Threat:** An attacker floods the authentication endpoint, preventing legitimate users from logging in.
**Likelihood:** 3 | **Impact:** 4 | **Risk:** 12 (MITIGATE)
**Mitigation:** Rate limiting at API gateway (100 requests/minute per IP); CAPTCHA after 5 failed attempts; WAF rules for credential stuffing patterns.
**Status:** Implemented
#### E — Elevation of Privilege
**Threat:** A regular user accesses admin-only endpoints by manipulating request parameters or exploiting broken access control.
**Likelihood:** 3 | **Impact:** 5 | **Risk:** 15 (MITIGATE)
**Mitigation:** Role-based access control enforced server-side; no client-provided role claims trusted; automated tests verify that each admin endpoint returns 403 for non-admin tokens.
**Status:** Implemented
---
### [Component/Flow: Data Storage — PostgreSQL]
#### S — Spoofing
**Threat:** A compromised application service connects to the database using credentials stolen from another service, impersonating a different application identity.
**Likelihood:** 2 | **Impact:** 5 | **Risk:** 10 (MITIGATE)
**Mitigation:** Each service uses a dedicated database user with least-privilege grants; credentials rotated via secrets manager on 90-day schedule.
**Status:** In progress — TICKET-1235
#### T — Tampering
**Threat:** An attacker with database access modifies records (e.g., order amounts, user permissions) without detection.
**Likelihood:** 2 | **Impact:** 5 | **Risk:** 10 (MITIGATE)
**Mitigation:** Application-level audit log for all write operations; database-level trigger audit on critical tables; read replicas for analytics (prevents analytics workloads from modifying data).
**Status:** Partially implemented
#### I — Information Disclosure
**Threat:** SQL injection attack allows an attacker to read arbitrary database data via the API.
**Likelihood:** 2 | **Impact:** 5 | **Risk:** 10 (MITIGATE)
**Mitigation:** All queries use parameterized statements / ORM; no raw SQL string interpolation permitted (enforced by linting rule); quarterly SAST scan includes SQL injection detection.
**Status:** Implemented
---
## Mitigations Summary
| # | Threat | Mitigation | Status | Owner | Ticket |
|---|--------|-----------|--------|-------|--------|
| M1 | Authentication spoofing | MFA for admin accounts | Implemented | [@name] | — |
| M2 | Repudiation | Immutable audit log | In Progress | [@name] | TICKET-1234 |
| M3 | Privilege escalation | Server-side RBAC | Implemented | [@name] | — |
| M4 | DB credential sharing | Per-service DB users | In Progress | [@name] | TICKET-1235 |
| M5 | SQL injection | Parameterized queries | Implemented | [@name] | — |
---
## Residual Risks
| Risk | Rationale for Acceptance | Owner | Review Date |
|------|--------------------------|-------|-------------|
| [Risk description] | [Why it is accepted — e.g., "Likelihood is very low and full mitigation would require architectural rework scheduled for Q3"] | [@name] | [YYYY-MM-DD] |
---
## Review Sign-off
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | [Name] | [YYYY-MM-DD] | [Signed] |
| Security Reviewer | [Name] | [YYYY-MM-DD] | [Signed / Pending] |
| Engineering Lead | [Name] | [YYYY-MM-DD] | [Signed / Pending] |
| Compliance (if required) | [Name] | [YYYY-MM-DD] | [Signed / Pending] |
Pros and cons
Benefits
- Surfaces security vulnerabilities at design time — the cheapest and least disruptive point to fix them.
- Creates shared security awareness across the engineering team; engineers who participate in threat modeling write more security-conscious code.
- Provides evidence of a functioning security design process for compliance audits (SOC 2, ISO 27001, PCI-DSS).
- Produces a prioritized, actionable list of mitigations that can be incorporated into the implementation backlog rather than discovered post-breach.
Pitfalls
- Threat models that are not updated as the system evolves become dangerously stale, providing false assurance that security has been reviewed.
- Analysis paralysis: attempting to enumerate every possible threat without prioritizing by risk leads to documents that are exhaustive but not actionable.
- Treating STRIDE as a rigid checklist rather than a thinking tool — some threat categories do not apply to all components, and over-applying the framework produces noise.
- No security expertise in the room: threat models produced by engineering teams without security knowledge tend to miss sophisticated attack techniques that a trained reviewer would catch.
Writing guidance
Start with the Data Flow Diagram before writing any STRIDE analysis. The DFD forces you to make data flows and trust boundaries explicit, which is the foundation of all threat analysis. Every threat in a well-structured threat model can be traced to a specific data flow crossing a trust boundary. If you cannot draw the DFD, you do not yet understand the system well enough to model its threats. Spend 80% of your preparation time on the DFD — the analysis is much easier once it is clear.
Use the risk score (Likelihood × Impact) to prioritize, not to excuse inaction. A Risk score of 25 (5×5) means an extremely likely, catastrophic threat that must be mitigated regardless of cost. A Risk score of 4 (2×2) means an unlikely, moderate threat that can be accepted with appropriate monitoring. The DREAD or STRIDE×DREAD framework extends this with additional dimensions; for most teams, simple likelihood × impact scoring produces actionable prioritization without excessive complexity.
Involve a security engineer or security champion in the review, especially for high-risk systems. Engineering teams are not trained to think like attackers. A security reviewer brings knowledge of current attack techniques, regulatory requirements, and common implementation vulnerabilities that is rarely present in a purely engineering review. Even one hour with a trained security reviewer reviewing the DFD and STRIDE table significantly improves threat model quality.
Common mistakes
- No trust boundaries on the DFD: A data flow diagram without trust boundaries cannot support STRIDE analysis — trust boundary crossings are where most threats manifest.
- Mitigations listed without implementation status: A threat model where every threat lists "implement input validation" as a mitigation but none are tracked or verified provides no actual security assurance.
- Skipping the Repudiation category: Non-repudiation (audit logging) is consistently the most under-addressed STRIDE category in engineering threat models, despite being critical for incident investigation and compliance.
- No residual risk acknowledgment: Organizations that list no accepted residual risks in their threat models are either modeling perfect systems (impossible) or are not being honest about what they have not mitigated.
Review checklist
- Is a Data Flow Diagram with explicit trust boundaries included or linked?
- Has each STRIDE category been addressed for every trust boundary crossing in the DFD?
- Do all mitigations have an implementation status (Implemented / In Progress / Accepted) and a ticket for in-progress items?
- Has the threat model been reviewed by at least one person with formal security training?
- Is a next review date set and is there a named owner responsible for keeping the document current?
Example usage
- New payment integration: Before integrating a new payment provider, the team produces a threat model covering the new data flows carrying cardholder data. The STRIDE analysis identifies that transaction details are logged in plaintext in application logs — a PCI-DSS violation — which is caught and remediated before the integration goes live.
- API gateway introduction: A platform team models the new API gateway's authentication and routing logic. The Elevation of Privilege analysis reveals that the gateway passes internal service names in a header that client applications can read, potentially enabling service enumeration by an attacker who compromises a user's client device.
- Annual review of user authentication service: A yearly threat model update incorporates new threat intelligence about AiTM (Adversary-in-the-Middle) phishing attacks that bypass TOTP-based MFA, leading the team to adopt phishing-resistant FIDO2 hardware keys for admin accounts.
Related templates
- Design Document (Tech Spec) — the Security Considerations section of a design doc often references or embeds a threat model.
- API Contract — the authentication section of an API contract should be consistent with the threat model's analysis of authentication threats.
- Security — security architecture patterns and controls referenced in threat model mitigations.