NIST SP 800-53 RA Risk Assessment: Key Controls, Enhancements and How to Evidence Them

Risk assessment findings are rarely about the absence of a risk register; they are about a register that was written once, never updated when the system changed, and never connected to the scan results and audit findings that should feed it. This guide works through the Risk Assessment (RA) family of NIST SP 800-53 Rev. 5 control by control: what each key control and enhancement requires, which baselines select it, which organisation-defined parameters you must set, and what evidence an assessor will ask for. It is written for risk owners, system security plan authors, vulnerability management leads and assessors. For the risk assessment method itself, see the NIST SP 800-30 Risk Assessment Guide; for the wider lifecycle, see the NIST Risk Management Framework Guide. This page stays at the level of the RA controls and their evidence.

Key takeaways

• Five RA controls apply at Low. RA-1, RA-2, RA-3, RA-5 and RA-7 sit in all three security baselines, along with RA-3(1) supply chain risk assessment, RA-5(2) and RA-5(11). Moderate adds RA-5(5) privileged scanning and RA-9 criticality analysis; High adds RA-5(4) discoverable information.
• RA-3 includes privacy harm. RA-3a.3 requires determining the likelihood and impact of adverse effects on individuals from processing PII, so a security-only risk assessment does not fully meet RA-3.
• RA-5 is more than scanning. It requires analysis, remediation within response times you define based on risk, sharing results to prevent similar flaws elsewhere, and tools that can update the vulnerabilities they check for.
• A public disclosure channel is baseline. RA-5(11) at Low, Moderate and High requires a public reporting channel for vulnerabilities in your systems. A security contact page and a vulnerability disclosure policy meet it.
• RA-7 closes the loop. Findings from assessments, monitoring and audits must be responded to in line with risk tolerance. Accepted risks need an owner, a reason and an expiry date.

The RA family at a glance

The table lists every current RA base control with its baseline allocation, taken from NIST's OSCAL Release 5.2.0 catalogue and baseline profiles (L = Low, M = Moderate, H = High, P = Privacy). RA-4 is withdrawn and omitted.

For selection and tailoring, see the NIST SP 800-53B Control Baselines and Tailoring Guide.

RA-1 and RA-2: policy and categorisation

• RA-1 Policy and Procedures: a risk assessment policy at the level you select, procedures, a designated official and review at a frequency and after events you define.
• RA-2 Security Categorization: (a) categorise the system and the information it processes, stores and transmits; (b) document the results and rationale in the security plan; (c) verify that the authorising official or designated representative reviews and approves the decision. RA-2(1), a tailoring candidate, prioritises systems within the same impact level for more granularity, which helps large estates decide where Moderate systems sit relative to each other.

RA-2 decides which baseline the system starts from, so an under-categorised system under-protects everything. The categorisation method is FIPS 199 with SP 800-60 information types; see the NIST SP 800-53 Privacy Controls and FIPS 199/200 Categorisation Guide.

RA-3: risk assessment

RA-3 has six parts. The table shows what each needs in practice.

RA-3(1) Supply Chain Risk Assessment is in all three baselines: assess supply chain risks for systems, components and services you define, and update at a frequency you define or on significant change. Include suppliers with privileged or API access to the system, not only those who ship components. See the NIST SP 800-161 Cyber Supply Chain Risk Management Guide. Tailoring candidates RA-3(2) all-source intelligence, RA-3(3) dynamic threat awareness and RA-3(4) predictive cyber analytics suit organisations with a threat intelligence function; see the Threat Intelligence Guide.

Non-human identities are a common blind spot in RA-3a.1. Long-lived API keys, over-privileged service accounts and third-party OAuth grants are vulnerabilities in the RA-3 sense and belong in the threat and vulnerability list with an owner.

RA-5: vulnerability monitoring and scanning

• RA-5a: monitor and scan for vulnerabilities in the system and hosted applications at a frequency or random process you define, and when new vulnerabilities that may affect the system are reported.
• RA-5b: use tools and techniques that support interoperability and automation through standards for enumerating platforms, flaws and misconfigurations, formatting checklists and test procedures, and measuring impact. CPE, CVE, CWE, SCAP checklists and CVSS are the familiar examples.
• RA-5c and RA-5d: analyse reports and remediate legitimate vulnerabilities within response times you define in line with a risk assessment.
• RA-5e and RA-5f: share results with named roles to eliminate similar vulnerabilities elsewhere, and use tools that can readily update the vulnerabilities scanned.

RA-5(5) creates a credential worth protecting: authenticated scanning needs accounts with wide read or administrative access on every target. Treat scanner credentials as privileged non-human identities, vault them, scope them to scanning, rotate them and alert on their use outside scan windows. RA-5(8) is valuable after a critical disclosure: search historic logs for signs the flaw was already exploited. See the Vulnerability Management Guide and the Bug Bounty and Vulnerability Disclosure Guide for RA-5(11).

RA-7, RA-8, RA-9 and RA-10: response, privacy, criticality and hunting

• RA-7 Risk Response: respond to findings from security and privacy assessments, monitoring and audits in line with organisational risk tolerance. Each finding ends in mitigate, accept, avoid, share or transfer, recorded with an owner. Plans of action and milestones (CA-5) carry the mitigation work.
• RA-8 Privacy Impact Assessments (P): conduct a PIA before developing or procuring IT that processes PII, and before starting a new collection of PII processed with IT that permits contacting a specific individual where identical questions go to ten or more individuals outside the federal government. Outside US government, a DPIA under GDPR plays a similar role; see the DPIA Guide.
• RA-9 Criticality Analysis (M, H): identify critical components and functions for systems, components or services you define at system development life cycle decision points you define. Its output feeds CP-2(8), supply chain decisions and where to spend assurance effort. See the Crown Jewels Analysis Guide.
• RA-10 Threat Hunting: a tailoring candidate requiring a hunting capability to search for indicators of compromise and to detect, track and disrupt threats that evade existing controls, at a frequency you define. See the Threat Hunting Guide.
• RA-6 Technical Surveillance Countermeasures Survey: a tailoring candidate for sensitive locations, run at locations and times you define.

How to evidence RA controls

SP 800-53A Rev. 5 assessment procedures use examine, interview and test. The table turns them into evidence an assessor can accept in one pass.

For assessment depth, see the NIST SP 800-53A Guide.

Implementing the RA family: a phased approach

This sequence is NHI Mgmt Group's recommendation for a Moderate system.

1. Confirm categorisation. Review RA-2 with the authorising official and record the rationale.
2. Write the parameters. Fill RA-1c, RA-3d, RA-3f, RA-5a, RA-5d response times by severity, RA-5e roles and RA-9 decision points in the system security plan.
3. Close scan coverage. Reconcile scan targets against the asset inventory, move to authenticated scanning under RA-5(5), and vault scanner credentials.
4. Publish a disclosure channel. A vulnerability disclosure policy and monitored contact for RA-5(11).
5. Run the risk assessment. Use the SP 800-30 method; include supply chain risks, privacy harm and non-human identity weaknesses.
6. Connect findings to response. Feed scan, assessment and audit findings into one register with RA-7 decisions and expiry dates.
7. Set change triggers. New internet exposure, new supplier access, new PII processing or a major architecture change triggers an RA-3 update.

Introduce authenticated scanning to a pilot group first and watch for performance or lockout effects. Roll back by returning that group to unauthenticated scans while scanner account permissions are corrected, and record the coverage gap as a temporary accepted risk.

Decision guidance

• Low versus Moderate: Low already requires categorisation, risk and supply chain assessment, scanning with updates, a disclosure channel and risk response. Moderate adds authenticated scanning and criticality analysis.
• Qualitative versus quantitative: qualitative scales are enough for RA-3 in most organisations. Use quantitative methods where decisions involve large spending trade-offs and loss data exists.
• Response times: set RA-5d times by severity and exposure, and shorten them for vulnerabilities known to be exploited. Our starting point is days for exploited internet-facing flaws and weeks for others, tuned to your risk tolerance.
• Small organisations: a short risk register reviewed yearly and after major changes, managed scanning with tracked fix times and a security contact page meet the Low intent.

Detection and measurement

• Share of inventoried assets scanned within the RA-5a frequency, and share scanned with credentials.
• Share of vulnerabilities remediated within RA-5d response times, by severity.
• Number of accepted risks past their expiry date.
• Days since the last RA-3 update, and number of significant changes without an update.
• Median time to acknowledge reports received through the RA-5(11) channel.

Framework mapping

The SP 800-171 Rev. 3 column follows that publication's Risk Assessment and Supply Chain Risk Management families. CSF and CIS mappings are "intersects with", not equivalence, and are our reading. Check them against NIST's published informative references before using them in an audit. See the CIS Control 7 Continuous Vulnerability Management Guide.

Common failure patterns

• Write-once assessment: RA-3 completed for authorisation and never updated after major changes.
• Scans without coverage: scanning runs, but cloud workloads, SaaS and new subnets are not in scope.
• Over-privileged scanner accounts: a domain administrator account is used for authenticated scanning and stored in the scanner's own database.
• Response times undefined: "remediate promptly" in place of RA-5d times, so ageing findings cannot be judged.
• Permanent risk acceptance: accepted risks with no owner or expiry accumulate until nobody knows why they were accepted.
• Machine identities ignored: leaked keys and stale service accounts never appear in RA-3 because they are not "vulnerabilities" in the scanner.

Practitioner checklist

• Document RA-2 categorisation with rationale and authorising official approval.
• Include supply chain, privacy harm and non-human identity risks in RA-3.
• Define RA-3 update triggers and review dates and keep to them.
• Reconcile scan scope with the asset inventory and scan with credentials at Moderate.
• Vault, scope and monitor scanner credentials as privileged non-human identities.
• Set RA-5d response times by severity and report against them.
• Publish a monitored vulnerability disclosure channel.
• Record every RA-7 decision with owner, reason and expiry.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: OSCAL content, SP 800-53 Release 5.2.0 catalogue and baseline profiles
• NIST: SP 800-53B, Control Baselines for Information Systems and Organizations
• NIST: SP 800-53A Rev. 5, Assessing Security and Privacy Controls
• NIST: SP 800-30 Rev. 1, Guide for Conducting Risk Assessments
• NIST: SP 800-171 Rev. 3

Related NHI Mgmt Group resources: NIST SP 800-53 Guide · NIST SP 800-30 Risk Assessment Guide · Vulnerability Management Guide · NIST Risk Management Framework Guide