RA-1: Policy and Procedures

RA-1 sits at the front of the NIST SP 800-53 Risk Assessment family. It is not asking you to “do risk assessments” (that’s covered elsewhere in RA). It is asking you to prove you run risk assessment as a managed program: you have a policy that sets expectations and procedures that make those expectations repeatable, trainable, and auditable.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat RA-1 as a documentation-and-governance control with operational hooks. Your RA policy becomes the rulebook: what you assess, when you assess it, who approves exceptions, how results feed remediation and authorization decisions, and what records you retain. Your procedures become the playbooks: the steps teams follow to execute assessments, record results, and escalate material risk.

If you handle federal data (including as a contractor), RA-1 is commonly assessed as part of a broader NIST SP 800-53 program. The goal is simple: if an assessor asks “show me how your organization governs risk assessment,” you can produce an approved policy, current procedures, evidence they were disseminated, and proof they’re being used.

Regulatory text

Excerpt (RA-1): “Develop, document, and disseminate to {{ insert: param, ra-1_prm_1 }}:” ¹

What the operator must do:

1. Develop a risk assessment policy and related procedures.
2. Document them in a controlled, reviewable form (versioning, approvals, effective dates).
3. Disseminate them to defined audiences (the parameter placeholder in the excerpt indicates your organization must specify who receives them, such as system owners, security staff, engineering, and relevant business stakeholders). ¹

Plain-English interpretation (what RA-1 is really testing)

RA-1 tests whether risk assessment is governed like a program, not handled ad hoc. You should be able to answer, with artifacts:

• What is your organization’s risk assessment policy?
• What procedures implement it?
• Who must follow them?
• How do you keep them current?
• How do you prove people can access them and that teams actually follow them?

This is why assessors often treat RA-1 as an “auditability multiplier.” Weak RA-1 makes other RA controls harder to defend because you cannot show consistent expectations or repeatable execution.

Who it applies to (entity and operational context)

RA-1 applies wherever NIST SP 800-53 is used as the control baseline, including:

• Federal information systems and the organizations operating them.
• Contractor systems handling federal data where NIST SP 800-53 is flowed down through contracts, program requirements, or authorization expectations. ¹

Operationally, RA-1 touches:

• The GRC/compliance function (policy ownership, governance, evidence).
• Security leadership (risk methodology, acceptance thresholds, escalation).
• System owners and engineering (execution of assessments, remediation tracking).
• Third-party risk teams (where third-party risk is part of your risk assessment scope, even if managed under a separate policy).

What you actually need to do (step-by-step)

Step 1: Set the control boundaries (define “RA” in your environment)

Write down, in one page, what “risk assessment” includes for RA-1 purposes:

• Systems/information types in scope (production systems, corporate IT, SaaS used for regulated data).
• Risk types covered (security risk at minimum; include privacy, operational resilience, and third-party risk if that’s how your program operates).
• Interfaces to other processes (change management, vulnerability management, incident response, enterprise risk).

This prevents the most common audit argument: “This policy is generic and doesn’t cover the assessed system.”

Step 2: Draft the RA policy (the “what” and “who”)

Your RA policy should be short and directive. Include, at a minimum:

• Purpose and scope
• Roles and responsibilities (policy owner, procedure owner, system owner duties, approver for risk acceptance)
• When assessments occur (event-based triggers like new systems, major changes, new third parties, significant incidents; avoid unsourced numeric intervals and instead state “periodic and event-driven” unless your organization sets an internal requirement)
• Methodology reference (name the internal standard you follow; if you use a template, reference it)
• Risk acceptance and escalation (who can accept which types of risk; where exceptions are recorded)
• Recordkeeping requirements (where evidence lives; retention handled by your organization’s retention schedule)

Keep it enforceable. “May” and “should” reads like optional guidance; use “must” for requirements you intend to test.

Step 3: Write procedures (the “how” that teams can follow)

Procedures must be specific enough that two different analysts produce comparable outputs. Include:

• Intake: what starts an assessment (request form, ticket, change record)
• Data collection: architecture diagrams, asset inventory, threat sources, third-party dependencies
• Analysis steps: identify threats, vulnerabilities, likelihood/impact scales (use your internal scale), existing controls, residual risk
• Outputs: risk register entry, recommended actions, risk owner assignment
• Approvals: sign-offs for high-risk items, exception path, and where approvals are stored
• Follow-through: how remediation is tracked to closure; when reassessment happens after changes

If your organization spans multiple environments (cloud and on-prem), add procedure variants or appendices so the guidance matches reality.

Step 4: Define the dissemination plan (who, how, and proof)

RA-1 explicitly calls out dissemination. Build a simple matrix:

Audience	What they receive	Delivery method	Evidence
System owners	Policy + procedure summary	GRC portal / intranet + onboarding	Access logs or attestation
Security team	Full procedures + templates	Knowledge base	Change log + team acknowledgement
Engineering	“How to request/participate” job aid	Wiki + SDLC docs	Link in SDLC standard
Third-party risk	Integration points	TPRM playbook	Cross-reference in TPRM procedure

Your goal is not mass emailing. Your goal is controlled availability plus provable communication.

Step 5: Assign ownership and set review mechanics

Document:

• Policy owner (often CISO, Head of GRC, or Risk function)
• Procedure owner (GRC operations or Security Assurance)
• Review/approval workflow (legal/compliance review if required; executive approval)
• Change control (version history, effective date, next review date)

If you use Daydream, map RA-1 to a named control owner, link the policy/procedure artifacts, and schedule recurring evidence collection so you do not scramble at audit time.

Step 6: Map RA-1 to evidence artifacts (make audits boring)

NIST auditors typically look for “designed and operating” evidence. For RA-1, you prove operation by showing the documents are current, disseminated, and referenced by actual risk assessment work products. The strongest pattern is to map RA-1 to an owner, an implementation procedure, and recurring evidence artifacts. ¹

Required evidence and artifacts to retain

Maintain an “RA-1 evidence packet” with:

• Approved RA policy (versioned, signed/approved, effective date)
• Approved RA procedures (versioned; includes templates or linked forms)
• Dissemination evidence (intranet publication record, GRC portal page, access permissions, training/attestation records, or onboarding materials referencing RA policy)
• Review evidence (ticket or meeting minutes showing periodic review and approval)
• Cross-references (links from SDLC, change management, TPRM, or system authorization docs to RA procedures)
• A sample set of risk assessment work products that clearly follow the procedure (redact sensitive details as needed)

Common exam/audit questions and hangups

Expect these questions:

• “Who is the RA policy owner, and who approves exceptions?”
• “Show me dissemination: how do you know the right people received it?”
• “Is this policy tailored to the system boundary we’re assessing?”
• “Where are procedure outputs stored, and how do you ensure completeness?”
• “Show evidence the procedure is actually used, not shelfware.”

Hangups that trigger findings:

• Policy exists, but procedures are missing or too high-level.
• Procedures exist, but no approval trail or version control.
• Dissemination claimed, but no evidence (no publication record, no attestations, no references in operational playbooks).
• Multiple teams run risk assessments differently with no standard templates.

Frequent implementation mistakes (and how to avoid them)

1. Copy-paste policy language with no operational hooks
   Fix: require named roles, defined triggers, and record locations.

2. Dissemination treated as “sent an email once”
   Fix: publish in a controlled repository and capture access/attestation evidence.

3. Procedures don’t match how work happens
   Fix: align to your real tooling (ticketing, risk register, GRC system). Update steps to match the workflow teams follow.

4. No linkage to outputs
   Fix: require risk register entries to cite the procedure/template version used.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for RA-1. Practically, the risk is program failure during assessment: weak RA-1 often leads to broader findings because assessors cannot confirm consistent governance, repeatability, or evidence quality across the risk assessment lifecycle. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize)

• Name the RA-1 control owner and procedure owner.
• Inventory what you already have (policies, risk methodology docs, templates, risk register).
• Draft or revise the RA policy to match your actual scope and governance.
• Stand up a single controlled location for publication (GRC tool or controlled intranet folder) and define who must have access.

Next 60 days (operationalize)

• Write procedures that match real workflows (intake, analysis, approvals, outputs, tracking).
• Publish job aids for system owners/engineering so participation is frictionless.
• Build the RA-1 evidence packet structure and assign evidence collectors.
• Run a tabletop: take one system change or third-party onboarding and execute the procedure end-to-end, capturing artifacts.

By 90 days (prove repeatability)

• Complete at least one full cycle of document review/approval and capture the change history.
• Validate dissemination evidence: access lists, attestations, or training completion where your program uses them.
• Perform an internal audit-style check: pick recent risk assessments and verify they follow the documented procedure, including approvals and record locations.
• If using Daydream, implement recurring evidence tasks (policy review, dissemination verification, sample testing) so RA-1 stays current without heroics.

Frequently Asked Questions

What counts as “disseminate” for RA-1?

Disseminate means the right audiences can reliably access the current policy and procedures and you can prove it. A controlled repository plus access evidence or acknowledgements is typically stronger than one-off emails.

Do we need separate RA policy and RA procedures documents?

You need both a policy (management direction) and procedures (execution steps). They can be separate documents or a single controlled document with clearly separated sections, as long as both elements are present and approved.

How do we decide who the audience is for dissemination?

Base it on who must execute or comply with risk assessment activities: system owners, security staff, engineering, and stakeholders involved in risk acceptance. Document the audience list in the policy so it is not a guessing game during an audit.

Can our enterprise risk management (ERM) policy satisfy RA-1?

Sometimes partially, but assessors usually expect RA-1 to cover information system risk assessment practices at an actionable level. If ERM is too high-level, add a system-focused RA procedure and cross-reference ERM governance.

What evidence is most persuasive to an assessor?

A signed/approved policy and procedures, version history, a controlled publication record, and a small set of completed risk assessments that clearly follow the documented steps and approvals.

How do we keep RA-1 from becoming shelfware?

Embed the procedure into existing workflows (change tickets, SDLC gates, third-party onboarding) and require the procedure’s outputs (risk register entries, approvals) as completion criteria.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5