Standard : Teams understand the threat models relevant to their domain

Purpose and Strategic Importance

This standard ensures teams understand the threat models relevant to their domain — so they can design systems that mitigate real-world risks, not just theoretical ones. It strengthens proactive security thinking at every layer of development.

Aligned to our "Secure by Design" policy, this standard builds risk awareness and reduces vulnerabilities before they reach production. Without it, teams may unknowingly expose systems to avoidable threats and compromise trust.

Strategic Impact

  • Increases consistency and rigour in secure design
  • Reduces likelihood of exploitable vulnerabilities reaching production
  • Strengthens team confidence and autonomy in decision-making
  • Reinforces security ownership across the software lifecycle
  • Enables faster, safer innovation with reduced rework

Risks of Not Having This Standard

  • Late discovery of risks and vulnerabilities
  • Increased cost of remediation due to poor early-stage threat planning
  • Reduced trust in systems and engineering maturity
  • Missed compliance obligations and audit failures
  • Fragmented understanding of security across teams

CMMI Maturity Model

Level 1 – Initial

Category Description
People & Culture Teams have low awareness of threats relevant to their domain.
Security is reactive or dependent on external review.
Process & Governance No structured threat modelling occurs.
Risks are surfaced post-fact through incidents.
Technology & Tools No tooling or templates to support threat modelling.
Measurement & Metrics Security risks are only tracked after production incidents.

Level 2 – Managed

Category Description
People & Culture Teams begin to identify common threat patterns during delivery.
Process & Governance Threat modelling occurs occasionally but without consistency.
Technology & Tools Some use of basic templates (e.g. STRIDE) but not embedded in delivery tools.
Measurement & Metrics Risks are captured inconsistently across teams or phases.

Level 3 – Defined

Category Description
People & Culture Teams are trained on threat modelling relevant to their domain.
Process & Governance Threat models are produced at key lifecycle stages and linked to design decisions.
Technology & Tools Shared tooling, templates, and examples are integrated into team workflows.
Measurement & Metrics Threat model coverage and mitigation tracking are visible and monitored.

Level 4 – Quantitatively Managed

Category Description
People & Culture Teams reflect on the effectiveness of their threat modelling and refine practices.
Process & Governance Threat models are kept up to date and linked to architectural decisions.
Technology & Tools Risk registries and mitigation actions are version-controlled and auditable.
Measurement & Metrics Threat coverage, false negatives, and risk remediation rates are tracked.

Level 5 – Optimising

Category Description
People & Culture Threat modelling is collaborative, iterative, and embedded in design thinking.
Process & Governance Models are updated through feedback from incidents, retros, and evolving risk landscapes.
Technology & Tools Threat modelling tools integrate with pipelines and design tooling.
Proactive threat intelligence feeds shape team focus.
Measurement & Metrics Threat posture is continuously improved based on trend data and feedback loops.

Key Measures

  • % of services with documented and reviewed threat models
  • % of engineers trained in threat modelling relevant to their domain
  • Frequency of threat model updates across product lifecycle
  • % of threat mitigations implemented from model insights
  • Time between threat identification and mitigation planning