Threat Modelling vs Risk Assessment: Design Decisions vs Enterprise Risk Decisions

Threat modelling and risk assessment both ask "what could go wrong?", so organisations often treat one as a substitute for the other and end up with design flaws nobody rated or risk registers nobody can trace to a real system. Threat modelling is a design-time engineering activity: a team examines a representation of a specific system to find threats and agree mitigations before and while it is built. Risk assessment is a management activity: it estimates the likelihood and impact of adverse events across systems, processes or the whole organisation so that leaders can decide how to respond. This guide compares the two on scope, inputs, outputs, owners and cadence, shows how threat model findings should flow into the risk register, and covers the failure modes when they do not. It is for security architects, AppSec leads, risk managers and CISOs. For the methods themselves, see the Threat Modelling Guide and the NIST SP 800-30 Risk Assessment Guide.

Key takeaways

• Different questions, different owners. Threat modelling asks "how could this design be attacked and what do we change?"; risk assessment asks "how much exposure do we carry and is it acceptable?".
• Threat modelling produces requirements, risk assessment produces decisions. One feeds the backlog and the architecture; the other feeds the risk register, budgets and acceptance.
• Most threat model findings never need the risk register. Mitigations that are fixed in design are closed in the backlog; only findings that will be accepted, deferred or that exceed a threshold should be escalated as risks.
• The link must be explicit. A defined escalation rule, a shared scale and a traceable reference from each risk entry to its threat model stop findings from vanishing between the two processes.
• Neither replaces the other. A risk assessment cannot find a missing authorisation check on an API, and a threat model cannot tell the board whether total cyber exposure is within appetite.

Short answer

Threat model each significant system, feature or change during design, and keep the model current as the system changes, as the OWASP Threat Modeling Cheat Sheet recommends. Run risk assessments at organisation, business process and system level on a regular cycle and when the environment changes, as NIST SP 800-30 Rev. 1 describes across its three tiers. Connect them with an escalation rule: a threat model finding becomes a risk register entry when its agreed response is to accept, transfer or defer it, or when its rated severity crosses a threshold the risk function defines. NIST SP 800-53 Rev. 5 reflects the split: SA-11(2) requires developers to perform threat modelling and vulnerability analyses during development, while RA-3 requires the organisation to conduct and update risk assessments.

Side-by-side comparison

Threat modelling in this pairing

Purpose: the Threat Modeling Manifesto defines threat modelling as analysing representations of a system to highlight concerns about security and privacy characteristics, and frames it around four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. Its value comes from changing the design while change is cheap.

Architecture in words: the team draws a data flow diagram or similar model showing processes, data stores, external entities, data flows and trust boundaries. It applies a structured prompt such as STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) to each element, records threats and decides a response for each: mitigate, eliminate, transfer or accept. Agreed mitigations become security requirements and test cases. The OWASP cheat sheet adds that mitigations should be testable and that the reasons for accepting any residual risk should be documented.

Where it is weak: it rates threats relative to each other within one system, often with simple high, medium and low labels. OWASP notes that likelihood multiplied by impact is hard to estimate at this level and ignores remediation effort. It says little about business impact across the organisation or whether exposure is within appetite.

Failure modes: the Manifesto names "Admiration for the Problem" (analysis without practical solutions), the "Hero Threat Modeler" (dependence on one expert) and the assumption of a single "Perfect Representation". In practice the commonest failure is a model built once for a design review and never updated.

Risk assessment in this pairing

Purpose: NIST SP 800-30 Rev. 1 positions risk assessment as the step that gives senior leaders the information to decide how to respond to risk, and describes assessments at three tiers: organisation, mission or business process, and information system. ISO/IEC 27005:2022 gives guidance on identifying, assessing and treating information security risks in support of an ISO/IEC 27001 management system.

Architecture in words: the risk function frames the context (scope, assumptions, appetite and tolerance), identifies threat sources and events, vulnerabilities and predisposing conditions, estimates likelihood and impact, and records the result as risk scenarios in a register. Each risk has an owner and a response: accept, avoid, mitigate, share or transfer. NIST IR 8286 Rev. 1, published in December 2025, describes how cybersecurity risk registers roll up from system and organisational levels into enterprise risk management, and the IR 8286 series supplies risk register schemas and templates.

Where it is weak: it works at a level of abstraction where a specific design flaw is invisible. A scenario such as "unauthorised access to customer data through the web application" can be rated without anyone knowing that the order API lacks object-level authorisation.

Failure modes: registers full of generic, untraceable risks; scores that never change because no new evidence arrives; and acceptance decisions made without the technical detail that would have changed them.

Linking threat model findings to the risk register

This is the part most organisations leave informal. The aim is not to copy every threat into the register, which would flood it, but to make sure the right findings reach a decision maker with authority to accept or fund them.

Make the link work in practice:

1. Agree one rating translation. Threat models can keep a light scale, but the risk function publishes how a threat model rating maps to register likelihood and impact so escalated items arrive pre-scored, then reviewed.
2. Define the escalation rule in policy. For example: any accepted or deferred finding rated high, any finding affecting regulated data, and any finding whose mitigation depends on another team.
3. Write proper risk statements. Turn "STRIDE: Elevation of privilege on admin API" into a scenario a business owner can judge: the threat source, the event, the affected asset and the business consequence.
4. Keep traceability both ways. Each register entry references the threat model and threat ID; each model shows the register ID for escalated items. Use the Threat Model Template and the Risk Register Template.
5. Close the loop. When the risk is treated or the system changes, update both records. Expired acceptances should reopen the model, not just the register line.

The flow also runs the other way. Enterprise risk assessment tells threat modellers which systems deserve the deepest models (those supporting the highest-rated business processes) and which threat sources matter most, and it supplies data classification and impact context that helps rate design threats consistently.

Choosing the right activity: decision criteria

Small versus large organisations: a small organisation may run both through one person and one spreadsheet, which is fine provided the escalation rule exists. A large organisation needs a threat modelling programme embedded in the development lifecycle, a separate risk function, and tooling that links model IDs to register IDs. For risk method choice, see Risk Assessment Methods Compared.

Worked scenario: a payments API

A product team is building a partner payments API. The threat model, built from the data flow diagram during design, finds seven threats. Five are mitigated in design: mutual TLS between partner and gateway, object-level authorisation checks on every request, signed request bodies, rate limiting and structured audit logging. Each becomes a requirement with a test.

Two remain. First, partner API keys are long-lived because two partners cannot yet support short-lived tokens; the team proposes deferring rotation for six months. Second, the fraud scoring service is run by a supplier whose outage would stop payments; the team transfers that dependency to the supplier contract.

Under the escalation rule, both go to the risk register. The first becomes a risk statement about credential compromise leading to fraudulent payment instructions, owned by the head of payments, with a six-month acceptance expiry and compensating controls (IP allow-listing, anomaly alerts on key use). The second becomes a third-party availability risk linked to the supplier record. In the next enterprise risk assessment, the risk function notices three other services with long-lived partner keys and raises a systemic risk on machine credential lifetimes, funded as a platform fix. Without the link, the register would have held only a generic "fraud" risk and the pattern would have stayed invisible.

Where identity fits

Identity is where threat models and risk registers most often diverge. Threat models routinely surface service accounts, API keys and tokens as trust boundaries, yet risk registers rarely hold a risk about non-human identity sprawl or credential lifetime because no single system owns it. Escalating identity findings as systemic risks closes that gap. See the AI Agent Threat Model Template for agent identities.

Implementation roadmap

1. Inventory current practice (month 1). Find which teams threat model, in what format, and how the risk register is populated today.
2. Publish the escalation rule and rating translation (month 1 to 2). Agree them jointly between the AppSec lead and the risk owner, and add them to the secure development and risk management policies.
3. Pilot with two or three teams (months 2 to 4). Run escalations end to end, measure volume, and adjust the threshold if the register floods or stays empty.
4. Add traceability (month 4). Add reference fields for model and threat IDs in the register and register IDs in the threat modelling tool or template.
5. Scale and review (month 5 onwards). Extend to all teams, add a quarterly review of systemic patterns across models, and roll back to manual escalation review if tooling integration proves unreliable.

Detection and measurement

• Threat model coverage: percentage of systems supporting high-rated business processes with a current threat model (updated within the agreed period or since the last significant change).
• Escalation rate: share of threat model findings escalated to the register; near zero or very high both suggest a broken rule.
• Traceability: percentage of technology risk register entries that reference a threat model, assessment or other evidence source.
• Acceptance expiry compliance: percentage of accepted or deferred findings reviewed before their expiry date.
• Systemic risks raised: number of cross-model patterns raised as enterprise risks each year.

Common failure patterns

• Using a risk assessment as a design review: a system is approved on a register rating with nobody examining its data flows or trust boundaries.
• Threat models that end at the diagram: threats listed, no responses, no requirements, no owner.
• Silent acceptance: developers accept residual risk inside the model with no business owner ever seeing it.
• Register flooding: every STRIDE item copied into the register, so meaningful risks are buried and the register loses credibility.
• Incompatible scales: threat model "high" means something different from register "high", so escalated items are misjudged.
• Stale models: the system changed but neither the model nor the linked risk entries did.

Framework mapping

Practitioner checklist

• Threat model every new system and significant change during design, and update the model on change.
• Record a response for every threat: mitigate, eliminate, transfer or accept, with reasons.
• Publish an escalation rule that sends accepted, deferred and transferred findings above a threshold to the risk register.
• Publish one translation between threat model ratings and register likelihood and impact.
• Rewrite escalated threats as business risk statements with a named owner.
• Keep model and register IDs cross-referenced in both directions.
• Give every acceptance an expiry date that reopens both records.
• Review threat models quarterly for systemic patterns and raise them as enterprise risks.
• Use enterprise risk ratings to decide which systems get the deepest threat models.

Standards and references

• NIST: SP 800-30 Rev. 1 Guide for Conducting Risk Assessments
• NIST: IR 8286 Rev. 1 Integrating Cybersecurity and Enterprise Risk Management
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (RA-3, SA-11(2))
• ISO: ISO/IEC 27005:2022 Guidance on managing information security risks
• OWASP: Threat Modeling Cheat Sheet
• Threat Modeling Manifesto
• NIST: SP 800-218 Secure Software Development Framework

Related NHI Mgmt Group resources: Threat Modelling Guide, NIST SP 800-30 Risk Assessment Guide, Risk Register Template, Threat Model Template, Top-Down vs Bottom-Up Cyber Risk Assessment.