NIST SP 800-30: the Guide for Conducting Risk Assessments, explained

NIST SP 800-30, "Guide for Conducting Risk Assessments," is the US National Institute of Standards and Technology's reference document for how to actually run a risk assessment, as opposed to how to manage risk at an organizational level more broadly. Its own abstract states its purpose is to provide "guidance for conducting risk assessments of federal information systems and organizations, amplifying the guidance in Special Publication 800-39." The current and only revision, Revision 1, was published in September 2012, superseding the original July 2002 edition; it has not been updated since. Although written for US federal agencies, the risk model and four-activity process it defines are widely used outside government as a vendor-neutral way to structure a security risk assessment.

What "amplifying SP 800-39" means

SP 800-30 does not stand alone. NIST's companion publication, SP 800-39, "Managing Information Security Risk: Organization, Mission, and Information System View," sets out the broader program: an "integrated, organization-wide program for managing information security risk" built on "a structured, yet flexible approach," explicitly positioned as something that "can be used as part of a more comprehensive Enterprise Risk Management (ERM) program." SP 800-39 defines risk management as happening across three tiers — the organization, the mission/business process, and the information system — and names risk assessment as one of four components of that program, alongside framing, responding to, and monitoring risk. SP 800-30 is the detailed how-to guide for that one component: it tells you how to actually conduct a risk assessment, not how to run the rest of the program around it.

The risk model: what feeds a risk level

SP 800-30 builds a risk assessment from a defined set of inputs rather than a single subjective judgment call:

Input	What it captures
Threat sources	The origin of a potential adverse event — adversarial, accidental, structural or environmental
Threat events	The specific event a threat source could cause
Vulnerabilities and predisposing conditions	Weaknesses that could be exploited, and conditions that make exploitation more or less likely
Likelihood	The probability a threat event occurs and results in an adverse impact
Impact	The magnitude of harm if the threat event succeeds

NIST's own glossary, sourced to SP 800-30 Rev. 1 and reused verbatim across SP 800-37 Rev. 2, SP 800-39 and SP 800-171 Rev. 3, defines risk assessment as "the process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of an information system," adding that it is synonymous with "risk analysis" and is "part of risk management" that "incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place." That last clause matters in practice: a risk assessment under SP 800-30 is never purely theoretical likelihood-times-impact math — it has to account for the controls, such as those catalogued in NIST SP 800-53, that are already planned or in place.

The process: prepare, conduct, communicate, maintain

SP 800-30's Chapter Three, "The Process," structures a risk assessment around four activities. It is worth being precise here, because NIST's own published abstract for the document describes this slightly differently — stating the guidance covers "each of the three steps in the risk assessment process (i.e., prepare for the assessment, conduct the assessment, and maintain the assessment)," treating communication as something that happens throughout rather than as its own numbered step. The document's chapter structure, by contrast, is commonly summarized as four distinct activities. Either framing describes the same underlying process:

Step	What it involves
Prepare for the assessment	Identify the assessment's purpose, scope, assumptions and constraints, the information sources to use, and the risk model to apply
Conduct the assessment	Identify threat sources and events, vulnerabilities and predisposing conditions, likelihood of occurrence, and the resulting impact and risk
Communicate the results	Share the assessment's findings and supporting risk-related information with decision-makers who need it
Maintain the assessment	Monitor the risk factors identified in the assessment on an ongoing basis, and update the analysis as conditions change

Assessments are not meant to be run once at a single scope. SP 800-39's three-tier model (organization, mission/business process, information system) means the same four-step process can run at each tier, with results from a system-level assessment rolling up to inform mission- and organization-level risk decisions, and organization-level risk tolerance decisions flowing back down to shape how lower-tier assessments are scoped.

Where this sits next to the Risk Management Framework and SP 800-53

Risk assessment is not a one-off report; it is one recurring activity inside NIST's broader Risk Management Framework (RMF), described in SP 800-37. The RMF's steps include categorizing a system, selecting applicable controls from the SP 800-53 control catalogue, implementing and assessing those controls, authorizing the system to operate, and monitoring it continuously — and risk assessment, in the SP 800-30 sense, is the activity that informs several of those steps, not a separate process run in isolation. Confirming the precise cross-reference wording SP 800-37's current revision uses to describe where SP 800-30-style assessment fits into the RMF's own step names is best done against the published SP 800-37 text directly; this guide has not independently verified that specific phrasing this run.

A workable starting point

1. Separate "assessment" from "management." If your organization only has a risk register and no documented process for how entries get there, you have skipped the SP 800-30 layer SP 800-39 assumes exists underneath it.
2. Name your tier before you start. An assessment scoped at the information-system level (a single product, a single firmware image) asks different questions than one scoped at the organization level — decide which one you are running before picking threat sources and impact criteria.
3. Treat "maintain" as a standing commitment, not a wrap-up task. A risk assessment that is never revisited after the initial report stops reflecting reality the moment a new vulnerability, threat actor technique, or compensating control appears.
4. Feed existing control evidence in, don't assess from zero. If controls from SP 800-53 or an equivalent catalogue are already documented, use that evidence directly in the "mitigations provided by security controls" step rather than re-deriving it.

SoftWSP builds risk assessments on real firmware SBOM, CVE and fleet-exposure evidence rather than a generic questionnaire, so the "conduct the assessment" step starts from actual data instead of assumptions: see device firmware security.

This guide summarises a public NIST publication; it does not constitute legal or compliance advice.