RA-3 Risk assessment: requirements and evidence

What RA-3 risk assessment asks for and why assessors start there

If an audit, a FedRAMP package or a customer contract requires RA-3, the first thing to establish is that it is a demand for a documented, current risk assessment of the system, not a one-time exercise. RA-3 asks the organization to identify threats and vulnerabilities, estimate the likelihood and impact of harm if they are exploited, and record the results in a form that other people can read, challenge and act on. The harm is not limited to the organization's own losses. Where the system processes personally identifiable information, the assessment must also consider harm to the individuals whose data it holds, which is why privacy teams usually need a seat in the review. Assessors start here because every other risk-driven decision in the program, from which controls to prioritize to how plan of action and milestones entries are justified, depends on this document.

The control also asks that organization-level and system-level risk results be brought together. An enterprise risk register that says a threat is accepted at the program level cannot quietly contradict a system assessment that rates the same threat as high. Assessors typically request the assessment report, the method used to reach its likelihood and impact ratings, the reviews that were performed, and the updates recorded after significant changes such as a new interconnection, a major release or a change in hosting. Confirm with your authorizing official or assessor which review interval and triggering events your organization must meet, because those are set by the organization and by the governing program rather than by the control text alone.

Undocumented or stale assessments are the most common weakness assessors find under this control. A risk assessment written at authorization and never revisited will not reflect new vulnerabilities, new data types or new third parties, and an assessor will ask how the ratings were updated since. Before the assessment is requested, check that each threat and vulnerability has an owner, a rating rationale, a date, and a link to the scan results and remediation records that feed it. For FedRAMP work, also confirm how RA-3(1), the supply chain risk assessment enhancement, is covered, since FedRAMP's Rev5 baselines require it at the classes it names. Preparing this material is work your team or an implementation partner can carry out, but only the independent assessor will judge whether it meets the requirement.

Which systems, data and teams RA-3 risk assessment covers

RA-3 applies wherever a system, its data or its supply chain creates risk, but the amount of work depends on a few scoping choices made before any assessment starts. RA-3 is assigned to the low, moderate and high security control baselines and to the privacy baseline, so the impact level and the privacy scope both shape what must be assessed.

Setting the system boundary

The boundary defines which hardware, software, data stores, interfaces and administrators the risk assessment must cover. A narrow boundary shortens the threat and vulnerability analysis, but any component left outside it still needs an owner who can show it does not affect the assessed system. Confirm the boundary against the system security and privacy plan before scoping the assessment, and record every interconnection that crosses it.

Impact level from RA-2

The security categorization from RA-2 selects the low, moderate or high baseline, and that baseline determines how many RA-3 enhancements apply. In SP 800-53B, the low, moderate and high baselines all select RA-3(1), so the categorization changes the depth of the assessment rather than whether RA-3 applies. Ask the authorizing official to confirm the categorization rationale before the assessment plan is drafted.

Privacy baseline scope

RA-3 also appears in the privacy baseline, so any system that processes personally identifiable information must have its risk assessment address harm to individuals, not only harm to the organization. This adds effort in data mapping, purpose review and identification of the people affected. Teams should confirm which PII flows are in scope and who in the privacy office signs off on the likelihood and impact estimates.

Organization-level versus system-level

RA-3 expects results from organization-level assessments to be integrated with system-level results. A system-level assessment alone may miss shared threats such as a common identity provider or a central logging service, while an organization-level assessment alone may not capture the specific weaknesses of one system. Decide early which shared services feed the organization-level view, and assign a named owner to reconcile the two.

Third-party components inside the boundary

Vendor-supplied software, managed cloud services and external developers add threats that the organization does not directly control. Each third party whose component enters the boundary must be identified and its risks assessed, and FedRAMP's Rev5 baselines add supply chain risk expectations at RA-3 for the classes they cover. Ask suppliers for their own security documentation and update the assessment when a supplier changes.

How an assessor tests RA-3 risk assessment

This table maps the SP 800-53A examine, interview and test methods for RA-3 to the objects an assessor asks for and the findings that commonly appear. Read each row as a question the assessor will put to your risk assessment program, with the evidence that answers it. Most findings trace back to a risk assessment that lists threats but does not show how likelihood and impact were judged or how the results were reviewed.

Assessment method	What the assessor looks for	Common findings and evidence requested
Examine: risk assessment	A documented risk assessment that names threats and vulnerabilities for the system and its information, with likelihood and impact estimates for each identified harm	Threats listed without likelihood or impact ratings. Evidence: the current risk assessment report with its scoring method and rating for each risk
Examine: risk assessment results	Results tied to organization-level and system-level risk, and to the system boundary the assessment covers	No link to the system boundary or to the data flows in scope. Evidence: system inventory and boundary diagram cross-referenced to the assessed components
Examine: harm to individuals	Consideration of harm to individuals from processing personally identifiable information, where the system handles PII	Privacy harms absent from the assessment. Evidence: the privacy risk section of the assessment and the PII inventory it draws on
Examine: risk assessment reviews	Records showing the assessment was reviewed and the review outcome, with named reviewers and dates	Missing review dates or reviews that do not record decisions. Evidence: signed review minutes, approval records and change log entries
Examine: risk assessment updates	Evidence the assessment was updated at the defined interval and after significant changes to the system	Assessment dated before a major architecture or vendor change with no update. Evidence: change tickets linked to assessment revision history
Interview: system owners and risk officers	Staff explain how threats were identified, how ratings were agreed and who approves residual risk	Staff cannot explain the rating method or disagree on who accepts risk. Evidence: named roles in the policy and the approval record for each decision
Test: risk determination sample	Assessor selects risks and traces each one to its threat source, rating and treatment decision	Ratings that cannot be reproduced from the stated method. Evidence: the scoring worksheet and the RA-7 treatment record for sampled risks
Test: vulnerability input to the assessment	Vulnerabilities used in the assessment match current scan and finding data for the system	Assessment built on scan results that are months old or from a different scope. Evidence: scanner reports and finding exports dated near the assessment

How to implement RA-3 risk assessment step by step

This sequence turns RA-3 into a repeatable risk assessment that starts from a defined system boundary and ends with a documented report that decision makers have reviewed, with clear triggers for updating it.

Confirm the system boundary and categorization
Start by confirming which system, components, data and services the assessment covers, and reading the security categorization that RA-2 produced for them. The control owner, usually the system owner with the information security lead, records the boundary, the information types processed (including personally identifiable information) and the impact levels that select the baseline. The output is a short scope statement that names the boundary, the categorization and the people accountable for the assessment. Confirm the categorization with the authorizing official before any analysis begins, because every later judgment depends on it.
Define the assessment method and scales
Before analysis starts, the team agrees how it will rate threats, vulnerabilities, likelihood and impact. The method should state the scales (for example, the number of levels and what each means), how likelihood and impact combine into an overall rating, and how organization-level and system-level results will be integrated. Write the method into the risk assessment policy and procedures (RA-1) so the rating is consistent across systems. The output is an approved method document with scale definitions and a worked example that shows how a rating is produced. Ask the assessor to confirm that the method is defensible for the organization's own environment.
Identify threats and vulnerabilities from current inputs
Gather threat and vulnerability inputs for the boundary. Vulnerability data typically comes from authenticated scan results (RA-5), configuration reviews, penetration test findings and open items in the plan of action and milestones. Threat inputs come from sector information sharing, threat intelligence feeds and internal incident history. Open-source tools can consolidate this work: DefectDojo can import and deduplicate findings from many scanner report formats, Greenbone Community Edition stores scan results in PostgreSQL for review, and MISP can hold and correlate indicators shared within trusted communities. The output is a consolidated list of threat scenarios and vulnerabilities, each linked to the asset and its source, with duplicates removed.
Estimate likelihood and impact of harm
For each threat and vulnerability pair, the team estimates the likelihood that harm occurs and the impact if it does. Impact must include harm to individuals from processing personally identifiable information, not only harm to the organization or mission. Record the existing controls that reduce likelihood or impact and the reasoning behind each rating, so an assessor can retrace it. Two qualified reviewers should rate the highest-impact items independently, and disagreements should be resolved and written down. The output is a rated risk register where every entry shows its inputs, the existing controls considered and the resulting rating.
Produce the risk assessment report
Combine the rated register, the method, the scope and the inputs into a risk assessment report. The report should also explain how organization-level risk relates to system-level results, state which findings are accepted, mitigated or referred to risk response (RA-7), and list the assumptions and limitations of the analysis. The system owner approves the report, and the authorizing official or designee reviews it. The output is a signed and dated report stored under document control. Only an independent assessor can attest that the process meets the control; the report is the organization's own evidence.
Share results with decision makers
Distribute the report to the people who must act on it, including the authorizing official, system owner, information security leadership, privacy officer where personal data is involved, and the owners of any risks marked for treatment. Distribution should follow the sharing rules in the organization's own policy, and the recipients should be recorded. Each risk requiring a decision should be logged in the plan of action and milestones with an owner. The output is a distribution record and confirmed decisions for every high-rated item, which an assessor will check against the report.
Set review and update triggers
Define when the assessment must be reviewed and updated. RA-3 ties updates to defined intervals and to significant changes, so the organization should set its own interval in policy and list the events that trigger an early update, such as a new system component, a major change to data types, a significant vulnerability disclosure or a confirmed incident. Confirm these triggers with the authorizing official and the assessor, and align them with continuous monitoring. The output is a review schedule and a trigger list attached to the report, along with a record of the last review and who performed it.

Evidence that passes an RA-3 risk assessment review

An assessor testing RA-3 samples documents that show the organization identified threats and vulnerabilities, assessed likelihood and impact, reviewed results, and updated them when conditions changed. The six artifacts below connect to one another, so a gap in one usually shows up in another. Each card describes how to keep the artifact current between assessments, because a report written once and never revisited will not satisfy the review and update tests.

The risk assessment report

This is the primary record of RA-3 and must state the threats and vulnerabilities considered, the likelihood and impact determinations, and the resulting risk for each finding, including harm to individuals from PII processing. Keep one versioned report per system and per organization-level scope, and check that it integrates both levels as the control requires. Between audits, add a revision entry whenever a finding changes status so the current version always matches the open risk register. Confirm each finding has an owner and a current status.

The method and scales document

This document defines how the organization rates likelihood, impact and overall risk, so an assessor can check that two assessors reaching the same inputs would reach comparable ratings. It should name the scales, the thresholds that separate acceptable from unacceptable risk, and the assessors' roles. Review it at the interval the organization sets and whenever the scoring model changes, and record the reason for each change. Assessors often ask why a rating moved, and this document is the answer.

Threat and vulnerability input records

Assessors trace each rated risk back to the threat intelligence, scan results, penetration test findings and audit observations that informed it. Store these inputs with dates and sources, such as vulnerability scanner exports or threat feed extracts, so the trail can be replayed. Refresh the inputs before each assessment cycle, since a rating based on last year's scan output will not reflect current exposure. Where scanner output is imported into a findings platform, keep the import records alongside the report.

The review log with dates and approvers

RA-3 requires the risk assessment to be reviewed at defined intervals. The review log records each review date, the people who reviewed it, the decisions they made and the signature or approval of the accountable official. Assessors compare these dates against the interval in your own policy, so the interval set in RA-1 governance and the dates in this log must agree. Add an entry for every review, including reviews that changed nothing, because an empty interval is a finding.

Update records tied to significant changes

The control also requires updates after significant change, so keep a register that links each change to the risk assessment revision it triggered. Typical triggers include a new hosting environment, a major software upgrade, a new data type or a change in connected third parties. For each entry, record the change, the date the assessment was reopened and the date it was completed. Confirm the change process in configuration management feeds this register, because changes that never reach the risk team are the most common gap assessors find.

The sharing record for results

RA-3 expects results to be shared with designated officials and other stakeholders who depend on them. The sharing record names each recipient, the version they received, the date and the channel. Keep it current by logging each new distribution and each acknowledgment, and by removing recipients who change roles. This record also supports supply chain risk work, since FedRAMP's rules tie the RA-3 enhancement to supply chain risk monitoring. Confirm that every recipient received the current version, not an earlier draft.

What meeting RA-3 risk assessment costs in money and effort

This table breaks the cost of RA-3 into components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to shape a quote request, since no supplied figures set prices or durations for this work. The main takeaway is that open-source tools mainly remove license spend, while analyst time, method design and independent review remain the largest variables.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up or down
Assessment method design	Internal risk lead or implementation partner defines method, scales, thresholds and scoring	One-time, revisited on change	Number of impact scales, threat sources and how many organization and system levels the method must cover
Analyst and engineering time	Internal analysts, engineers and system owners who identify threats, vulnerabilities and likelihood	Recurring, per assessment cycle	System count, boundary complexity, number of data types including PII, and how many third-party services sit in scope
Tooling and licenses	Commercial risk or GRC vendors, scanner and findings platforms	Recurring subscription or maintenance	Open-source options such as CISO Assistant, DefectDojo, Greenbone and MISP remove license fees but still need hosting and administration effort
Self-hosted infrastructure and administration	Platform engineers who host, back up, upgrade and secure the tools	Recurring	Number of tools deployed, scan volume, data retention periods and whether the tools run in an air-gapped network
Scan and findings triage	Security engineers who review scan output, deduplicate findings and feed results into risk decisions	Recurring, per scan cycle	Scan volume, number of assets, quality of authenticated scanning and how well deduplication is tuned
Evidence upkeep	Compliance leads who keep assessment reports, review records and update logs current	Recurring	Review frequency, number of triggering events such as significant change, and whether evidence is generated automatically
External review of the assessment	Independent assessor or consultant who reviews method and results before authorization or contract submission	Recurring at each assessment or authorization event	Assessor's own scope, number of systems reviewed, and whether the organization prepares complete documentation first
Auditor sampling time	Independent assessor who examines samples of risk assessments, results, reviews and updates	Recurring at each audit or assessment	Number of risk assessment cycles in the audit period, sample size chosen by the assessor, and quality of records
Supply chain risk enhancement work	Procurement, legal and engineering staff who assess suppliers and document results where FedRAMP applies	Recurring, per supplier and per cycle	Number of third-party providers, contract terms and whether supplier evidence is already collected

Open-source tools that produce RA-3 risk assessment inputs

RA-3 asks the organization to identify threats and vulnerabilities, estimate likelihood and impact, and document the results. The tools below do not make those judgments. They gather, normalize and correlate the findings, indicators and framework mappings that an assessor will ask to see behind each risk decision, and they keep records of those decisions over time.

Consolidating scanner findings in DefectDojo

DefectDojo imports and reimports findings from more than 500 security tool report formats through its UI or API, including the open source edition, and it has a generic findings import for other sources. It deduplicates findings using per-tool hashcode fields, so one vulnerability reported by several scanners does not inflate the risk picture. Check that the hashcode settings match each scanner you run, and keep the import history, since assessors often ask how the findings feeding a risk assessment were produced. The deduplication rules are your decision, so document them. Licensed under BSD-3-Clause.

Vulnerability results from Greenbone Community Edition

Greenbone Community Edition (OpenVAS) runs through gvmd, which stores scan results in PostgreSQL, manages users and permissions, and schedules scan tasks. Users run scans and review results in the Greenbone Security Assistant web interface. For RA-3, this gives you dated, scoped vulnerability data that can feed the likelihood side of an assessment. Confirm which scan targets and credentials are covered, because gaps in coverage become gaps in the assessment. Licensed under AGPL-3.0-or-later.

Threat indicator correlation in MISP

MISP correlates indicators by exact match and by advanced patterns such as fuzzy hashes and CIDR overlaps. It synchronizes events between MISP instances using distribution levels and sharing groups, records sightings, and exports to STIX 1 and 2, CSV, and Suricata, Snort and Zeek rule formats through its REST API. These capabilities support the threat side of RA-3, showing which adversary activity has been observed against your sector or assets. Define sharing rules before you connect instances to external communities. Licensed under AGPL-3.0-only.

Framework mapping and assessment records in CISO Assistant

CISO Assistant ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and it runs audits and compliance assessments with automatic mapping between frameworks. It can hold the risk assessment record alongside the controls it touches. Treat automatic mappings as starting points, and have someone accountable confirm each one against the NIST control text before relying on it for an assessor. Licensed under AGPL-3.0-only.

What the RA-3 supply chain risk enhancement adds for FedRAMP

For a cloud service seeking FedRAMP authorization, the key point is that RA-3(1) is required alongside RA-3. FedRAMP's Rev5 baselines require RA-3 and RA-3(1) at Classes B, C and D, and SP 800-53B selects RA-3(1) in the low, moderate and high baselines. The enhancement therefore extends the base risk assessment from the system's own threats and vulnerabilities to the parties and parts that supply it. Read the exact wording in the FedRAMP Risk Assessment control reference before you scope your assessment, because the enhancement's text and the FedRAMP rules are what an assessor will test against.

For a cloud service, supply chain risk assessment means looking at everything that enters the authorization boundary from outside your direct control. That includes hosting and infrastructure providers, managed service and support vendors, software and container base images, open-source packages and their upstream maintainers, hardware, and third-party integrations or telemetry services that handle system data. An illustrative case: a logging agent pulled from a public repository with a short maintenance history would appear in the component inventory, and the assessment would record how it is obtained, how it is verified and what happens if its maintainer stops releasing fixes. Decide which suppliers and components feed the assessment, who owns each entry, and how the results link back to the RA-3 risk assessment report.

FedRAMP 20x connects RA-3 to several Key Security Indicators, including KSI-SCR-MIT (mitigating supply chain risk), KSI-SCR-MON (monitoring supply chain risk), KSI-MLA-EVC (evaluating configurations) and KSI-SVC-EIS (evaluating and improving security). This means supply chain findings are expected to show up in ongoing evidence about monitoring and mitigation, not only in an annual document. Confirm the current requirement, its classes and its indicator mapping in the FedRAMP rules repository, using the consolidated rules version your assessor and authorizing body apply. Ask your assessor which supplier evidence they expect at each class before the assessment starts.

Who owns RA-3 risk assessment: your team, a partner and the auditor

Your organization owns RA-3. The control asks that risk assessments be carried out, documented, reviewed, shared and updated, and those decisions belong to the people accountable for the system and its mission. Your team identifies the threats and vulnerabilities that matter for its environment, judges likelihood and impact (including harm to individuals from PII processing), decides how identified risks are handled, and signs off the risk assessment report. Risk acceptance is a management decision, and an assessor will look for it in writing, with a named approver and a date.

Threat and impact judgment: Decide which threat sources and scenarios apply to your system and document the reasoning behind each likelihood and impact rating.
Risk acceptance: Record who accepted each residual risk, under what authority, and the review date.
Report ownership: Keep the risk assessment report as an internal document that your authorizing or accountable official approves.
Review triggers: Define the review interval and the significant changes that force an update, then follow them.
Policy alignment: Confirm that the RA-1 policy and procedures name the owner of each step.

Confirm with your compliance lead which internal roles sign each artifact before any partner work begins, because that list drives the rest of the engagement.

Questions buyers ask about RA-3 risk assessment cost, effort and audits

How much effort does RA-3 risk assessment take?

The effort depends on the system's size, its boundary, how many threats and vulnerabilities the team must analyze, and how many risk assessment cycles already exist. No researched figure for hours or duration is available here, so ask any provider for a written breakdown of work by phase: scoping, threat identification, vulnerability input, likelihood and impact estimation, report drafting, and review. The first assessment is usually the largest effort because the method, templates and inputs are built from scratch. Later updates are smaller if the inputs are maintained. Confirm the estimate against your own system inventory and existing scan and incident data before you commit budget.

Can a team complete an RA-3 assessment without a partner?

Yes, an internal team can complete RA-3 if it has people who understand the system architecture, the threat landscape and the organization's risk method. RA-3 is an organization-owned control, so the organization must make the risk decisions and approve the report. A partner adds value mainly where the team lacks security engineering capacity, needs help standing up open-source tooling for evidence, or wants an independent second review. Whichever route you take, the assessment itself must be documented, reviewed and shared with the right decision makers.

What inputs must our team supply for an RA-3 assessment?

The team supplies the material that the assessment analyzes. The usual inputs are:

An accurate system description and boundary, with data types, including personally identifiable information where it is processed
Architecture diagrams, data flows and interconnections
Current vulnerability scan results and their remediation status
Threat information relevant to the sector and system, such as incident history and intelligence feeds
Organization-level risk context, such as the risk tolerance and the risk register
Results of prior assessments, audits and plans of action and milestones

Without these inputs, the assessment cannot show how threats and vulnerabilities were identified or why likelihood and impact were estimated.

How often must an RA-3 risk assessment be updated?

RA-3 requires the risk assessment to be updated at an organization-defined frequency and after significant changes. The frequency is a parameter you set, so confirm the value in your own policy and in any contract or FedRAMP obligation that applies. Plan updates for significant changes to the system, new threat information, major vulnerability findings, and changes to the boundary or data types. Your assessment should record the review date, who reviewed it and what changed, so an assessor can see the cycle in operation.

What will an auditor sample when testing RA-3?

Assessors test RA-3 with the examine, interview and test methods described in SP 800-53A. For RA-3, the examine objects include the risk assessment, the risk assessment results, the risk assessment reviews and the risk assessment updates. Expect the assessor to sample the current assessment, earlier versions, evidence of review and sharing, and records showing updates after significant changes. They will also interview the people who own the assessment and the people who act on its results. Keep the report, review records, change records and linked risk decisions easy to retrieve. Confirm the exact sample size with your assessor, because it is their decision.

Can a partner produce the RA-3 risk assessment alone?

A partner can prepare systems, data, scanning and evidence, and help draft the assessment, but the organization must own the risk decisions and approve the final report. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports or attestations. Independent auditors or certification bodies assess the result. Ask any partner to state in the written scope which parts they draft, which parts you review and approve, and which evidence you must retain. Fixed-scope agreements make these responsibilities explicit before work starts.

How do RA-3, RA-5 and RA-7 work together?

RA-3 produces the assessment that identifies threats, vulnerabilities, likelihood and impact. RA-5 supplies much of the vulnerability input through monitoring and scanning, so scan results feed the next RA-3 update. RA-7 then takes the risks identified in RA-3 and records how each one is accepted, mitigated, transferred or avoided, usually through the plan of action and milestones. In practice, a scan finding from RA-5 moves into the RA-3 analysis, and the decision it leads to is recorded under RA-7. Confirm how your organization links these three records so an assessor can trace a finding from detection to decision.

How DeployOpen prepares RA-3 risk assessment evidence

DeployOpen plans, implements and documents self-hosted open-source platforms that produce RA-3 evidence inside the client's own infrastructure. The organization owns its risk assessment decisions, and an independent assessor is the party who tests them and issues any report.

How we scope

Agree which systems, boundaries and organizational units the RA-3 risk assessment must cover, in writing before work starts.
Confirm the impact level and baseline with the organization so RA-3 and RA-3(1) match its selected controls.
Define the review triggers, update intervals and supply chain risk enhancement scope the written engagement will address.

How we build

Set up self-hosted vulnerability scanning and findings tracking so threat and vulnerability inputs are recorded consistently.
Configure a risk register template that records likelihood, impact, threat sources and affected assets for each assessed item.
Integrate scanner output, threat intelligence and asset inventory data so organization and system level results can be combined.

How we hand over

Deliver the risk assessment report template, populated with the findings and rationale the organization approves.
Provide documented review and update records showing when assessments were revisited and who approved each change.
Hand over runbooks and configuration documentation so the organization's staff can repeat the process without DeployOpen.

How we support

Offer ongoing support and upgrades for the platforms, available as a retainer after the fixed-scope engagement ends.
Run continuous security testing as a retainer when the organization wants periodic checks of the evidence pipeline.
Confirm with the organization's independent assessor which artifacts they need, and adjust the evidence set before the assessment.

RA-3 Risk assessment