RA-3: Risk Assessment

Quick-reference card

What this control requires

RA-03 requires your organization to conduct, document, review, and update risk assessments that identify threats, vulnerabilities, and the potential harm from unauthorized access, disclosure, or disruption of information systems. The control goes beyond a one-time analysis. It mandates a repeatable cycle of assessing risk, integrating results across organizational tiers, and disseminating findings to decision-makers who can act on them.

In practice, the control establishes six operational obligations. You must identify threats and vulnerabilities relevant to your systems, determine the likelihood and magnitude of harm from exploitation, assess adverse effects on individuals arising from personally identifiable information (PII) processing, and then integrate those results across organizational levels. The results must be documented in your system security plan or a standalone risk assessment report, reviewed on a defined schedule, shared with designated personnel, and updated whenever significant changes occur.

Where most organizations fall short isn’t in performing an initial assessment. It’s in maintaining the cycle. NIST SP 800-53 treats risk assessment as a living process, not a point-in-time compliance artifact. That distinction is what separates a control that protects your organization from one that only satisfies an auditor during a narrow review window.

Why it matters

Organizations that treat risk assessments as static documents accumulate blind spots. Threat landscapes shift, system boundaries change, and new integrations introduce vulnerabilities that didn’t exist during the last review cycle. Without a current risk assessment, your security controls are calibrated against yesterday’s threat model.

Failure to maintain RA-03 introduces audit risk and may result in certification withdrawal or regulatory findings. Federal agencies and contractors operating under FISMA face direct consequences when risk assessment documentation is outdated or incomplete. For organizations pursuing FedRAMP authorization or maintaining an authorization to operate (ATO), gaps in RA-03 implementation signal systemic weaknesses in the security program’s foundation.

The risk compounds at scale. When risk assessment results aren’t integrated across organizational levels, leadership makes resource allocation decisions without understanding where the greatest exposure exists. Security teams patch vulnerabilities without a prioritization model, and compliance officers can’t demonstrate due diligence during audits.

Risk assessments also play a structural role in the Risk Assessment control family. They inform control selection, guide tailoring decisions, and provide the justification for accepting residual risk. An outdated assessment undermines every downstream control that depends on it.

What attackers exploit

• Unidentified threat vectors. When risk assessments don’t account for evolving attack techniques, organizations miss threats like supply chain compromise, credential stuffing against legacy systems, or cloud misconfigurations that weren’t present during the last review.
• Vulnerability gaps between assessment cycles. Prolonged gaps between risk assessment updates leave newly disclosed vulnerabilities unaccounted for in the organization’s risk posture.
• PII processing blind spots. Organizations that fail to assess adverse effects on individuals from PII processing expose themselves to privacy-related attack vectors, including data aggregation and inference attacks.
• Siloed risk visibility. When assessment results aren’t integrated across organizational tiers, attackers exploit gaps between what the information system owner knows and what executive leadership has approved.

How to implement

For your organization

The most common failure mode is treating risk assessment as a compliance checkbox rather than an operational input. Organizations produce a risk assessment document during initial authorization, file it, and don’t revisit it until the next audit cycle. By that point, the threat landscape and system boundaries have changed enough to make the original assessment unreliable.

Step 1. Define your assessment methodology. Establish a documented risk assessment methodology that specifies how you’ll identify threats, characterize vulnerabilities, determine likelihood, and evaluate impact. NIST SP 800-30 provides a widely adopted methodology for conducting risk assessments at all three organizational tiers. Your methodology should specify whether you’re using qualitative, quantitative, or semi-quantitative approaches, and how you’ll handle uncertainty.

Step 2. Identify threats and vulnerabilities. Catalog threats relevant to your operating environment using structured sources like the MITRE ATT&CK framework for adversarial techniques and NIST’s threat taxonomy. Map these threats against known vulnerabilities in your systems, including those identified through vulnerability scanning, penetration testing, and configuration audits.

Step 3. Determine likelihood and impact. For each threat-vulnerability pair, assess the likelihood of exploitation and the magnitude of harm. Consider organizational operations, assets, individuals, and other organizations. If your systems process PII, you must separately assess adverse effects on individuals from that processing.

Step 4. Integrate and document results. Consolidate risk assessment results across the organization, mission/business process, and information system levels. Document findings in your system security plan or a dedicated risk assessment report. The documentation should capture the risk determination methodology, the assessed risk level for each finding, and the rationale behind likelihood and impact ratings.

Step 5. Establish review and update cadence. Define a review frequency for risk assessment results, typically aligned with continuous monitoring cycles or authorization milestones. Risk assessments must also be updated whenever significant changes occur, such as new system integrations, architectural changes, or emerging threat intelligence that changes your risk profile.

Step 6. Disseminate to defined personnel. Identify the roles that need access to risk assessment results, including system owners, authorizing officials, and security officers. Establish a distribution mechanism that ensures timely access without exposing sensitive risk data to unauthorized personnel.

Evidence to produce:

• Documented risk assessment methodology
• Completed risk assessment with threat-vulnerability pairings
• PII impact analysis (if applicable)
• Risk assessment review records with dates and reviewer names
• Distribution records showing dissemination to designated personnel

Common mistakes:

• Conducting risk assessments only at the information system level while ignoring organization and mission/business process tiers
• Failing to update the assessment after major system changes or new threat intelligence
• Documenting risks without assigning likelihood and impact ratings
• Omitting PII processing from the scope of the assessment
• Not defining specific personnel for results dissemination, defaulting to “all staff” without accountability

Evidence examples

Cross-framework mapping

Related controls

• CA-03 — Information Exchange: defines requirements for information exchange agreements, which should incorporate risk assessment findings about interconnection threats.
• CA-06 — Authorization: the authorization decision relies directly on risk assessment results to determine whether residual risk is acceptable.
• CM-04 — Impact Analyses: requires analysis of security and privacy impacts from configuration changes, using risk assessment results as baseline context.
• CM-13 — Data Action Mapping: maps PII processing activities, providing inputs to the risk assessment’s evaluation of adverse effects on individuals.
• CP-06 — Alternate Storage Site: risk assessment results inform the selection and configuration of alternate storage sites based on identified threats.
• CP-07 — Alternate Processing Site: risk assessment findings guide decisions about alternate processing site capabilities and geographic separation.
• IA-08 — Identification and Authentication (Non-organizational Users): risk assessments determine the authentication assurance level required for external users.
• MA-05 — Maintenance Personnel: risk assessment results inform the level of supervision and access restrictions applied to maintenance personnel.
• PE-03 — Physical Access Control: physical threat assessments feed into the risk assessment’s evaluation of facility-level vulnerabilities.
• PE-08 — Visitor Access Records: visitor access controls are calibrated based on risk assessment findings about physical security threats.

Frequently asked questions

What is NIST SP 800-53 RA-03

RA-03 is the NIST SP 800-53 control that requires organizations to conduct risk assessments identifying threats, vulnerabilities, and the potential harm from unauthorized access or disruption. The control mandates a repeatable cycle of assessing risk, integrating results across organizational tiers, and documenting findings in security plans or dedicated risk assessment reports. It applies across all baselines, including privacy, and requires organizations to evaluate adverse effects on individuals from PII processing.

What happens if RA-03 is not implemented

Without RA-03 implementation, your organization operates without a documented understanding of its threat landscape, leaving security controls misaligned with actual risks. Auditors will flag the absence of a current risk assessment as a material finding, which can jeopardize authorization to operate decisions and delay or revoke certifications. The downstream impact extends to every control that depends on risk assessment inputs, including control selection, tailoring decisions, and residual risk acceptance.

How do you audit RA-03

Auditors verify RA-03 by examining the risk assessment report for completeness, checking that threat and vulnerability identification was conducted, that likelihood and magnitude of harm were determined, and that PII impact assessment was performed where applicable. They review integration records to confirm results were consolidated across organizational levels and inspect dissemination logs to verify findings reached designated personnel. Auditors also check the review and update log to confirm the assessment was refreshed at the defined frequency and after significant system changes.

How often should a NIST risk assessment be updated

NIST doesn’t prescribe a fixed update frequency for RA-03. Instead, organizations must define their own review cadence and update the risk assessment whenever significant changes occur, such as new system components, architectural modifications, or changes in the threat environment. Most organizations align updates with their continuous monitoring strategy, typically reviewing annually at minimum and triggering ad hoc updates when major changes affect the system’s risk profile.