Risk Assessment Plan

Approach basics → §4.x

Methodology references and tooling that anchor the rest of the plan.

Categorization method (one-liner) * How information is categorized per FIPS 199 (e.g., 'FIPS 199 + CNSSI 1253 overlay', 'FIPS 199 with NIST SP 800-60 v2 information-type guide').

Risk-assessment methodology * Methodology used to assess risk (e.g., 'NIST SP 800-30 r1 likelihood × impact', 'OCTAVE Allegro', 'FAIR (quantitative)').

Risk register location * Where the risk register is maintained (e.g., 'GRC tool — Archer / ServiceNow GRC', 'eMASS', 'Spreadsheet under /repo/risk/register.xlsx with version control').

Vulnerability scanning tool * Primary scanner (typically the same tool referenced in the SI plan: e.g., 'Tenable.sc', 'Qualys VMDR', 'Rapid7 InsightVM').

Threat-hunt cadence How often proactive hunts are conducted (e.g., 'Quarterly hypothesis-driven hunts; continuous SOAR-assisted micro-hunts').

Threat-hunt role Role that performs hunts (e.g., 'Enterprise SOC Threat Intelligence Team', 'External MDR retainer + internal IR lead').

Security Categorization (RA-2) → §4.x

FIPS 199 process and information-type analysis.

FIPS 199 categorization (CIA triad) The Confidentiality / Integrity / Availability impact levels (Low / Moderate / High) and how they were determined. Reference NIST SP 800-60 v2 information-type guide for the rationale.

High-water-mark rationale Per FIPS 199, system categorization is the high-water mark across information types. Document the deciding information type and any moderation per CNSSI 1253 if applicable.

Information types in scope

Add item

Suggested: + C.2.8.1 Personnel Management + C.3.5.1 System Development + C.3.5.5 IT Infrastructure Maintenance + C.3.5.7 Information Security + D.10 General Government + D.13 Law Enforcement + D.14 Regulatory Compliance

Impact-level prioritization (RA-2(1)) Per RA-2(1), how individual data elements within an information type are prioritized when impact varies. Often required at moderate / high baselines.

Re-categorization triggers What events cause categorization to be revisited (e.g., 'Significant change per CM-4', 'New information type onboarded', 'Annual ATO review').

Risk-Assessment Methodology (RA-3) → §4.x

How likelihood, impact, and risk are computed.

Threat-source taxonomy

Adversarial — Nation-state Adversarial — Cybercriminal Adversarial — Insider (malicious) Adversarial — Hacktivist Adversarial — Unknown / opportunistic Accidental — Insider (unintentional) Structural — IT failure / aging hardware Environmental — Natural disaster / power / cooling Supply chain — Third-party compromise

Likelihood scale — Select — Qualitative 5-tier (Very Low / Low / Moderate / High / Very High) Qualitative 3-tier (Low / Moderate / High) Quantitative (annualized rate of occurrence) Hybrid (qualitative for unknown, quantitative for measured)

Impact scale — Select — Qualitative 5-tier (Very Low / Low / Moderate / High / Very High) Qualitative 3-tier (Low / Moderate / High) Quantitative ($ loss range) Hybrid

Risk-assessment cadence (RA-3 ODV) How often the system risk assessment is refreshed. RA-3 ODV — common values: 'Annually + on significant change', 'Every 3 years + on significant change'.

Risk-assessment results distribution (RA-3 ODV) Roles / personnel to whom risk-assessment results are distributed (System Owner, ISSO, ISSM, AO, ITRM committee, etc.).

Risk-assessment documentation format Format / template used (e.g., 'NIST SP 800-30 r1 Appendix L worksheets', 'Internal Risk Assessment Report template', 'eMASS-generated Security Assessment Report').

Risk Register Management → §4.x

How identified risks are tracked, prioritized, and aged.

Required fields per risk entry

Unique risk ID Risk statement Threat source Vulnerability or weakness Affected components Likelihood rating Impact rating Inherent risk score Residual risk score (post-mitigation) Risk owner Mitigation strategy Decision (accept / mitigate / transfer / avoid) Decision authority + date Review date Linked POA&M ID

Risk aging policy How long risks may sit at each status before re-evaluation (e.g., 'Open risks reviewed quarterly; accepted risks re-validated annually; mitigated risks closed when controls verified').

Escalation thresholds Thresholds at which risks escalate beyond System Owner (e.g., 'High residual → ISSM brief; Very High residual → AO immediate notification').

Vulnerability Scanning (RA-5) → §4.x

Scan scope, cadence, and coordination with SI-2 remediation.

Scan scope (RA-5)

All hosts in authorization boundary External-facing (DMZ + public) Container images at build Container runtime Cloud configuration (CSPM) Web application (DAST) Source code (SAST) Software composition (SCA) Database configuration Network appliances Mobile applications API endpoints

Scan cadence Cadence by scope (e.g., 'External: continuous; Internal authenticated: weekly; Container images: on build; Web app DAST: monthly'). RA-5 ODV.

Authenticated vs unauthenticated Posture on authenticated scans (preferred for accuracy). Service-account credential management.

Vulnerability information update mechanism (RA-5(2)) How scanner signatures are kept current (auto-update, daily plugin pulls). Required by RA-5(2) — system is scanned with current information.

Findings routing Where scan findings land. Typically a remediation queue feeding SI-2. Severity classification mapping.

Information sharing (RA-5(11)) Per RA-5(11), how vulnerability information is shared with stakeholders (System Owner, ISSO, ISSM, downstream consumers, partner systems).

Privileged-access controls for scanners (RA-5(5)) Per RA-5(5), how scanner privileged access is controlled. Service-account vault, JIT credential, MFA on scanner console.

Risk Response (RA-7) → §4.x

Decision framework and authority for risk disposition.

Risk-response options offered

Accept (formal acceptance with rationale) Mitigate (additional controls) Transfer (insurance, cyber-insurance, contractual) Avoid (eliminate the activity / system feature) Share (distribute to multiple parties)

Risk-acceptance authority by tier Who can accept risk at each level (e.g., 'Low: System Owner; Moderate: ISSM; High: AO; Very High: AO with CIO concurrence'). Reference any organizational risk-tolerance statement.

Risk-acceptance evidence required Documentation required for risk acceptance (e.g., 'Signed risk-acceptance memo + entry in risk register + POA&M for periodic re-validation').

Accepted-risk revisit cadence How often accepted risks are re-validated to ensure conditions haven't changed.

Criticality Analysis (RA-9) → §4.x

Identification of critical components for prioritized protection.

Criticality-analysis methodology Approach to identifying critical components (e.g., 'NIST SP 800-161 r1 § 2.4 supply-chain criticality; NIST SP 800-30 r1 Appendix F asset value; FMEA for failure-impact analysis').

Critical-component categories

Mission-essential functions (per CNSSI 4009) Cryptographic modules / HSMs Authentication / IdP infrastructure Network boundary devices Database servers holding CUI / PII / PHI Logging / audit infrastructure (AU) Backup / recovery infrastructure (CP) Supply-chain critical items (per RA-3(1)) Single-source / single-vendor components

Criticality-analysis review cadence How often the analysis is refreshed (e.g., 'Annual + on architecture change').

How criticality informs decisions How criticality drives architecture choices, redundancy investments, monitoring prioritization, supplier vetting depth.

Supply Chain Risk (RA-3(1)) → §4.x

Supply-chain-specific risk assessment, separate from generic RA-3.

Supply-chain assessment triggers

New vendor onboarding (initial) Annual vendor review Major version / contract change Vendor incident / breach Geopolitical change affecting vendor location M&A activity affecting vendor ownership

Critical supply-chain dependencies Vendors / components whose compromise would disable the system. Single-source items, foreign-sourced components per FAR / DFARS, key open-source projects.

Assessment inputs used

Vendor SOC 2 Type II reports Vendor FedRAMP authorization Vendor cyber-insurance + financial health ICT-SCRM (NIST SP 800-161 r1) self-attestation SBOM analysis (per EO 14028 / OMB M-22-18) Vendor security questionnaire (CAIQ / SIG) Open-source project health (commits, maintainers, vulnerability history) Third-party risk-rating service (BitSight / SecurityScorecard)

Handoff to SR (Supply Chain Risk Management) family How RA-3(1) outputs feed the SR family controls. If SR plan exists, reference its location.

Threat Hunting (RA-10) → §4.x

Proactive search for previously undetected threats.

Hunt methodology Hypothesis-driven hunts based on threat intelligence, MITRE ATT&CK techniques, anomaly-driven hunts. Tooling (SIEM, EDR query, custom queries).

Threat-intelligence sources used

MITRE ATT&CK CISA Cyber Threat Bulletins Sector ISAC threat reports Vendor threat-intel feeds Open-source intel (OSINT) Government classified intel feeds (federal) Commercial TIP (Recorded Future / Mandiant / etc.) Internal red-team / purple-team reports

Hunt-finding handling What happens when a hunt finds something (incident escalation per IR plan, control gap → POA&M, detection-rule creation feeding SI-4).

Privacy Risk Assessment (RA-8) → §4.x

Privacy Impact Assessment if applicable to information categorization.

PIA required by categorization — Select — Yes — system handles PII (PIA required + published) Yes — PIA required + not published (operational sensitivity) No — system does not handle PII Pending — PII handling under review

PIA methodology Methodology used (e.g., 'NIST IR 8062 privacy risk model', 'OMB M-03-22 PIA template', 'Internal privacy-impact framework based on FIPPs').

PIA review cadence When PIA is refreshed (e.g., 'Annually; on significant change to information collection or use'). Reference PT family if authored.

Risk-Assessment Scope and Coverage → §2.x

Quantitative scope numbers that anchor metrics later in the plan.

Open risks in register (approximate) Order-of-magnitude count to anchor the metric tracking.

System components in scope of RA-5 Approximate count of hosts / containers / images covered by vulnerability scans.

Critical components per RA-9 analysis Count of components classified as critical.

Third-party / supply-chain dependencies tracked Count of vendors / open-source projects in the supply-chain register.

Risk-Assessment Metrics & KPIs → §6.x

Metrics tracked to demonstrate RA control effectiveness.

Tracked metrics

Add item

Suggested: + Open risks by severity (current + trend) + Mean time to risk decision (Identified → Decision) + % Accepted risks reviewed within revisit cadence + Vulnerability scan coverage rate (% of in-scope assets scanned) + % Critical / High vulnerabilities patched within SLA (overlaps SI-2) + KEV-affected scan-coverage rate + Threat-hunt findings closed per quarter + Threat-hunt findings escalated to incident + Critical-component coverage of monitoring + redundancy + Supply-chain assessments completed within trigger cadence + Open POA&M items linked to RA controls

Scan Coverage Verification → §6.x

How the org continuously verifies RA-5 scanning is correctly deployed.

Scan-coverage reconciliation cadence How often the asset inventory (CMDB) is reconciled against scanned-asset roster. Detects shadow / unscanned hosts.

Scanner signature-currency verification How the org verifies scan signatures are current (e.g., 'Daily plugin-update verification report'). Required by RA-5(2).

Cross-references to other RMF artifacts → §7

Where this plan plugs into the broader RMF package.

SSP section reference Where in the SSP the RA control implementations are summarized (e.g., 'SSP §13.11').

POA&M ID prefix for RA findings Convention for RA-related POA&M items (e.g., 'POAM-RA-' for general; 'POAM-RA5-' for vuln-specific).

SI-2 flaw-remediation consumer handoff How RA-5 findings flow into the SI-2 remediation queue. Tooling, ticket-creation automation, owner assignment.

CM-4 security-impact analysis handoff How RA-3 outputs inform CM-4 / CM-3 change-impact analysis. Reference the CM Plan.

CA-7 continuous-monitoring strategy reference Pointer to the CA-7 monitoring strategy document tying RA continuous-monitoring metrics to the broader ConMon plan.

IR escalation handoff How incidents trigger risk-register revisits. Closed incidents that introduced new risk get entries in the register.

SR family pointer Pointer to the SR (Supply Chain Risk Management) plan if authored. RA-3(1) is the gateway control; SR formalizes the program.