How do you run a security threat assessment? NIST 800-30 steps

A security threat assessment identifies the threats to your systems, the weaknesses they could exploit, how likely each is, and how much harm would follow. NIST SP 800-30 frames this as a four-step risk assessment: prepare, conduct, communicate the results and maintain the assessment over time.

What are the key terms?

NIST defines a threat as any circumstance or event with the potential to adversely affect operations, assets, individuals, other organizations or the Nation through an information system, by unauthorized access, destruction, disclosure, modification of information, or denial of service. Risk is a function of the likelihood of a threat event occurring and the potential adverse impact if it does.

Getting the vocabulary straight prevents the common muddle where "threat," "vulnerability" and "risk" are used for the same thing. A threat is the thing that might act. A vulnerability or predisposing condition is the weakness. Risk is the combination of likelihood and impact.

Who or what are the threats?

NIST's taxonomy of threat sources has four types: adversarial (individuals, groups, organizations or states, including insiders, outsiders, suppliers and partners), accidental (for example a user making an error), structural (failures of information technology and other equipment) and environmental (natural or man-made events). A good assessment covers all four, since an accidental deletion by a trusted administrator causes damage as well.

For adversarial sources, NIST suggests describing capability, intent and targeting.

What are the four steps?

1. Prepare. Define the purpose, scope, assumptions, constraints and the information sources you will use, and the risk model and scales. Write down what decision the assessment will inform.
2. Conduct. Identify threat sources and events, identify vulnerabilities and predisposing conditions, determine the likelihood of occurrence, determine the magnitude of impact, then determine risk.
3. Communicate. Share results with the decision makers in terms they can act on, and keep the evidence.
4. Maintain. Keep the assessment current by monitoring risk factors and updating when systems or threats change.

NIST says the process describes the essential elements and is not meant to limit organizations' flexibility. It also notes that SP 800-39 supersedes 800-30 as the primary source of guidance on information security risk management, so read the two together.

What does one look like?

Constructed example. A 40-person company assesses its customer portal.

• Scope: the portal, its database and the staff who administer them.
• Threat events: credential stuffing against customer logins (adversarial), an administrator misconfiguring storage permissions (accidental), a cloud region outage (environmental).
• Vulnerabilities and conditions: no lockout on login attempts, no review of storage permissions, a single region.
• Likelihood and impact: NIST's scales run from very low to very high. The team rates credential stuffing high likelihood and moderate impact, misconfiguration moderate and high, outage low and moderate.
• Result: a ranked list, with owners and actions. Lockout and review come first, since they are cheap and address the two likeliest events.

The team writes down its assumptions and reruns the assessment when the portal adds a payments feature.

What makes assessments fail?

Scope that is too wide to finish. Scales nobody agrees on. Results with no owner. And the assessment that sits in a folder: threat assessments go stale as quickly as the systems they describe.

How to check or apply this

1. Pick one system and write the decision the assessment will support.
2. Define a simple five-level scale for likelihood and impact, with written meanings.
3. List threat events across all four source types, not just attackers.
4. For each, record the weakness that would let it succeed and the controls already in place.
5. Rate likelihood and impact, then rank.
6. Assign an owner and a date to the top items.
7. Set a re-review trigger: a new feature, a new vendor, a major incident.

Quick check

Sources

• NIST SP 800-30 Rev 1, Guide for Conducting Risk Assessments

Last reviewed: 18 October 2026.