Threat Modelling Policy
1. Objective
This policy defines the requirements for carrying out threat modelling - systematic modelling of threats - in applications classified as L2 or L3.
Threat modelling is the link between risk classification, security requirements and the controls applied. Without threat modelling, security requirements lose their context and the controls applied no longer have a justified origin: they are applied out of habit or convention, not through analysis of real risk.
The objective of this policy is to ensure that:
- The threats relevant to each application are identified systematically
- Decisions to mitigate, accept or transfer risk are documented and approved
- The threat model remains valid and up to date throughout the lifecycle
- The artefacts produced are traceable, protected and auditable
2. Scope and applicability
| Level | Applicability |
|---|---|
| L1 | Optional; recommended for applications with critical logic or external exposure |
| L2 | Mandatory |
| L3 | Mandatory; with independent review and formal approval |
3. Methodologies
The organisation adopts the following methodologies, selected proportionally to the context:
| Methodology | Focus | When to apply |
|---|---|---|
| STRIDE | Technical threats (Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege) | Exposed applications or those with critical logic - base use at L2 and L3 |
| LINDDUN | Privacy threats | Systems with personal data, subject to the GDPR or consent obligations |
| PASTA | Modelling based on business risk | Regulated or critical systems, or contexts with high formal demands |
STRIDE is the base methodology at L2 and L3. Whenever personal data exists, LINDDUN is mandatory at all levels: at L1 in lightweight form (the seven categories worked through over the personal-data flows), at L2 and L3 as a formal analysis. PASTA must be considered in regulatory contexts.
4. When to carry out threat modelling
4.1 Mandatory triggers
| Event | Applicability |
|---|---|
| Start of a new project or product (L2/L3) | Mandatory |
| New external integration or additional exposure | Mandatory |
| Significant architecture change | Mandatory |
| New type of sensitive data processed | Mandatory |
| Addition of a new user profile with privileges | Mandatory |
| Pentest result revealing a gap in the model | Mandatory |
| Post-incident originating in an unmodelled threat | Mandatory |
4.2 Periodic cadence
In addition to the triggers, the threat model must be reviewed at a minimum cadence:
| Level | Minimum cadence |
|---|---|
| L2 | Annual or with each major release |
| L3 | Half-yearly or with each major release |
5. Threat modelling process
5.1 Mandatory steps
- Define scope and assumptions - system boundaries, components included, trust assumptions, attacker profiles
- Create or update the architecture diagram - DFD (Data Flow Diagram) or equivalent, with explicit trust boundaries
- Identify threats - using the selected methodology (STRIDE, LINDDUN, PASTA)
- Assess and prioritise - impact, likelihood, severity per threat
- Decide per threat - mitigate / accept / transfer / reject - with documented justification
- Map to requirements and controls - link each mitigated threat to the corresponding requirement or control
- Approve formally - by the approval authority appropriate to the risk level
- Archive - approved version with traceability metadata
5.2 Minimum model content checklist
- Scope, assumptions and boundaries documented
- Architecture diagram with trust boundaries
- List of threats identified per component/flow
- Documented decision per threat (mitigate / accept / transfer / reject)
- Link to security requirements (
REQ-*) or controls (CTRL-*) for mitigated threats - Accepted risks with justification and reference to the risk acceptance process
- Version, date and person responsible for preparing it
- Formal approval recorded
6. Formal approval
The threat model is only valid as a security control when there is documented formal approval.
| Level | Minimum approval required |
|---|---|
| L2 | AppSec Engineer + Tech Lead |
| L3 | AppSec Engineer + Software Architect + independent review |
The approval must include:
- Confirmation that the scope is correct and complete
- Confirmation that the decisions per threat are technically grounded
- Date and identification of the approver
7. Update upon technical change
Whenever a significant change occurs, the threat model must be updated before promotion to production:
- Significant change identified and documented
- New or changed threats recorded
- Mitigation or acceptance decisions updated
- New version formally approved
- Link to the commit or PR that gave rise to the change
The CI/CD pipeline must include a gate that checks whether the threat model is up to date with respect to relevant changes, blocking promotion at L2/L3 when the model is out of date without an approved justification.
8. Integration with architecture
Threat modelling and secure architecture must be synchronised bidirectionally:
- Architecture decisions must reflect the threats prioritised in the model
- Architectural changes must trigger an update of the threat model where applicable
- Architecture Decision Records (ADR) must reference relevant threats when the decision has a security impact
9. Protection and retention of artefacts
Threat modelling artefacts (diagrams, models, decisions) are sensitive assets - they contain information about the internal architecture, data flows and identified vulnerabilities.
9.1 Access control
- Access restricted according to the principle of least privilege
- Sharing only with functions that need access to carry out their responsibilities
- Do not publish in public repositories or in systems without access control
9.2 Classification
| Level | Minimum recommended classification |
|---|---|
| L2 | Confidential - internal to the product and security team |
| L3 | Confidential / Restricted - access limited to AppSec, architecture and management |
9.3 Retention
| Artefact | Minimum retention |
|---|---|
| Threat model (active version) | While the application is active |
| Approved historical versions | 3 years after replacement |
| Approval records | 1 year (L1), 2 years (L2), 3 years (L3) |
| Associated accepted risks | As per the Residual Risk Acceptance Policy |
10. Reuse of previous models
Reusing a previous threat model as the basis for a new project or review is permitted, provided that:
- The previous model is explicitly identified as the reference
- Differences in context, architecture and flows are analysed and documented
- Inherited critical decisions are explicitly revalidated
- The reuse is recorded together with the person responsible for the review
Reuse without explicit review is equivalent to having no threat modelling - the original model is not valid for a different context.
11. Proportionality by level
| Requirement | L1 | L2 | L3 |
|---|---|---|---|
| Threat modelling mandatory | No | Yes | Yes |
| STRIDE as base methodology | Recommended | Mandatory | Mandatory |
| LINDDUN (personal data) | Mandatory (lightweight form) | Mandatory | Mandatory |
| Formal approval | Not applicable | AppSec + Tech Lead | AppSec + Architect + independent review |
| Gate in the CI/CD pipeline | Not applicable | Recommended | Mandatory |
| Periodic review | On request | Annual / major release | Half-yearly / major release |
| Artefacts with access control | Recommended | Mandatory | Mandatory |
12. Responsibilities
| Role | Responsibility |
|---|---|
| Software Architect | Lead or coordinate threat modelling; keep the architecture diagram up to date |
| AppSec Engineer | Support threat identification; approve the model; ensure traceability |
| Tech Lead / Developer | Take part in the threat modelling session; implement assigned mitigations |
| DevOps / SRE | Configure the consistency gate in the pipeline; manage protected storage of the artefacts |
| GRC / Compliance | Ensure that all L2/L3 applications have an approved and up-to-date model |
13. Review and audit of this policy
This policy must be reviewed annually or after any of the following events:
- Incident originating in an unmodelled threat
- Update of the reference methodologies (STRIDE, LINDDUN, PASTA)
- Regulatory change with an impact on the mandatory nature of threat modelling
14. Normative and technical references
| Reference | Relevance |
|---|---|
| SbD-ToE Ch. 03 - Threat Modelling | Methodologies, user stories, artefacts, integration into the SDLC |
| SbD-ToE Ch. 04 - Secure Architecture | Threat modelling ↔ architecture synchronisation |
| SbD-ToE Ch. 02 - Security Requirements | Threat → requirement link |
| STRIDE (Microsoft) | Methodology for categorising technical threats |
| LINDDUN | Privacy threat methodology |
| PASTA | Process for Attack Simulation and Threat Analysis |
| OWASP Threat Modeling Cheat Sheet | Practical implementation guide |
| NIST SP 800-154 | Guide to Data-Centric System Threat Modeling |
| SSDF PW.1 | Threat analysis as the basis for security requirements |
| ISO/IEC 27005 | Information security risk management |