NIST SP 800-30

Determine likelihood and impact per NIST SP 800-30 Rev 1 Section 3.2 Step 4 (Likelihood) + Step 5 (Impact) + Appendix G (Likelihood) + Appendix H (Impact). Likelihood determination combines (a) likelihood of threat event initiation (adversarial capability + intent + targeting), (b) likelihood of threat event resulting in adverse impact given vulnerabilities and predisposing conditions, into an overall likelihood value. Impact determination assesses harm to operations, assets, individuals, other organisations, and the Nation from successful threat events, considering (a) confidentiality + integrity + availability impact on information and systems, (b) operational impact on mission and business functions, (c) financial impact, (d) regulatory and legal exposure, (e) reputational impact, (f) safety impact. Use the qualitative or semi-quantitative scales in Appendix G/H and adapt to organisat

• likelihood determination per scenario combining initiation likelihood and adverse-impact likelihood per Appendix G
• impact determination per scenario covering CIA + operational + financial + regulatory + reputational + safety per Appendix H
• documented choice between qualitative and semi-quantitative scales with conversion table where mixed
• likelihood and impact rationale captured in risk register

• scales mixed mid-assessment without documented conversion
• impact treated as CIA only ignoring operational + safety + reputational dimensions
• likelihood rationale not documented so estimates cannot be defended

Maintain the risk assessment per NIST SP 800-30 Rev 1 Section 3.3 Step 8 (Maintaining the Risk Assessment) and integrate with the NIST Risk Management Framework (SP 800-37) and continuous monitoring (SP 800-137). Maintenance must (a) trigger updates on significant change (system change, environment change, threat change, control failure, incident), (b) refresh annually at minimum even without trigger, (c) update the risk register on each control implementation, change, or failure, (d) feed risk assessment outputs into RMF Authorize step (information needed for authorising official ATO decision), (e) align with continuous monitoring strategy (NIST SP 800-137) so monitoring evidence updates assessment inputs automatically where possible. Documentation retention must support audit readiness with chain-of-custody from threat intelligence + vulnerability scan + control test through to risk re

• assessment update log triggered by change + incident + threat update + control failure
• annual refresh evidence per assessment
• continuous monitoring strategy citing SP 800-137 with feed to assessment inputs
• RMF Authorize step evidence using current assessment outputs
• documentation retention with chain-of-custody from intelligence + scan + test through risk register to authorisation

• assessments never updated after publication
• annual refresh skipped because no significant change triggered an update
• continuous monitoring evidence not flowing back to assessment inputs
• authorisation decisions made against stale assessments

Communicate risk per NIST SP 800-30 Rev 1 Section 3.3 Step 7 (Communicating and Sharing Risk Assessment Information). Communication must address (a) decision makers (system owner, mission owner, authorising official, Risk Executive Function, board) with appropriate tier-specific framing, (b) stakeholders inside and outside the assessment scope (shared service providers, mission partners, customers, regulators), (c) external sharing (CISA, sector ISACs, regulator reporting where required by statute or contract). Communication artefacts must include the risk assessment report, executive summary, risk register, prioritised risk list, recommended risk responses, residual uncertainty statement, and the next-assessment trigger conditions. Adopt a standard report template (per Appendix K Risk Assessment Reports) for consistency across assessments and tiers.

• risk assessment report per Appendix K template with executive summary + risk register + recommendations + uncertainty statement
• communication evidence to authorising official + Risk Executive Function + board
• external sharing log (CISA + sector ISAC + regulator) where statute or contract requires

• risk reports too technical for executive consumption
• external sharing obligations missed where statute or contract requires
• uncertainty and confidence not communicated alongside risk ratings

Determine risk per NIST SP 800-30 Rev 1 Section 3.2 Step 6 + Appendix I (Risk Determination Tables) and perform uncertainty and sensitivity analysis per Section 3.2 Step 6 guidance. Risk is a function of the likelihood that an adverse event will occur and the impact that would result. Capture overall risk per scenario using the risk determination tables in Appendix I (Risk Level Matrix combining likelihood and impact, both rated Very Low through Very High). Uncertainty analysis must document the assumptions made (threat source characterisation, control efficacy, dependency assumptions), the data quality (high, moderate, low) underlying each likelihood and impact estimate, and the residual uncertainty. Sensitivity analysis must identify scenarios where small changes in inputs produce large changes in risk and flag them as priority for refinement. Record risk rationale, assumptions, uncert

• risk determination per scenario using Appendix I risk-level matrix
• uncertainty statement per scenario citing assumption set + data quality + residual uncertainty
• sensitivity analysis output identifying scenarios where small input changes produce large risk swings
• risk register entries with full rationale chain

• risk determined without uncertainty statement so cannot be defended to auditor or regulator
• sensitivity analysis omitted so refinement priorities are unclear
• risk-level matrix not used consistently across assessments

Establish an organisation-wide risk management strategy per NIST SP 800-30 Rev 1 Chapter 2 (Fundamentals) and Chapter 3 (The Process) that (a) defines the purpose, scope, assumptions, constraints, risk tolerance, and priorities for risk assessment, (b) integrates risk assessment with the broader NIST SP 800-39 (Managing Information Security Risk) and NIST RMF (SP 800-37) processes, (c) establishes the risk assessment programme that determines frequency of assessments, triggers for ad-hoc assessments (significant change, incident, new threat intelligence), and management review cadence, (d) defines the three-tier hierarchy (Tier 1 organisation, Tier 2 mission/business process, Tier 3 information system) the organisation will use to scope assessments, (e) names the senior accountable officer (typically Risk Executive Function), the assessment owner per tier, and the maintenance owner. Capt

• approved risk management strategy / policy citing SP 800-30 Rev 1 + SP 800-39 + SP 800-37
• risk assessment programme document defining frequency, triggers, review cadence
• named accountable officer (Risk Executive Function) per tier
• risk tolerance statement approved at executive level

• risk assessments executed without an approved overarching strategy
• no named Risk Executive Function or equivalent
• risk tolerance never documented so impact ratings cannot be defended

Identify threat sources and threat events per NIST SP 800-30 Rev 1 Section 3.2 Step 2 + Appendix D (Threat Sources) + Appendix E (Threat Events). Threat source types include (a) adversarial (individual, group, organisation, nation-state) with characterisation by capability, intent, and targeting, (b) accidental (privileged or non-privileged user error), (c) structural (IT equipment failure, environmental control failure, software failure), (d) environmental (natural disaster, infrastructure outage). Threat event identification must enumerate events the organisation may face, using Appendix E as a starting taxonomy and supplemented with sector-specific threat intelligence (FS-ISAC, H-ISAC, MS-ISAC, CISA advisories, MITRE ATTandCK techniques). Document the threat source register and threat event catalogue per assessment.

• threat source register per assessment characterising adversarial sources by capability + intent + targeting
• threat event catalogue derived from Appendix E + sector ISAC intel + CISA advisories + MITRE ATTandCK techniques
• annual refresh evidence for adversarial threat intelligence
• post-incident refresh evidence

• threat catalogue copied from prior assessment without refresh
• adversarial sources named as specific groups (stale fast) rather than characterised by attributes
• no sector-specific threat intelligence consumption

Conduct risk assessments at the three tiers defined in NIST SP 800-30 Rev 1 Section 2.3 and aligned with NIST SP 800-39 governance tiers. Tier 1 Organisational Risk Assessment evaluates strategic risks (mission impact, regulatory exposure, supply chain risk, geopolitical risk) and informs the risk management strategy. Tier 2 Mission and Business Process Risk Assessment evaluates risks to specific mission and business functions and informs enterprise architecture and information protection decisions. Tier 3 Information System Risk Assessment evaluates risks to specific information systems and supports the categorisation, control selection, and authorisation activities of the NIST RMF. Document scope, assumptions, constraints, risk tolerance, and stakeholder list per tier in the risk assessment plan before executing.

• risk assessment plan per tier (T1 organisational + T2 mission/business + T3 system) showing scope + assumptions + tolerance + stakeholders
• Tier 1 aggregated organisational risk view fed by T2 and T3
• Tier 3 system risk assessment integrated with RMF Categorize and Authorize steps

• only Tier 3 system assessments exist with no aggregation to Tier 1/2
• tier scope undefined so assessments overlap or leave gaps
• Tier 3 assessments not integrated with RMF authorisation decision

Identify vulnerabilities and predisposing conditions per NIST SP 800-30 Rev 1 Section 3.2 Step 3 + Appendix F (Vulnerabilities and Predisposing Conditions). Vulnerabilities include weaknesses in information systems, security procedures, internal controls, or implementation that could be exploited by a threat source. Predisposing conditions are organisational characteristics (mission, location, dependencies, technology choices, partnerships) that increase or decrease the likelihood that vulnerabilities will be exploited or that adverse impacts will result. Sources include (a) vulnerability scanning (continuous scan results, infrastructure-as-code policy scans, container image scans), (b) penetration testing reports, (c) red-team and tabletop exercise findings, (d) prior audit and assessment reports, (e) plan-of-action-and-milestones (POAM) register, (f) industry advisories (CVE, CWE, KEV

• vulnerability catalogue per assessment citing scan results + pen test + audit + POAM + KEV
• predisposing conditions catalogue covering mission + location + dependencies + technology + partnerships
• KEV-driven prioritisation evidence
• vulnerability catalogue refresh cadence aligned to continuous scanning

• vulnerability catalogue limited to scan output ignoring penetration test + audit + incident learnings
• no predisposing conditions documented so likelihood estimates are inconsistent
• KEV catalogue not consulted