RA-1: Policy and Procedures

Quick-reference card

What this control requires

RA-01 requires your organization to create, maintain, and distribute a formal risk assessment policy along with the procedures needed to carry it out. This policy must define its purpose, scope, roles, responsibilities, management commitment, and how it aligns with applicable laws and regulations. You also need to designate a specific official responsible for developing and disseminating both the policy and its supporting procedures.

Beyond establishing these documents, RA-01 demands that you build a review cycle into them. Your organization must review and update the policy and procedures at defined intervals and in response to triggering events such as audit findings, security incidents, or changes in regulatory requirements. This ongoing maintenance separates a living risk assessment program from a static document that collects dust on a shared drive.

The control sits at the foundation of the entire Risk Assessment (RA) family. Without a documented policy and clear procedures, every downstream RA control lacks the governance structure it needs to function consistently across systems and mission areas.

Why it matters

Organizations that treat risk assessment policy as a checkbox exercise expose themselves to audit findings, regulatory penalties, and certification withdrawal. Because RA-01 is a governance control required at every baseline level, including privacy, auditors scrutinize it early and often. A missing or outdated policy signals systemic weakness in your security program.

Failure to maintain this control introduces audit risk and may result in certification withdrawal or regulatory findings. Federal agencies operating under FISMA face direct consequences when their risk assessment policies don’t reflect current organizational structures or threat environments. Commercial organizations pursuing FedRAMP authorization encounter the same scrutiny.

The real danger isn’t just a failed audit. Without a governing policy, risk assessment activities become inconsistent, ad hoc, and driven by individual judgment rather than organizational standards. Teams perform assessments using different methodologies, different scopes, and different risk tolerances, producing results that can’t be compared or aggregated into a coherent risk picture.

Specifically, when risk assessment policy is absent or stale, the risk management strategy outlined in PM-09 has no operational mechanism to translate strategic risk decisions into system-level action. The gap between executive risk appetite and day-to-day security operations widens.

What attackers exploit

• Inconsistent risk identification across business units. Without a standardized policy, different teams assess risk differently, leaving gaps that attackers can target.
• Outdated threat models that miss current attack vectors. Policies not reviewed after significant events fail to account for emerging threats and newly exploited vulnerabilities.
• No designated accountability for risk assessment oversight. When no official owns policy development, updates stall and risk blind spots persist indefinitely.
• Missing procedures that leave risk assessment frequency undefined. Attackers benefit when organizations don’t assess risk on a regular cadence, allowing vulnerabilities to accumulate undetected.

How to implement

Most organizations struggle with RA-01 not because the concept is difficult, but because they conflate policy with procedure. A policy states what the organization will do and why. A procedure describes how staff carry out specific activities to fulfill the policy. Treating them as a single document creates confusion during audits and slows down updates.

For your organization

Start by drafting a risk assessment policy that addresses each element auditors will check. The policy should cover purpose, scope, roles and responsibilities, management commitment, coordination among stakeholders, and compliance obligations. NIST SP 800-30 provides a detailed methodology for conducting risk assessments that your procedures should reference.

Designate a senior official, typically within the CISO or risk management function, as the owner of policy development and dissemination. This designation must be documented and communicated across the organization, not assumed through an org chart.

Develop procedures separately from the policy document. Procedures should describe the step-by-step process for conducting risk assessments, including how to identify threats and vulnerabilities, analyze likelihood and impact, and determine risk levels. Reference your organization’s risk management strategy, as defined under PM-09, to ensure procedures align with executive-level risk tolerance.

Build a review schedule into both documents. Define specific frequencies for routine reviews, such as annually, and identify triggering events that force an out-of-cycle update. Common triggers include audit findings, significant security incidents, changes in mission or business functions, and new or revised regulatory requirements. Document these triggers explicitly so reviews aren’t skipped.

Integrate your security and privacy teams during policy development. NIST guidance recommends collaboration between these programs, and a joint policy can reduce duplication. Organization-level policies are preferable to system-specific ones because they establish consistent standards. You can find a detailed walkthrough of the risk assessment process to guide your procedural development.

Finally, ensure your policy doesn’t restate control requirements verbatim. Auditors specifically check that policies reflect organizational decisions and context, not a copy of the NIST catalog.

For your vendors

Verify that each vendor maintains a documented risk assessment policy and supporting procedures. Request copies of these documents as part of your vendor onboarding and periodic review processes.

When evaluating vendor policies, confirm they address the same core elements required of your own organization. The policy should define purpose, scope, roles, responsibilities, and compliance alignment. Procedures should describe how the vendor actually conducts risk assessments, not just that they do.

Use a structured vendor risk assessment questionnaire to evaluate these controls systematically. Key questions to include are whether the vendor has a designated official responsible for risk assessment policy, what triggers a policy review, and how frequently assessments are conducted.

Request evidence of policy reviews and updates. A vendor whose risk assessment policy hasn’t been updated in three years is a red flag, particularly if they’ve experienced organizational changes, new regulatory obligations, or security incidents during that period.

Watch for vendors who provide a single, monolithic “security policy” document without distinct risk assessment procedures. This approach often means risk assessment activities aren’t operationalized consistently. Look for evidence that the policy drives actual assessment activities rather than existing as a standalone compliance artifact.

Cross-reference the vendor’s risk assessment policy against their system security plan and privacy plan. These documents should reflect the same risk management approach. Inconsistencies between them suggest the policy isn’t governing actual practice.

Evidence examples

Cross-framework mapping

Related controls

• PM-09 — Risk Management Strategy: Defines the organizational risk management strategy that RA-01 policies and procedures must align with and operationalize at the system level.
• PS-08 — Personnel Sanctions: Establishes consequences for personnel who fail to comply with risk assessment policies and procedures required by RA-01.
• SI-12 — Information Management and Retention: Governs how risk assessment documentation, policy versions, and related records are retained and managed throughout their lifecycle.

Frequently asked questions

What is NIST SP 800-53 RA-01?

RA-01 is the NIST SP 800-53 control that requires organizations to develop, document, and disseminate a risk assessment policy and supporting procedures. The policy must address purpose, scope, roles, responsibilities, management commitment, and coordination with applicable legal requirements. A designated official must own policy development and dissemination, and both documents require review and update at defined frequencies.

What happens if RA-01 is not implemented?

Without a documented risk assessment policy and procedures, your organization lacks the governance foundation for the entire RA control family. Auditors will flag the absence of a designated official for policy management and the lack of defined review frequencies as findings. These gaps can result in failed audits, delayed certifications, and regulatory penalties, particularly under frameworks like FISMA and FedRAMP that require RA-01 at every baseline.

How do you audit RA-01?

Auditors verify that a risk assessment policy exists, addresses all required elements including purpose, scope, roles, and compliance alignment, and has been disseminated to relevant personnel. They check for evidence of a designated official responsible for policy development, documented review and update cycles, and records showing the policy and procedures were updated in response to defined triggering events such as audit findings or security incidents.

How often should you review a risk assessment policy under NIST 800-53?

NIST SP 800-53 doesn’t prescribe a specific frequency. Instead, RA-01 requires organizations to define their own review intervals and document the events that trigger out-of-cycle updates. Most organizations review their risk assessment policy and procedures annually at minimum, with additional reviews following audit findings, significant incidents, or changes in regulatory requirements. The defined frequency must be documented within the policy itself and reflected in review records.