Risk Assessment

To meet the FedRAMP Moderate risk assessment requirement (NIST SP 800-53 Rev 5 RA-3), you must perform and document a repeatable assessment that identifies system threats and vulnerabilities, then evaluates the likelihood and magnitude of harm across confidentiality, integrity, and availability. Operationally, that means a scoped, evidence-backed method tied to your system boundary and used to drive control decisions and remediation. ¹

Key takeaways:

• Your RA-3 deliverable is a documented risk assessment method plus a system-specific risk assessment report tied to the authorization boundary. ¹
• Auditors look for traceability: threats/vulnerabilities → likelihood/impact → risk rating → treatment decision → tracked remediation. ¹
• The assessment must address unauthorized access, use, disclosure, disruption, modification, and destruction for information the system processes, stores, or transmits. ¹

A FedRAMP Moderate authorization expects your risk assessment to function as an operating discipline, not a one-time narrative. RA-3 is the baseline requirement that forces clarity on three points: what can go wrong (threats), where you are exposed (vulnerabilities), and what the business and mission impact looks like if the exposure is exploited (likelihood and magnitude of harm). ¹

For a CCO, GRC lead, or compliance operator, the fastest path to “audit-ready” is to treat RA-3 as a traceability problem. You need a defined method that your team can repeat, and you need evidence that you applied it to the actual system in scope, including all information processed, stored, or transmitted within the authorization boundary. ¹

This page gives you requirement-level implementation guidance: who needs to do it, how to run the assessment step-by-step, what artifacts to retain, and what exam teams typically challenge. It also includes a practical execution plan you can assign tomorrow.

Regulatory text

Requirement (RA-3): “Conduct a risk assessment, including identifying threats to and vulnerabilities in the system; determining the likelihood and magnitude of harm from unauthorized access, use, disclosure, disruption, modification, or destruction of the system, the information it processes, stores, or transmits, and any related information.” ¹

Operator interpretation: you must (1) perform a risk assessment for the system, (2) explicitly identify threats and vulnerabilities, and (3) evaluate likelihood and magnitude of harm for a defined set of adverse events (unauthorized access/use/disclosure/disruption/modification/destruction) affecting the system and its data. Your output must be sufficiently specific that a reviewer can see what you assessed, how you scored it, and what you decided to do about the risks. ¹

Plain-English interpretation (what the requirement really demands)

RA-3 requires a disciplined way to answer: “What could realistically happen to this system and its data, how bad would it be, and how likely is it?” Then you must show that your security program responds to those answers. If your risk assessment does not change priorities (patching, backlog order, compensating controls, monitoring, third-party constraints), exam teams treat it as paperwork.

The minimum “pass” pattern is:

• A documented method (your scoring model and how you identify threats/vulnerabilities).
• A system-scoped risk register (findings, scores, owners, treatment decisions).
• Evidence that high-risk items are tracked and addressed through remediation and/or risk acceptance.

Who it applies to

Entity scope: Cloud Service Providers seeking or maintaining FedRAMP Moderate authorization and Federal Agencies operating systems aligned to the FedRAMP Moderate baseline. ¹

Operational scope (what must be included):

• The system authorization boundary (your FedRAMP system, components, and supporting services in scope).
• Information the system processes, stores, or transmits, plus “related information” that could be impacted by the same adverse events. ¹
• Relevant third parties that materially affect the system’s risk posture (for example, hosting, identity providers, managed detection, ticketing, CI/CD tooling). RA-3 is system-focused, but third-party dependencies are often where threats and vulnerabilities concentrate.

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

1) Fix the scope before you assess

1. Confirm the system boundary (what is in/out).
2. Inventory major components: compute, storage, network, identity, key management, logging, SDLC pipeline, admin tooling.
3. Identify data types and flows (especially administrative access paths and interconnections).

Evidence: boundary diagram, data flow diagrams, component inventory.

2) Define your risk assessment method (make it repeatable)

Document a method that a different analyst could follow and reach similar conclusions. Include:

• Threat identification approach: where threats come from (for example, misuse cases, attacker actions, insider scenarios, dependency failures).
• Vulnerability identification approach: scanners, configuration reviews, code review inputs, pen test results, cloud posture findings, change management signals.
• Likelihood scoring rubric: clear definitions for what “high/medium/low” means in your environment.
• Magnitude of harm rubric: map harm to confidentiality, integrity, availability impacts, including mission/business consequences.
• Risk rating calculation: how likelihood and magnitude combine into an overall risk rating.
• Risk treatment options: mitigate, transfer, avoid, accept; with approval thresholds.

Tip: Keep the rubric simple enough to run consistently. Complex math models fail in audits because teams cannot explain scoring decisions.

Evidence: risk assessment procedure/methodology document.

3) Identify threats relevant to the system (not a generic library dump)

Run structured threat identification workshops with engineering, security, and ops. Ensure you cover the adverse events in RA-3 explicitly: unauthorized access, use, disclosure, disruption, modification, destruction. ¹

Concrete prompts that produce auditor-grade output:

• “How could an attacker gain admin access?” (credential theft, OAuth misconfig, session token replay)
• “How could data be disclosed?” (misconfigured storage, overly broad API responses, logging sensitive data)
• “How could service be disrupted?” (dependency outage, DDoS, misconfigured autoscaling, certificate expiry)
• “How could data be modified or destroyed?” (CI/CD compromise, ransomware, destructive IaC change)

Evidence: threat scenarios list, meeting notes/attendee list, linkage to system components/data flows.

4) Identify vulnerabilities with evidence-backed inputs

Aggregate vulnerability sources into one intake:

• Vulnerability scan results (infrastructure and containers)
• Cloud configuration findings (identity, storage exposure, network rules)
• Secure code review findings (OWASP-type issues, authZ failures)
• Pen test observations (where applicable)
• Operational incidents and near-misses

Normalize them so each item is traceable: unique ID, asset/component, description, evidence, date discovered.

Evidence: consolidated vulnerability register, scanner exports, pen test report excerpts, issue tracker links.

5) Score likelihood and magnitude of harm for each risk scenario

For each scenario, record:

• Threat actor/cause (external attacker, insider, third-party failure, admin error)
• Preconditions (what must be true for the scenario to occur)
• Existing controls that reduce likelihood (MFA, network segmentation, monitoring)
• Existing controls that reduce magnitude (encryption, backups, blast-radius limits)
• Likelihood rating and rationale
• Magnitude rating and rationale (C/I/A impacts)

Make the rationale specific. “High impact” with no explanation is where reviews stall.

Evidence: risk register entries with narrative justification.

6) Decide treatment and create a trackable plan

Each risk needs a decision:

• Mitigate: create remediation tasks with owners and due dates.
• Accept: document acceptance rationale and approval authority.
• Transfer: document contractual/insurance mechanisms where relevant.
• Avoid: document design change or feature removal.

Tie mitigations to controls and engineering work items so you can prove execution.

Evidence: remediation plan, risk acceptance memos, ticket links, control mapping notes.

7) Operationalize: make RA-3 a living input to governance

Establish:

• A cadence to refresh the assessment (trigger-based is often more defensible than calendar-only): major architecture changes, new data types, new third parties, significant vulnerabilities, incident learnings.
• A governance forum that reviews top risks and exceptions, with minutes and decisions.
• Reporting that connects risk posture to authorization artifacts and continuous monitoring.

Where Daydream fits naturally: teams often struggle with evidence traceability across scanners, tickets, architecture docs, and approvals. Daydream can centralize the RA-3 workflow so each risk item has linked evidence, assigned ownership, and a clean audit trail from discovery through closure.

Required evidence and artifacts to retain (audit-ready checklist)

Keep artifacts in a controlled repository with versioning and access control:

• Risk assessment methodology/procedure (how you do RA-3) ¹
• System-scoped risk assessment report (current state summary + top risks)
• Risk register (threat/vulnerability, likelihood, magnitude, risk rating, treatment)
• Supporting evidence for inputs: scan outputs, configuration findings, pen test excerpts, incident reports
• Risk treatment evidence: remediation tickets, change records, validation results (rescans), acceptance approvals
• Governance evidence: meeting minutes, sign-offs, escalation records

Common exam/audit questions and hangups

Expect reviewers to probe:

• Scope: “Show me your authorization boundary and prove the assessment covers it.”
• Specificity: “Why is this likelihood ‘medium’? What evidence supports it?”
• Completeness: “Where do you address disruption and destruction scenarios?” (RA-3 lists multiple harm types.) ¹
• Traceability: “Pick one high risk. Show discovery → scoring → decision → remediation → verification.”
• Repeatability: “If your lead analyst left, could someone reproduce this process?”

Frequent implementation mistakes (and how to avoid them)

1. Generic risk statements not tied to the system.
   Fix: require each risk to reference a component, data type, and threat path.

2. Vulnerability list equals risk assessment.
   Fix: convert vulnerabilities into scenarios with likelihood and magnitude of harm, per RA-3. ¹

3. No rationale for scoring.
   Fix: add a required “rationale” field and block approvals without it.

4. Risk acceptance without authority.
   Fix: define who can accept which level of risk and keep written approvals.

5. Assessment done once, never updated.
   Fix: define triggers (architecture change, new third party, major incident) and track refreshes as governance actions.

Enforcement context and risk implications

No public enforcement cases were provided in the approved source catalog for this requirement, so this page does not cite enforcement actions. Practically, RA-3 failures show up as authorization delays, significant POA&M expansion, or continuous monitoring findings because the program cannot justify control decisions or prioritization without a defensible assessment trail. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up the method and scope)

• Confirm authorization boundary, component inventory, and data flows.
• Publish the risk assessment methodology (rubrics, scoring, treatment rules).
• Create the risk register template and evidence standards (what must be attached).

Days 31–60 (run the assessment and produce decisions)

• Facilitate threat modeling workshops for key system areas (identity, admin plane, data plane, CI/CD).
• Consolidate vulnerability inputs into one register with deduplication.
• Score likelihood and magnitude of harm for prioritized scenarios.
• Start treatment actions for top risks and document any acceptances.

Days 61–90 (prove it operates and is traceable)

• Run a governance review of top risks with recorded decisions.
• Validate remediation with rescans or control tests; link results back to the register.
• Produce an auditor-ready risk assessment report snapshot (current risks, trends, top treatments).
• Implement change triggers so new services/third parties cannot go live without risk intake.

Frequently Asked Questions

Do we need a separate RA-3 risk assessment if we already have an enterprise risk program?

Yes, because RA-3 is system-specific and must cover threats and vulnerabilities in the system and the information it processes, stores, or transmits. Your enterprise program can provide the method, but you still need system-scoped outputs and evidence. ¹

What’s the minimum an auditor will expect to see for “likelihood and magnitude of harm”?

A documented rubric plus a risk register where each item includes a likelihood rating, an impact (magnitude) rating, and a written rationale tied to the system context. The rationale should reference existing controls and realistic preconditions. ¹

How do we handle third-party risks under RA-3?

Include third-party dependencies in your threat scenarios and vulnerability sources where they affect your system boundary and data flows. Capture the dependency, failure modes, and any contractual or technical controls that reduce likelihood or impact. ¹

Can we accept risks instead of fixing them?

RA-3 does not forbid acceptance, but you must document the likelihood and magnitude of harm and keep explicit approval evidence for the acceptance decision. Define who can accept which risks and why. ¹

What’s the most common reason RA-3 evidence gets rejected in review?

Missing traceability. Reviewers cannot follow one risk from identification (threat/vulnerability) through scoring to treatment and verification, or they cannot confirm the assessment covers the full system boundary. ¹

How should we show the assessment stays current?

Maintain a change-triggered refresh process and keep dated versions of the risk assessment report and register. Tie refreshes to architecture changes, newly onboarded third parties, major vulnerability disclosures, and incident learnings. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5