NIST SP 800-30 Risk Assessment Guide: Threats, Likelihood, Impact and Risk Ratings

Many risk registers are a list of scary nouns with a red, amber or green label, and nobody can explain how a rating was reached or why it changed. NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments, gives a repeatable method: model threat sources and threat events, account for vulnerabilities and predisposing conditions, estimate likelihood and impact on defined scales, and combine them into a risk level that can be defended to an auditor or a board. This guide walks through the method task by task, shows how to adapt it to identities and non-human identities (NHIs), and explains the evidence an assessment should leave behind. It is for risk analysts, security architects, GRC teams and system owners. How assessment results feed authorisation decisions across a system's life cycle is the subject of the separate NIST Risk Management Framework (SP 800-37) Guide; this page is about doing the assessment itself.

Key takeaways

• Risk has defined parts: SP 800-30 treats risk as a function of the likelihood that a threat event occurs and results in adverse impact, and the size of that impact.
• Four steps, fifteen tasks: prepare, conduct, communicate and maintain, with the preparation tasks (purpose, scope, assumptions, sources, risk model) deciding whether results are comparable.
• Scales must be written down: every factor gets a qualitative scale and semi-quantitative equivalents, so two analysts reach the same rating from the same facts.
• Use two analysis orientations: NIST recommends combining threat-oriented, asset/impact-oriented or vulnerability-oriented analysis to reduce blind spots.
• Assessments age: step 4 requires monitoring the risk factors and updating results, which is where most programmes fail.

What it is and who it applies to

SP 800-30 Rev. 1 was published on 17 September 2012, superseding the 2002 original. It amplifies SP 800-39, Managing Information Security Risk, which places risk assessment as one of four components of risk management (frame, assess, respond, monitor) across three tiers: organisation (Tier 1), mission/business process (Tier 2) and information system (Tier 3). The publication defines risk assessment as the process of identifying, estimating and prioritising information security risks.

• Mandatory audience: US federal agencies, for whom it is the referenced method behind control RA-3 Risk Assessment and the risk assessment tasks of the RMF Prepare step.
• Voluntary audience: any organisation that wants a documented, repeatable method. It is often used alongside ISO/IEC 27005 to satisfy ISO/IEC 27001 clause 6.1.2.
• Current status (checked 24 October 2026): Rev. 1 is the current final version. Its CSRC page lists no newer revision, draft or withdrawal, and no SP 800-30 draft appears in the CSRC list of drafts open for comment. A 2012 publication predates cloud, SaaS sprawl and AI agents, so organisations need to supply current threat information themselves. Check CSRC before relying on this status.
• What it is not: it is not a control assessment method (SP 800-53A tests whether controls work) and not a quantitative financial model, although it accepts quantitative inputs. See the Cyber Risk Quantification Guide.

Structure and key requirements

The risk model

The four steps and their tasks

Assessment and analysis approaches

Scales and the risk determination

Each assessable factor has one qualitative scale (very low, low, moderate, high, very high) and two semi-quantitative scales, the most granular being 0-100. The example scales in the appendices bin values as very high 96-100 (10), high 80-95 (8), moderate 21-79 (5), low 5-20 (2) and very low 0-4 (0). Likelihood is assessed twice for each threat event: the likelihood that it is initiated (adversarial) or occurs (non-adversarial), and the likelihood that it then causes adverse impact. These combine into an overall likelihood, which is then combined with impact in a matrix to give the level of risk. Organisations may change the bins, but they must write them down before the assessment starts (task 1-5), and the appendices (D threat sources, E threat events, F vulnerabilities and predisposing conditions, G likelihood, H impact, I risk determination, K report contents) provide templates to adapt.

Record uncertainty alongside each rating. SP 800-30 lists sources such as incomplete knowledge of threats, undiscovered vulnerabilities and unrecognised dependencies, and an honest uncertainty note is more useful to a decision maker than false precision.

Worked example: one threat event

The table below shows a single worksheet row for a Tier 3 assessment of a data analytics platform, using qualitative labels with the semi-quantitative values in brackets. It is illustrative: the ratings depend on the organisation's own scales and evidence.

Writing the row this way shows the decision maker which factor a proposed control changes. Moving the service account to key pair authentication lowers the likelihood of adverse impact; it does nothing to the threat source, which is why the threat rating stays the same on reassessment.

Identity and NHI requirements

The method is generic, so identity-specific threats only appear if the assessor puts them into tasks 1-4 and 2-2. Practical additions for a modern environment:

• Threat event catalogue: add events for stolen or leaked machine credentials, OAuth token theft, abuse of trusted relationships (T1199) and compromised software supply chain (T1195.002), mapped to ATT&CK so detection teams can link risks to coverage.
• Predisposing conditions: count unowned service accounts, long-lived API keys, accounts without MFA and integrations with broad scopes. These raise likelihood across many events at once. See the Service Account Security Guide.
• Impact paths: rate impact on what the identity can reach, not on the host it lives on. A low-value build server holding a publishing token has the impact of every downstream consumer.
• Supply chain: RA-3(1) Supply Chain Risk Assessment extends the analysis to suppliers and their access. See the Third-Party Risk Management Guide.

The Snowflake breach is a textbook predisposing condition: according to Mandiant, the affected customer accounts had no MFA, unrotated credentials and no network allow lists, and at least 79.7% of the accounts used had prior exposure in infostealer logs. A threat-oriented assessment that included infostealer credential reuse as a threat event would have rated that likelihood very high for any single-factor account.

Implementation steps

1. Write the assessment charter (tasks 1-1 to 1-3). State the decision the assessment supports (authorisation, investment, risk acceptance), its tier, scope boundary, time horizon and constraints. One page is enough.
2. Fix the risk model and scales (task 1-5). Adopt or adapt the SP 800-30 appendix scales, publish them, and get the risk owner's agreement before any rating is made. Changing scales mid-assessment invalidates comparisons.
3. Assemble information sources (task 1-4). Threat intelligence feeds and sector advisories (PM-16 Threat Awareness Program), vulnerability scan output (RA-5), asset and identity inventories, criticality analysis (RA-9) and incident history.
4. Run a facilitated workshop for tasks 2-1 to 2-6. Use a structured worksheet per threat event: source, event, relevant vulnerabilities and conditions, likelihood of initiation, likelihood of impact, impact, risk, uncertainty. Pilot it on one system before scaling.
5. Calibrate. Have a second analyst rate a sample independently; where ratings differ by more than one level, tighten the scale definitions.
6. Communicate (tasks 3-1, 3-2). Give decision makers a ranked list with recommended responses (accept, avoid, mitigate, share or transfer) and feed accepted risks into the risk register. See the Risk Register Template.
7. Maintain (tasks 4-1, 4-2). Define triggers for reassessment: major architecture change, new threat intelligence affecting a rated event, a significant incident, or a fixed review period.

Rolling back: if the first workshop produces ratings nobody trusts, revert to qualitative scales only and fewer, better-defined threat events, then reintroduce semi-quantitative values once calibration improves.

Decision guidance by organisation size

Evidence and assessment

An assessment that cannot be reproduced will not survive an audit. Keep:

• The charter and risk model: purpose, scope, assumptions, constraints, information sources and scales (task 1 outputs).
• Worksheets: one row per threat event with every factor rating, the rationale and the uncertainty note.
• The report: SP 800-30 Appendix K outlines an executive summary, a main report and supporting appendices; keep the same structure each cycle so results can be compared.
• Response decisions: who accepted which risk, with what conditions (RA-7 Risk Response) and links to remediation tickets.
• Maintenance log: dates and triggers of each update (task 4-2).

Metrics

• Currency: percentage of in-scope systems with a risk assessment updated within the agreed period.
• Calibration: share of sampled ratings where two independent analysts agree within one level.
• Coverage: percentage of threat events mapped to ATT&CK techniques with detection coverage recorded.
• Response follow-through: percentage of high and very high risks with an owner and an approved response.
• Trigger latency: days between a qualifying change or incident and reassessment.

Mapping to other frameworks

For the control catalogue behind these IDs see the NIST SP 800-53 Guide; for the CSF outcomes see the NIST CSF 2.0 Guide. AI systems need additional harm categories that SP 800-30 does not define; see the AI Risk Assessment Guide.

Common pitfalls

• No written scales: "high" means different things to each analyst, so ratings cannot be compared or defended.
• Asset lists that omit identities: the Microsoft Midnight Blizzard breach started from a legacy non-production test tenant account without MFA and a legacy test OAuth application with elevated access, the kind of asset an assessment scoped to "production systems" never rates.
• Only one orientation: a vulnerability-only assessment ranks scanner findings and misses design risks such as trusted update channels. The SolarWinds supply chain compromise came through signed, normal-looking updates, a threat event no scan would surface.
• Single likelihood number: collapsing initiation and impact likelihood hides where controls actually reduce risk.
• No uncertainty statement: decision makers read precise-looking scores as facts.
• Never maintained: skipping step 4 leaves the register describing last year's environment.

Practitioner checklist

• Confirm on CSRC that SP 800-30 Rev. 1 is still current before each assessment cycle.
• Write a one-page charter covering purpose, tier, scope, assumptions and constraints.
• Publish qualitative and semi-quantitative scales for likelihood, impact and risk before rating.
• Maintain a threat event catalogue that includes NHI and supply chain events mapped to ATT&CK.
• Record predisposing conditions such as unowned service accounts and single-factor access.
• Assess likelihood of initiation and likelihood of impact separately.
• Use at least two analysis orientations and calibrate ratings with a second analyst.
• Document uncertainty for every high and very high risk.
• Assign an owner and response to every high risk and record it in the register.
• Define and log reassessment triggers.

Standards and references

• NIST: SP 800-30 Rev. 1, Guide for Conducting Risk Assessments
• NIST: SP 800-39, Managing Information Security Risk
• NIST: SP 800-37 Rev. 2, Risk Management Framework
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: SP 800-53A Rev. 5, Assessing Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Valid Accounts: Cloud Accounts

Related NHI Mgmt Group resources: NIST SP 800-53 Guide · Risk Register Template · Cyber Risk Quantification Guide · Third-Party Risk Management Guide · Security Exceptions and Risk Acceptance Guide