Yes. Threat modelling should be treated as a governance control because it determines whether every other control is aimed at the real attacker. If the model is wrong, compliance can still look good while the system remains vulnerable. Teams should require evidence that assumptions were tested against automation, runtime access, and adversarial behaviour.
Why threat modelling belongs in governance, not just design
Threat modelling is a governance control when it is used to decide whether the organisation is protecting the right assets, against the right adversary behaviour, with the right assumptions. That matters because control effectiveness depends on the threat picture being current. A model that ignores automation, runtime privilege, or novel abuse paths can leave a system compliant on paper and exposed in practice. For teams working on AI or agentic workflows, NIST Cybersecurity Framework 2.0 is useful as a governance reference point, but it is the threat model itself that tells you whether the controls map to reality.
Security teams often treat threat modelling as a one-time architecture exercise, then discover only after deployment that the system’s actual trust boundaries, privilege paths, or third-party dependencies were never captured.
What governance-grade threat modelling actually changes
Governance-grade threat modelling changes the question from “Did we do a workshop?” to “Can we show that risk decisions were made from a defensible understanding of the system?” That distinction matters because the output is not only a diagram or a list of threats. It is evidence that assumptions were challenged, owner responsibility was assigned, and control choices were tied to realistic attack paths. Where the subject involves AI systems, the model should also account for prompt injection, tool misuse, training or retrieval contamination, and delegated action through connected services. Where the subject is broader cyber infrastructure, the same logic applies to lateral movement, privilege escalation, and dependency failure.
In practice, the governance value comes from the decision points the model forces. Teams should be able to show what they considered in scope, what they excluded, why a threat was prioritised, and what changed after review. If a model never changes with architecture changes, credential changes, or new automation, it is no longer governing the system. If the model cannot explain which assumptions were tested, it is usually being used as documentation rather than control.
- Use the threat model to confirm that security requirements are tied to actual system behavior, not generic templates.
- Record assumptions about identities, integrations, and autonomous actions so they can be revisited when the design changes.
- Require evidence that high-impact abuse paths were reviewed by both technical owners and risk owners.
This guidance breaks down when teams treat every diagram update as equivalent to a real threat review, because that turns governance into paperwork rather than decision-making.
Where the governance line gets blurry
Tighter threat modelling often increases review overhead, requiring organisations to balance speed against the need to catch the wrong assumptions early. The line gets blurry in fast-moving environments, especially when product teams want lightweight design review and security teams want formal approval. Guidance versus consensus is not uniform here: some organisations treat threat modelling as a required pre-implementation gate, while others use it as a recurring control that informs risk acceptance after each major change. The right answer depends on how much change the system can tolerate without re-validating its attack assumptions.
One common edge case is a low-complexity system with a narrow scope. In that case, a full modelling exercise may add little value beyond a short, well-maintained threat register. Another edge case is a platform with repeated reuse of the same service pattern. There, the threat model should not be recreated from scratch each time; it should be versioned and amended when the trust boundary, privilege model, or dependency chain changes. For AI-enabled systems, the governance burden rises quickly because the threat surface can change when the model, tools, or orchestration layer changes even if the user interface does not. That is why the control should focus on change sensitivity, not document length.
The most useful standard is whether the threat model still explains the system’s current exposure and supports a defensible risk decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST CSF 2.0, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV-1 | Threat modelling sets the system-level risk picture that governance uses to direct control priorities. |
| Recommendation: Use threat models to steer control selection toward the most material attack paths and assumptions. | ||
| NIST CSF 2.0 | ID.RA-1 | The question is about whether threat modelling should govern how threats are identified and recorded. |
| Recommendation: Threat modelling should keep threat and exposure identification current as systems and threats change. | ||
| NIST CSF 2.0 | GV.RM-1 | Threat modelling becomes governance when it is maintained as part of an ongoing risk process. |
| Recommendation: Treat the threat model as an ongoing risk input, not a one-off design artifact. | ||
| CIS Controls v8 | 17 | Threat modelling helps prioritise realistic adversary paths that response planning must be ready for. |
| Recommendation: Use modelling to ensure response planning covers the most plausible attack paths. | ||
| MITRE ATLAS | ATLAS | AI and agentic threat modelling aligns with adversary technique analysis against AI systems. |
| Recommendation: Map AI-specific abuse paths so governance reflects how adversaries actually attack AI systems. | ||
Practitioner Guidance
What to prioritise: Treat the threat model as a living input to design approval, exception handling, and major-change review. If it is not used to challenge scope, assumptions, and ownership, it is not functioning as governance.
What to verify: Confirm that the model covers current trust boundaries, active integrations, privileged paths, automation, and any delegated or autonomous actions. A model that omits one of those areas is usually under-governing the real system.
Decision rule: If a change alters access, data flow, execution authority, or external dependency, require a threat-model refresh before relying on prior risk decisions. If the change only affects implementation detail without altering exposure, a lighter review may be sufficient.
Practitioner takeaway: The governance test is not whether threat modelling exists, but whether it still forces accurate risk decisions when the system, attacker, or automation changes.
