NIST SP 800-30
Risk assessment on one operating record

NIST SP 800-30 risk assessment methodology explained

NIST Special Publication 800-30 Revision 1 (Guide for Conducting Risk Assessments, published September 2012) is the federal guide to the risk assessment process for information systems and the organisations that operate them. The publication sits underneath NIST SP 800-39 (Managing Information Security Risk) at the enterprise layer and feeds NIST SP 800-37 (the Risk Management Framework) at the operating layer. 800-30 specifies a four-step assessment process (Prepare, Conduct, Communicate, Maintain), a risk factor decomposition (threat source, threat event, vulnerability, predisposing condition, likelihood, impact), a taxonomy of threat sources, and a flexible analytical approach that accommodates qualitative, semi-quantitative, and quantitative analysis.

For CISOs, GRC owners, vulnerability management teams, AppSec teams, security engineering teams, security architects, enterprise risk teams, and the federal-side programmes operating under FISMA, FedRAMP, or CMMC, 800-30 is the methodology that produces the assessment evidence the rest of the programme references. Programmes already operating against NIST SP 800-37 (RMF), NIST SP 800-53, ISO 27001, or ISO 31000 use 800-30 as the underlying assessment process the higher-level framework reads against. The methodology is not a replacement for FAIR or COSO ERM; FAIR is one of the quantitative methods 800-30 accommodates, and COSO ERM consumes the 800-30 outputs into the enterprise risk portfolio.

Three-tier risk management context: where 800-30 sits

800-30 is one of the assessment processes inside the broader multi-tier risk management context NIST SP 800-39 describes. The three tiers carry different decisions and consume different assessment outputs. 800-30 is most commonly applied at Tier 3 (information system level) but uses the same task structure at all three tiers.

The four-step assessment process: Prepare, Conduct, Communicate, Maintain

The 800-30 process is four sequential steps, each producing named outputs the next step reads against. The steps are sequential in dependency, not in calendar time: Maintain produces refreshed inputs that re-enter Prepare for the next assessment cycle, so the methodology operates as a loop rather than a one-off project. Each step is described in detail in 800-30 Section 3.

Threat source taxonomy: adversarial, accidental, structural, environmental

800-30 Appendix D defines four categories of threat source. The categorisation is the methodology backbone: assessments that focus only on adversarial threats and skip the other three categories miss the failure modes that drive most observed incidents. The taxonomy is meant to be exhaustive across the four categories, with the analyst sourcing per-category characterisation evidence per assessment.

Risk factor decomposition the methodology expects

The 800-30 risk model decomposes each per-event risk determination into the named factors below. The decomposition is what lets the decision-maker push back on specific inputs rather than on the headline number, and what lets the per-cycle refresh produce a delta on the changed factors rather than a rebuild of the whole assessment. Each factor is described in 800-30 Section 2.3 and Appendices D through I.

• Threat source: the entity or condition that initiates the threat event. Threat sources are catalogued by type (adversarial, accidental, structural, environmental) and characterised by relevant attributes (capability, intent, targeting for adversarial sources; range of effects for accidental and structural sources; consequence severity for environmental sources).
• Threat event: the activity the threat source initiates that has a potential adverse effect. Threat events are described in terms of the action taken, not in terms of the source taking it; the same threat event can be initiated by different sources, and the methodology preserves this separation so the assessment can be reused across multiple source scenarios.
• Vulnerability: a weakness in an information system, system security procedure, internal control, or implementation that could be exploited by a threat source. Vulnerabilities cover technical vulnerabilities (the kind a scanner detects), procedural vulnerabilities (the kind audits surface), and architectural vulnerabilities (the kind threat modelling surfaces). The assessment reads vulnerability against the specific threat event under analysis rather than as a general statement.
• Predisposing condition: a condition that, in combination with a vulnerability and a threat event, can elevate the likelihood of the event occurring or the magnitude of the consequence. Predisposing conditions include the absence of a control, the presence of an exception, the geographic location of the system, the dependencies on external services, and the privileged access design.
• Likelihood of occurrence: a weighted risk factor based on an analysis of the probability that a given threat event is capable of exploiting a given vulnerability or set of vulnerabilities. Likelihood is assessed at two layers: the likelihood the threat source initiates the threat event (initiation likelihood) and the likelihood the threat event results in an adverse impact given vulnerabilities and predisposing conditions (resulting-impact likelihood).
• Impact: the magnitude of harm that can be expected to result from a threat event. Impact reads against the harm to operations (mission, functions, image, reputation), the harm to assets, the harm to individuals, the harm to other organisations, and the harm to the nation. The methodology supports both qualitative impact scales (very low to very high) and quantitative impact estimation (financial loss expectancy).
• Risk: a function of likelihood of occurrence and resulting impact. The combination is the per-threat-event risk determination that feeds the risk response decision in Step 3. The 800-30 methodology does not prescribe a single combination function; the assessment plan in Step 1 names the function the assessment will use, and the same function is applied consistently across the per-event determinations.

Qualitative, semi-quantitative, and quantitative analysis

800-30 is deliberately analytical-approach-agnostic. The same risk factor decomposition supports three analytical approaches; the assessment plan in Step 1 names which approach the assessment will use. Programmes typically start with qualitative analysis and adopt semi-quantitative or quantitative approaches for the scenarios where the analytical investment is justified by the decision the assessment supports.

CVE, CVSS, EPSS, KEV, and SSVC as 800-30 inputs

The vulnerability scoring and prioritisation signals modern programmes already use feed directly into the 800-30 factor decomposition. The discipline is to treat them as inputs to the assessment rather than as the assessment itself; the methodology adds the threat source characterisation, the predisposing conditions, the impact analysis, and the audience-specific communication that the vulnerability scores alone do not produce.

• CVSS scores feed the vulnerability factor for technical vulnerabilities the assessment reads against. The CVSS Base, Temporal, and Environmental metrics each contribute different signals: Base for the unmitigated severity, Temporal for the current exploit and remediation context, Environmental for the per-system context the assessment is bounded against.
• EPSS estimates feed the initiation likelihood factor for adversarial threat events tied to specific vulnerabilities. EPSS is not the threat event frequency; it is the probability the vulnerability is exploited within a defined time window, which is one input the analyst combines with the threat source characterisation to estimate the per-event likelihood.
• CISA KEV catalogue entries elevate the initiation likelihood factor for the specific vulnerabilities the catalogue lists. KEV is the active-exploitation signal; vulnerabilities on KEV warrant the high or very high initiation likelihood reading regardless of the EPSS estimate, because active exploitation in the wild is observed evidence rather than a probability estimate.
• SSVC decisions are not 800-30 inputs themselves; they are decisions the 800-30 assessment can feed. SSVC produces a per-vulnerability decision (Track, Track*, Attend, Act) for stakeholder-specific contexts and reads the same input set the 800-30 vulnerability factor reads against.
• Threat intelligence feeds (vendor subscriptions, ISAC sharing, regulator advisories) provide the threat source characterisation data the assessment reads against. The discipline is to source per-source data per assessment cycle rather than to carry the prior cycle characterisation forward without re-validation.
• Internal incident history provides the calibration data for the likelihood and impact estimates the assessment produces. Programmes with a documented incident record can validate per-source characterisations against observed events; programmes without an incident record carry higher uncertainty in the estimates and must reflect that uncertainty in the confidence band the analysis reports against.

800-30 next to RMF, 800-53, ISO 27001, ISO 27005, ISO 31000, FAIR, and COSO ERM

800-30 is the assessment process, not the broader risk management framework. The publication sits inside a broader risk management ecosystem with named relationships to the adjacent standards. Mature programmes typically operate several of these standards together; 800-30 is the assessment engine the rest of the ecosystem reads against.

• NIST SP 800-39 (Managing Information Security Risk) sits above 800-30 at the strategic enterprise risk management layer and defines the three-tier context 800-30 operates within.
• NIST SP 800-37 (RMF) sits below 800-30 as the operating sequence for federal systems. The 800-30 assessment feeds the RMF Categorise step (FIPS 199 categorisation), the Select step (control tailoring), the Authorise step (residual-risk determination), and the Monitor step (ongoing risk reassessment).
• NIST SP 800-53 is the control catalogue the RMF Select step picks from. The 800-30 assessment informs which baseline (low, moderate, high) the system selects and which tailoring decisions are justified by the per-system risk determinations.
• ISO 27001 clause 6.1.2 requires a documented information security risk assessment process. 800-30 satisfies the methodological requirement clause 6.1.2 reads against, and the per-assessment evidence reads cleanly into the ISO 27001 Statement of Applicability and the residual risk treatment plan.
• ISO/IEC 27005 (Information security risk management) is the ISO-side counterpart to 800-30 with a parallel process structure and a similar risk factor decomposition. Programmes that operate primarily under ISO 27001 typically reference 27005 for the process; programmes that operate under FISMA or sell to federal customers reference 800-30. The two are deliberately compatible.
• ISO 31000 is the enterprise risk management umbrella standard. 800-30 sits inside the ISO 31000 assessment sub-process (identification, analysis, evaluation), and ISO 31000 wraps 800-30 with the broader framework components (leadership, integration, design, implementation, evaluation, improvement) the methodology does not address.
• FAIR is the most common operationalisation of the quantitative path within 800-30. Federal programmes that require quantitative analysis typically reference 800-30 for the process and FAIR for the method.
• COSO ERM is the enterprise risk management framework boards and audit committees read against. 800-30 outputs feed COSO ERM Principle 11 (Assesses Severity of Risk) and Principle 14 (Develops Portfolio View).

Recurring failure modes 800-30 programmes hit

Programmes that struggle with 800-30 typically hit a small set of recurring failure modes. Naming the failure modes upfront lets the programme design the assessment operating model to avoid them rather than discovering them at the regulator examination or the AO defence.

Evidence the methodology expects to see

A defensible 800-30 programme produces a stable evidence set per assessment cycle. The same set reads cleanly under NIST SP 800-37 (RMF), NIST SP 800-53, ISO 27001 clause 6.1.2, ISO 27005, ISO 31000, COSO ERM, FedRAMP, CMMC, SOC 2, PCI DSS, and the regulator-side examinations that consume risk assessment evidence as part of the broader programme review.

• Risk assessment plan per Step 1: purpose, scope, assumptions and constraints, sources of information, risk model, analytical approach, and the decisions the assessment is meant to inform
• Risk assessment results per Step 2 with the per-threat-event record: the threat source, the threat event description, the vulnerabilities and predisposing conditions, the initiation likelihood, the resulting-impact likelihood, the impact magnitude, and the determined risk level
• Threat source catalogue per assessment with the per-source characterisation: capability, intent, and targeting for adversarial sources; range of effects for accidental and structural sources; consequence severity for environmental sources; per-source confidence in the characterisation
• Vulnerability catalogue per assessment with the per-vulnerability record: technical vulnerabilities sourced from scanner output, procedural vulnerabilities sourced from audit findings, architectural vulnerabilities sourced from threat modelling, per-vulnerability validation evidence
• Predisposing conditions record per assessment with the per-condition rationale, the per-condition impact on likelihood and impact estimates, and the linkage to the operating evidence (exception register entries, control deviation records, geographic context, external service dependencies)
• Communication record per Step 3: the audience-specific outputs, the interrogation evidence (questions raised by decision-makers, analyst responses, input revisions arising from the exchange), and the per-audience decision record arising from the communication
• Maintenance record per Step 4: the per-cycle refresh triggers met, the input deltas applied, the analyst sign-off per refresh, the impact on the prior risk determinations, and the communication to the decision-makers who relied on the prior assessment
• Analyst sign-off record per assessment with the analyst identity, the training and calibration evidence, the input rationale per leaf factor, the confidence band per estimate, and the reviewer counter-signature
• Decision record per assessment: which decisions the assessment informed, the disposition per decision (acceptance, avoidance, mitigation, sharing, transfer), the per-decision rationale, the per-disposition implementation reference, and the per-decision review cadence
• Cross-framework reference per assessment: the ISO 31000 process step the assessment maps to, the NIST SP 800-37 RMF step it feeds (Categorise, Select, Authorise, Monitor), the NIST CSF 2.0 outcome category it supports, the ISO 27001 clause 6.1.2 evidence it produces, the COSO ERM principle it informs, and the regulatory read it supports

How 800-30 reads across enterprise security functions

800-30 is a cross-functional methodology. The same assessment record reads differently depending on the function that holds the work. Programmes that run 800-30 as a GRC exercise alone lose the engineering depth the inputs require; programmes that run it as an engineering exercise alone lose the governance depth the audience-tailored communication is meant to add. The named functions below own different parts of the same assessment record.

Running 800-30 on SecPortal

SecPortal is built around the operating record an 800-30 assessment programme reads against: the engagement carries the per-assessment lifecycle from Prepare through Maintain, the findings record carries the vulnerability state feeding the assessment inputs, the documents area carries the assessment plan and the per-cycle artefact set, and the activity log carries the assessment audit trail. The platform alignment below maps the verified product capabilities to the 800-30 process so the methodology is held on one operating record rather than across a separate analytical environment that drifts from the live posture.

• Engagement management as the workspace anchor for the assessment lifecycle, with the per-assessment Prepare plan, the Conduct execution record, the Communicate audience pack, and the Maintain refresh cadence tracked as a single engagement rather than as four parallel projects that drift apart
• Findings management with CVSS 3.1 calibration so the vulnerability inputs the 800-30 assessment reads against carry the same severity vocabulary the scanner intake, the manual finding triage, the exception register, and the remediation SLA record use
• Compliance tracking across NIST SP 800-37 (RMF), NIST SP 800-53, NIST SP 800-171, NIST CSF 2.0, FedRAMP, CMMC, ISO 27001, SOC 2, PCI DSS, and the additional framework catalogues so the 800-30 risk determinations feed the parallel framework reads without rebuilding the underlying input set
• Authenticated scanning and external scanning so the vulnerability catalogue Step 2 reads against carries live posture evidence on the assessed scope rather than a snapshot from the assessment week, with the per-asset coverage record archived per refresh
• Code scanning via Semgrep against connected repositories so the AppSec input feeding the vulnerability and predisposing conditions records for application-system assessments reads against the live code state rather than against a prior commit
• Repository connections via GitHub, GitLab, and Bitbucket OAuth so the architectural vulnerability inputs and the supply-chain predisposing conditions read against the same source-control evidence the SDLC programme already produces
• Document management for the assessment plan, the threat source catalogue, the vulnerability catalogue, the predisposing conditions record, the per-assessment results, the audience-specific communication outputs, and the maintenance record so the 800-30 evidence package lives on the operating record rather than across a folder hierarchy that drifts from the assessment reality
• Activity log with CSV export so every change to an assessment scope, an input source, an analyst sign-off, a determined risk level, a disposition, or a refresh trigger is reproducible from one source, which is the assessment audit trail the methodology defence reads against
• Multi-factor authentication for workspace access so the analyst sign-off, the reviewer counter-signature, and the disposition approval the maintenance record reads against carry the authentication evidence the audit committee expects
• Team management with RBAC so the analyst role, the reviewer role, the approver role, and the decision-maker role the assessment plan names are enforced at the workspace layer rather than at the per-document level
• AI report generation that turns the per-assessment record into the audience-specific outputs the Communicate step expects: the technical assessment narrative for the system owner, the residual-risk summary for the authorising official, the enterprise-risk reading for senior leadership, the regulator-facing summary, and the board-level briefing pack
• Retesting workflows paired to the mitigation commitments arising from the assessment so the closure evidence the next maintenance cycle reads against carries the verify-after-fix record rather than a status statement that has drifted from the operating reality

What SecPortal does not do

SecPortal is the operating record an 800-30 assessment programme is held on, not the analytical engine that produces quantitative outputs. The workspace does not run a built-in Monte Carlo simulation engine, does not maintain a built-in threat intelligence catalogue, does not federate with asset inventory or CMDB systems, does not provide an automated risk register editor with quantitative combination logic, does not consume real-time CISA KEV or FIRST EPSS feeds through a packaged API, does not auto-route exception approvals through a workflow engine, and does not integrate with GRC platforms (Archer, ServiceNow GRC, Onspring), ticketing systems (Jira, ServiceNow ITSM), or SIEM and SOAR platforms. The discipline SecPortal supports is holding the assessment plan, the per-event results, the audience-specific communication outputs, and the maintenance record as workspace evidence the methodology defence reads against; the analytical engine, the external intelligence feeds, and the GRC tool integrations belong to other systems the programme operates alongside SecPortal.

Related reading on SecPortal

• NIST SP 800-37 (RMF) is the operating sequence 800-30 assessments feed into through the Categorise, Select, Authorise, and Monitor steps.
• NIST SP 800-53 is the control catalogue the RMF Select step picks from, with the baseline informed by the 800-30 risk determinations.
• ISO 31000 is the enterprise risk management umbrella 800-30 operates inside as the assessment sub-process.
• ISO/IEC 27005 is the ISO-side counterpart with deliberately compatible process structure that ISO 27001-aligned programmes reference instead of 800-30 for clause 6.1 evidence.
• ISO 27001 clause 6.1.2 reads against 800-30-aligned assessments as the methodological satisfaction of the risk assessment process requirement.
• FAIR (Factor Analysis of Information Risk) is the most common operationalisation of the quantitative path within 800-30.
• COSO ERM consumes 800-30 outputs into the enterprise risk portfolio Principles 11 and 14 read against.
• FedRAMP operates 800-30-aligned assessments as part of the authorisation package every cloud service provider produces.
• CMMC reads 800-30-aligned assessment evidence as part of the contractor maturity examination at the higher CMMC levels.
• NIST AI Risk Management Framework extends the assessment process to AI components with the MEASURE function reading against the 800-30-style analytical approach catalogue.
• Cybersecurity risk assessment guide covers the wider risk assessment landscape, the methodology comparison, and the operating model that survives the second cycle.
• Cyber risk quantification guide covers the quantitative path within 800-30 and the FAIR adoption model that produces the board-readable financial output.
• Risk assessment operating model covers the per-cycle refresh cadence, the audience-tailored communication, and the maintenance record the methodology expects.
• Security leadership reporting workflow carries the audience-tailored communication outputs Step 3 produces for the executive, board, and audit committee audiences.
• Vulnerability acceptance and exception management carries the disposition record the assessment results feed into when the decision is to accept rather than mitigate.
• Control mapping cross-framework crosswalks carries the per-assessment cross-framework reference that lets 800-30 outputs feed parallel framework reads without rebuilding the underlying input set.
• Audit fieldwork evidence request fulfillment carries the assessor read against the per-assessment artefact set during ISO 27001, SOC 2, FedRAMP, CMMC, and PCI DSS examinations.
• Asset criticality scoring carries the per-asset criticality input feeding the impact factor 800-30 assessments read against.
• Threat-intelligence-driven prioritisation carries the threat source characterisation input feeding the initiation likelihood factor 800-30 assessments read against.
• SecPortal for CISOs covers the executive workspace that holds the 800-30 assessment programme alongside the operating record the assessments read against.
• SecPortal for GRC and compliance teams covers the GRC workspace that holds the cross-framework reconciliation 800-30 outputs consume into.