Threat modeling vs risk assessment: what is the difference?

Threat modeling looks at a specific system and asks what can go wrong and what you will do about it. A risk assessment ranks risks across a system or organization by likelihood and impact to guide decisions. Threat modeling feeds risk assessment with concrete scenarios, and risk assessment tells you which threats to fix first.

What is threat modeling?

OWASP describes threat modeling with four questions: What are we working on? What can go wrong? What are we going to do about it? Did we do a good job? The scope can be as small as a sprint or as large as a whole system, and the technique for finding threats can be a brainstorm, STRIDE, kill chains or attack trees. OWASP also warns that trying to evaluate every combination of threat agent, attack, vulnerability and impact is often a waste of effort, so refine the search space.

The unit is a design. The output is a list of threats and countermeasures for that design.

What is a risk assessment?

NIST SP 800-30 provides guidance for conducting risk assessments of federal information systems and organizations. It frames risk assessment as part of an overall risk management process at three tiers, giving senior leaders information to decide how to respond to risks. The unit is the organization, a business process or a system. The output is a ranked view of risk, with likelihood and impact, that supports decisions about what to accept, reduce, transfer or avoid.

How are they different in practice?

Level. Threat modeling is usually done by the team building the thing, at design time. A risk assessment is done with the business, and spans many systems.

Question. Threat modeling asks "how could this break?" Risk assessment asks "how much does it matter, and what should we do first?"

Output. A threat model gives specific scenarios and mitigations. A risk assessment gives priorities and decisions on acceptance.

Cadence. Threat models change when designs change. Risk assessments run on a schedule and after major changes.

A constructed example

Constructed example: a team designs a feature that lets customers upload CSV files for import. Their threat model, drawn on a whiteboard in an hour, lists four threats: malicious formulas in cells, oversized files exhausting memory, another tenant's file being read through a predictable URL, and a stale parsing library with a known flaw. They agree mitigations for each.

The security lead then runs a quarterly risk assessment across all products. The tenant isolation threat appears there as a risk with high impact and low likelihood after the mitigation, and the library flaw as medium. The assessment lets leadership see that tenant isolation across the platform matters more than the CSV feature's other items, and fund a platform wide fix.

Without the threat model, the assessment has no specifics. Without the assessment, the threat model has no priorities.

When do you do which?

Do a threat model when a design is new or changes in a way that touches trust boundaries: new data stores, new integrations, new authentication paths. Do a risk assessment on a calendar, when the business changes, and when a significant incident reveals a gap.

Neither replaces testing. Threat models are hypotheses, and the last OWASP question, did we do a good job, is where scans and tests come in. Safeguard's dependency scanning and reachability analysis can help check one class of threat, vulnerable components, against what your code actually calls.

What to do

1. Pick the next design change that crosses a trust boundary and threat model it in an hour.
2. Use OWASP's four questions as the agenda.
3. Write threats as scenarios with an owner and a mitigation.
4. Feed the threats into a risk register with likelihood and impact.
5. Review the register on a schedule with the business.
6. Check mitigations with tests and scans, then update the model.

Quick check

Sources

• Threat Modeling, OWASP
• NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments

Last reviewed: 18 October 2026.