Periodic Review Checklist - Threat Modelling
This checklist applies to all applications with L2 or L3 criticality, or that involve sensitive flows, external exposures or relevant architecture changes.
It serves as a binary, auditable verification instrument of the practical adoption of the prescriptions of Chapter 3 - Threat Modelling (THR-001 to THR-008), enabling:
- Formal verification in technical reviews and audits;
- Control of traceability between threats, requirements and controls;
- Generation of operational indicators that can be aggregated by project or team.
🗓️ Review is recommended at the start of each epic or critical feature, and before significant changes to the system.
📋 Verification Items
| Item | Verified? |
|---|---|
| Is there a formal, documented threat model for the application (L2+), traceable to the architecture version assessed? | ☐ |
| Does the model include up-to-date DFDs with explicit, justified trust boundaries? | ☐ |
| Was a structured methodology applied, with STRIDE as the baseline? | ☐ |
| Do systems that process personal data apply LINDDUN over the same DFD? | ☐ |
| Does each threat have an explicit formal disposition (mitigated, accepted, transferred or excluded) with a named owner? | ☐ |
| Does each accepted risk have a documented justification, formal approval and a reassessment deadline? | ☐ |
| Is there verifiable threat → requirement → backlog → validation traceability, with the threat ID referenced? | ☐ |
| Is the threat model versioned, and was it updated within the defined period (≤30 days after a trigger or per release), with a freshness gate in the CI/CD? | ☐ |
| Was the threat model reviewed by independent AppSec before go-live (L2+), with evidence? | ☐ |
| Do systems with AI/ML components have an extended threat model (prompt injection, model poisoning) referenced to MITRE ATLAS or NIST AI 100-2? | ☐ |
| Do AI agents with tool use have an agentic DFD and a threat library cited by canonical ID and anchored to controls? | ☐ |
| Were abuse/misuse cases derived and integrated into the backlog as traceable requirements? | ☐ |
| Was the threat model validated and approved by an explicitly responsible person, distinct from the supporting artefacts? | ☐ |
| Do the threat modelling artefacts have defined access control, classification and retention? | ☐ |
| Were the threats prioritised by business impact, and is that prioritisation reflected in the backlog? | ☐ |
🔄 Operational Integration
- This checklist can be integrated into architecture reviews, release gates, CI/CD pipelines or sprint planning sessions.
- Each item must be validated with objective evidence: DFD models, STRIDE files, comments in PRs, links to requirements in the backlog, session records, etc.
⚠️ In the event of a negative answer, a documented formal exception must exist, with an owner and a reassessment deadline, in accordance with the Ch. 2 model.
✅ Compliance and KPI
- Validation of this checklist makes it possible to declare compliance with Chapter 3 - Threat Modelling.
- The count of affirmative answers can be used to measure the degree of adoption of the prescribed practices.
- This result can be aggregated by team, domain or organisation as an indicator of maturity and risk coverage.
📌 This operational mechanism is aligned with the model of traceability and continuous control defined in SbD-ToE.