RA-7 Risk response: requirements and evidence

What RA-7 risk response requires and why assessors check it

If an upcoming assessment or authorization includes RA-7 in its baseline, the question you will face is whether your organization decides what to do about each finding from its assessments, monitoring and audits, in line with its risk tolerance. RA-7 requires a documented response to every relevant finding, not just a record that the finding exists. The control is in the low, moderate and high security baselines and in the privacy baseline, so it applies whatever the impact level of the system. In Release 5.2.0 of SP 800-53 Rev. 5, RA-7 has no organization-defined parameters and no control enhancements, so the assessor works from the base control alone and from your own stated risk tolerance.

The risk it addresses is familiar to every assessor: findings that are logged in a scanner, an audit report or a penetration test report and then never decided. Without a recorded decision to accept, mitigate, transfer or avoid each one, the organization cannot show that its risk tolerance is actually being applied. The control is hard to meet for a practical reason. The inputs come from the risk assessment, vulnerability scans, control assessments, incident reviews and internal audit, and each is usually owned by a different team in a different tool. The decisions often sit in email threads or meeting notes rather than in one place.

Before the assessment, confirm three things with your assessor: how your risk tolerance is written down and who approved it, which sources of findings count as in scope for RA-7, and what evidence they will sample. In the SP 800-53A procedures for RA-7, examine objects include assessment reports and audit records or event logs, so expect to show a sample of findings traced from source to decision. Your plan of action and milestones is the natural place to record each decision. Ask your assessor whether the sample will be drawn from the ticketing and scanning records you already hold, because that determines how much reconciliation work you need to do first.

Which systems, findings and decisions fall under RA-7

RA-7 applies wherever an organization has a system at a selected baseline and a stream of findings to act on. The cards below cover the scoping choices that change the work, the finding sources that feed the control, and the people and third parties who own each response decision.

Systems inside the selected baseline

RA-7 is assigned to the low, moderate and high baselines and to the privacy baseline in SP 800-53B, so the impact level chosen under RA-2 determines whether the control applies at all. Confirm which authorization boundary each baseline covers, including shared infrastructure and inherited controls. A system that falls outside the boundary still needs a documented decision about who responds to its findings.

Assessment and audit findings

Findings from control assessments, independent audits and penetration tests are the most formal input to RA-7. The assessment report and audit records are also examine objects in SP 800-53A, so assessors will ask to see how each finding moved from report to decision. Check that every finding has an owner, a recorded decision and a link to a plan of action and milestones entry.

Continuous monitoring and scan results

Vulnerability scan output, security alerts and monitoring trends arrive continuously and in volume, so they need a triage path before they reach a risk decision. Decide which findings trigger a response review, which are handled through routine patching, and how duplicates from several tools are merged. Scanning itself belongs under RA-5, but RA-7 governs what the organization does with the results.

Risk tolerance and decision authority

RA-7 requires responses that match the organization's risk tolerance, so the tolerance must be written down before a finding can be judged against it. Name who may accept a risk, who may approve mitigation or transfer, and at what severity each level of approval applies. Without this mapping, the same finding can be closed by an engineer in one team and escalated by another.

Operations teams and ticketing workflow

Accepted, mitigated, transferred and avoided risks all become work for engineering, operations or procurement. Confirm which team owns each ticket, how the ticket links back to the finding and the risk decision, and how changes to production are approved. Reviewers will look for a clear trail from the decision to the completed remediation, not only a closed ticket.

Third parties and inherited risk

Cloud providers, managed service providers and software suppliers may own the response to findings in parts of the system you depend on. Document which party decides and acts for each component, and what your organization retains as the accountable owner. Shared responsibility agreements should state how external findings reach your risk register and how quickly they must be reviewed.

How accepting, mitigating, transferring and avoiding risk differ on paper

Each of the four response options leaves a different paper trail, and an assessor will check that the record matches the decision. Under RA-7, the organization responds to findings from risk assessments, monitoring and audits in line with its risk tolerance. Mitigation is recorded as a change to the system or its controls, with the control that changes, the owner, the target date and the expected effect on likelihood or impact. Avoidance is recorded as a decision to stop the activity, retire the component or decline the data flow, with the business consequence named. Transference is recorded as a contract, insurance or outsourcing arrangement, with the clause or policy that moves financial exposure, and the reminder that accountability for the control objective usually stays with the organization.

Acceptance is the option that most often lacks support in the file. An accepted risk needs a written rationale, the name of the owner who approved it at a level that matches the risk tolerance, the compensating measures that still operate, and the residual risk stated in the same terms used by the risk assessment. Confirm with your own governance documents who may approve each rating and whether the authorizing official must sign off on a system-level acceptance. The inputs come from RA-3 risk assessment results, which name threats, vulnerabilities, likelihood and impact, and from RA-2 categorization, which sets the impact level that affects how much residual exposure is tolerable. Those inputs do not produce a fixed answer, so the record should show the reasoning rather than only the label.

For an implementation partner, the practical job is to make these records traceable. Each risk item in your register should link to the finding it came from, the response chosen, the approver, and the plan of action and milestones entry if work is still open. Confirm how your tracking tool handles acceptance expiry and re-review. Open-source ticketing platforms such as GLPI can hold the approval workflow and the mitigation tasks, and a findings platform such as DefectDojo can carry the source findings and their status, but neither decides the response. Ask your assessor which record types they expect to sample for RA-7 and whether they want acceptances reviewed on a fixed cycle.

How an assessor tests RA-7 under SP 800-53A

This table walks through how an assessor tests RA-7 Risk response under SP 800-53A Release 5.2.0, one test method at a time. Read each row as a question the assessor will ask and the evidence the organization should have ready before the assessment begins.

Test element	What the assessor does	Evidence the organization should prepare
Determination statements	Four statements are tested, each requiring a finding of satisfied or not satisfied. Each statement must be supported by at least one method and assessment object.	A written mapping from each determination statement to the procedure, owner and artifact that supports it.
Examine method	Reviews assessment reports and audit records or event logs to confirm that findings were answered with a documented response in line with stated risk tolerance.	Risk assessment and audit reports, the risk response register, and event logs or ticket histories showing each finding's disposition and date.
Interview method	Asks the risk owner, system owner and security staff how responses are chosen, who approves acceptance, and how residual risk is escalated.	Named roles with documented responsibilities, a short walkthrough of the decision path, and staff who can explain a recent example without notes.
Test method	Selects sample findings and checks whether the chosen response (accept, mitigate, transfer or avoid) was carried out and whether its outcome was verified.	Records for sampled findings showing remediation or compensating control work, retest results and closure approval.
Risk tolerance link	Checks that responses reflect the organization's documented risk tolerance rather than ad hoc judgment.	A current risk tolerance statement, the approval record and examples of decisions traced back to it.
Common finding: decisions without owners	Accepted or transferred risks with no named approver or no expiry date are commonly reported as unsatisfied.	An acceptance record per risk with an accountable approver, a review date and the rationale recorded.
Common finding: no recorded disposition	Findings that appear in assessment reports or scans but have no status, response or closure record are a frequent gap.	A single register linking each finding to its response, plan of action and milestones entry, and closure evidence.
Tooling note	Assessors generally accept any system that preserves timestamps, approvals and history. The organization must confirm the platform's audit trail meets the assessor's expectations.	Confirm with the assessor which record formats are acceptable, and whether exports from the ticketing or findings tool are sufficient.

How to implement RA-7 step by step

This sequence turns scattered findings from risk assessments, monitoring and audits into a single decision record, so every finding ends with a documented response, a named owner and a tracked path to closure or a reviewed acceptance.

Set risk tolerance and response criteria
Work with the authorizing official or accountable executive to define how much risk the organization will tolerate, which impact and likelihood levels require which response, and who may approve an acceptance. RA-7 ties responses to risk tolerance, so this step sets the rules every later decision is measured against. Output: a written risk tolerance statement and a response matrix, approved by the people who own the risk, and filed with the risk management documentation.
Identify every finding source and its owner
List each input that produces findings: risk assessments under RA-3, vulnerability scans under RA-5, control assessments and audits, penetration test reports, continuous monitoring results and incident lessons learned. Name the team that owns each source and the format it delivers in. Output: a source register that shows where findings originate, so no feed is missed when the intake is built.
Route all findings into one intake
Send findings from every source into a single tracked queue, such as a ticketing system or a vulnerability management platform, so each finding gets one record with its origin, affected system, impact rating and date received. Deduplicate findings that repeat across tools. Output: one intake queue where each finding has a unique identifier and no finding exists only in an email or a spreadsheet tab.
Record a decision for each finding
Assess each intake item against the response criteria and record one of four decisions: accept, mitigate, transfer or avoid. The record should name the decision owner, the rationale, the affected system and any compensating controls. Output: a decision record for every finding, approved at the level the tolerance statement requires. An accepted risk without an approver or rationale fails this step.
Track mitigations to closure in the POA&M
For each finding decided as mitigate, open or update an entry in the plan of action and milestones with the weakness, the planned corrective action, the responsible owner and the milestone schedule set by the organization. Record status changes and closure evidence, such as a rescan result or a configuration record. Output: a POA&M in which every mitigation has an owner, a dated milestone and closure evidence, and no item is closed on assertion alone.
Document transfer and avoidance decisions
Where a finding is transferred, for example to a cloud provider under a shared responsibility model or to an insurer, record the contract or agreement that moves the obligation and confirm the receiving party accepts it in writing. Where a finding is avoided, record the decision to stop the risky activity or retire the component and verify the change in the system inventory. Output: signed or retained agreements for transfers and change records for avoidance, each linked to the original finding.
Review accepted risks on a set cycle
Put every accepted risk on a review calendar with the review interval set by the organization's policy. At each review, confirm the risk still falls within tolerance, check for changed conditions such as new exploit activity or system changes, and renew or reopen the decision. Output: dated review records for each accepted risk, with renewals approved by the original decision owner or a higher authority.
Report response status to governance
Summarize open findings, decisions by type, overdue POA&M milestones and accepted risks for the governance body that owns risk tolerance. Use the summary to adjust tolerance, funding or priorities when patterns emerge. Output: a recurring risk response report with minutes or decisions recorded, which an independent assessor can trace back to individual finding records.

Evidence that passes RA-7 and how to keep it current

An assessor testing RA-7 looks for a trail that runs from a finding to a documented decision and then to a closed or tracked outcome. The cards below cover the records that make up that trail and the routine checks that keep each one accurate between formal assessments.

Risk response decision records

Each decision to accept, mitigate, transfer or avoid a risk should record the finding, the chosen response, the rationale, and the name and role of the approver. Assessors test whether the response matches the organization's stated risk tolerance, so the rationale should cite that tolerance explicitly. Check that every open finding has a recorded decision and that no approver has left the role without a handover.

POA&M entries linked to findings

A plan of action and milestones entry should point back to the specific assessment, scan or audit result that created it, with a responsible owner and a target date for each step. Entries that exist without a source finding are hard to defend, and findings that never reach the POA&M suggest the response process is not running. Review the register on a fixed cadence and record each change with its date and reason.

Accepted-risk register with review dates

Risks the organization decides to accept need their own register, listing the accepted condition, the compensating controls, the approver and a review date. Acceptance is not permanent, so the register should trigger re-review when the system changes, when new threat information appears, or when the review date passes. Confirm that every entry has a review date that is still in the future.

Ticket histories showing mitigation

Mitigation work should be tracked in a ticketing system with timestamps, assignees, status changes and closure notes, so the path from decision to fix is visible. GLPI's Assistance module can hold tickets, problems and changes under ITIL practices, which helps link a remediation ticket to the change that deployed it. Check that closed tickets record how the fix was verified rather than only that it was closed.

Source scan and assessment reports

Each finding should trace back to the report that produced it, such as a vulnerability scan, control assessment or audit log review, with the scan date and scope. Greenbone stores scan results in PostgreSQL and schedules scan tasks, which keeps the originating report retrievable for later review. Confirm that re-imported or repeated findings are deduplicated so that one underlying issue does not appear as several open risks.

Retaining evidence between assessments

Between formal assessments, export and archive the decision records, POA&M snapshots, accepted-risk reviews and report references on a schedule the organization sets in its policy. Assessors will ask for the state of the register at a specific past date, so point-in-time exports matter more than the live system alone. Confirm the retention period and storage location with the assessor before the assessment begins, because the required period is set by the organization's authorizing and oversight requirements, not by this page.

What meeting RA-7 costs in money and effort

This table breaks down the cost components of running RA-7 Risk response, who is paid for each one, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request and to see where self-hosted open-source tooling changes the license line but not the people time.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it
Tooling and licenses	Vendors of commercial findings platforms and scanners, or none for self-hosted open source	Usually recurring if commercial; open-source tools carry no license fee but still need hosting	Number of finding sources, seat counts and whether the platform is self-hosted
Implementation and integration	Implementation partner or internal platform engineers connecting scanners, ticketing and findings stores	One-time, with later changes when sources are added	Number of finding sources, report formats and ticketing workflows to connect
Risk owner decision time	Internal system owners, risk managers and the authorizing official who accept, mitigate, transfer or avoid each risk	Recurring, tied to each assessment, monitoring cycle and audit	Volume of findings needing a documented decision and the number of systems in scope
Plan of action and milestones upkeep	Internal GRC or security staff who keep each decision, owner and due date current	Recurring until closure of each item	Count of open items, slippage against milestones and how often status is reviewed
Evidence upkeep	Internal staff who export decisions, approvals and closure records for the assessment file	Recurring, usually per assessment cycle	Format of the records, whether decisions are captured in the tool at the time they are made
External review	Independent assessor or auditor who tests RA-7 against the SP 800-53A procedures	Recurring per assessment; the assessor reports, not the implementation partner	Scope of systems, number of decisions sampled and the readiness of the evidence on arrival
Assessor sampling effort	Internal staff who answer requests and retrieve records during testing	Recurring, concentrated in the assessment window	Quality of indexing across findings, decisions and approvals
Ongoing support	Implementation partner under a written retainer, if the organization buys one	Recurring when contracted	Upgrade frequency, tool changes and the team's internal capacity

Who owns RA-7, what partners prepare and what assessors decide

Your organization owns RA-7 in full. The control asks that findings from assessments, monitoring and audits be answered in line with your risk tolerance, and only your leadership can set that tolerance and decide which path to take for each finding. The decisions cannot be delegated to a vendor, because they carry business and legal consequences that belong to the system owner and the authorizing official or equivalent executive.

Risk tolerance: Approve the thresholds that separate findings you must fix from findings you may accept, transfer or avoid.
Response decisions: Choose to accept, mitigate, transfer or avoid each risk, and record the rationale and the approver.
Funding and deadlines: Commit the budget, staff time and remediation dates that the chosen responses require.
Exception ownership: Name who signs off on accepted risks, who reviews them and when they expire.
Governance records: Keep the plan of action and milestones current so each decision can be traced.

Before engaging anyone, confirm with your assessor and your governance documents which roles, approval levels and review cycles your framework or contract expects you to name.

Where RA-7 usually fails and how to close each gap

RA-7 is less about finding risks than about proving what happened next. Assessors look for a recorded decision for every finding, a review trail for every accepted risk, and a tolerance statement that the decisions can be traced back to. The gaps below are where that chain usually breaks.

Findings with no recorded decision

Scanners, assessments and audits produce findings faster than teams triage them, and many items sit in a queue with no decision attached. RA-7 expects each finding to lead to a response that fits the organization's risk tolerance. Close it by requiring every open finding to carry one of four decisions (accept, mitigate, transfer or avoid), an owner and a date. Check the tracker for items older than their triage window with a blank decision field.

Accepted risks never reviewed

Teams often accept a risk once and never revisit it, even after the system, threat or data changes. An accepted risk is still a live decision that needs an approver and a review date. Close it by setting a review date and a named approver on every acceptance, and by re-opening it when the system or its threat picture changes. Sample accepted items and confirm each has a review that happened after the acceptance.

POA&M items without milestones

A plan of action and milestones that lists a weakness but no dated steps does not show how the response will happen. Assessors read a blank milestone as no plan. Close it by giving each item at least one milestone with a completion date, an owner and a status that updates when the milestone is met. Confirm that closed items show the evidence that closed them, such as a patch record or a configuration change.

Decisions made outside the register

Risk decisions made in chat threads, meeting notes or email leave no single record for an assessor to test. When the register and the real decisions disagree, the register is wrong. Close it by routing every acceptance, mitigation and transfer through one ticket or register entry, and blocking closure of a finding until that entry exists. Ask for a sample of decisions and trace each one to the place it was recorded.

Risk tolerance that does not match decisions

RA-7 responses must fit the organization's risk tolerance, but many organizations state tolerance in a policy that no one uses to make decisions. Acceptances then drift from the stated limit without anyone noticing. Close it by writing tolerance as thresholds, such as the severity or impact an owner may accept without escalation, and checking each acceptance against those thresholds. Confirm that the policy, the register and the approval records use the same terms.

Transfers without a supporting agreement

Transferring a risk to a cloud provider, insurer or managed service only holds if the transfer is written down. Where the provider's responsibilities are unclear, the risk stays with the organization. Close it by recording each transfer with the contract clause or insurance term that moves the risk, and naming who reviews that term when it renews. Confirm the register entry points to the actual clause, not a general statement about shared responsibility.

How long, how much effort and what to ask before hiring help with RA-7

What drives the cost of implementing RA-7 risk response?

The cost depends mainly on how many findings your assessments, monitoring and audits produce, how many systems fall under the control, and how much of the response process already exists. RA-7 itself is a short control with no organization-defined parameters and no control enhancements in Release 5.2.0, so the effort sits in the surrounding work: deciding how each finding is accepted, mitigated, transferred or avoided, recording that decision, and tracking it to closure. Costs have two parts. Your staff own risk tolerance decisions and approvals. A partner, if you use one, is paid for preparing the tracking workflow, configuring tools and assembling evidence. Ask a partner to price the systems in scope, the number of finding sources feeding the process, and the reporting you need for your authorizing official or assessor. NIST does not estimate compliance costs, so treat any figure you see from a vendor as something to verify against your own scope.

How long does it take to put an RA-7 risk response process in place?

The duration depends on the scope, the maturity of your risk assessment and vulnerability processes, and how many approvals the decisions need. NIST does not set implementation timelines for SP 800-53; under FISMA those are set by OMB Circular A-130 for federal agencies, and FedRAMP sets its own requirements for cloud providers. For a commercial organization, the work usually runs in phases: agreeing the risk tolerance and decision authority, defining the response categories and record format, connecting the sources of findings, and running a first cycle end to end so the evidence is real. Agree a schedule in the written, fixed-scope plan before work starts, and confirm any deadline that comes from a contract or authorization with the party that set it.

How much effort does RA-7 need from our internal team?

Internal effort goes to decisions, not tooling. Your team needs to define the risk tolerance that RA-7 refers to, name the people who can accept risk, and set how often findings are reviewed. Security, system owners and the risk owner all contribute: system owners describe the affected components and proposed fixes, security staff check the finding and its severity, and the accepting official signs off on each decision. Plan for recurring time, because every new assessment, scan result or audit finding must be routed through the same decision process. A partner can reduce the overhead of routing and record keeping, but cannot make the risk decisions on your behalf.

Can we implement RA-7 ourselves without an outside partner?

Yes, many organizations do. RA-7 is an organizational control, so the decision logic belongs to you, and an internal team with a clear risk tolerance statement and a tracking system can meet its intent. Outside help is most useful when the findings come from several tools, when no single system holds all decisions, or when you need the records assembled for an assessment on a fixed date. Whichever route you choose, the organization owns the control, and only an independent assessor can test it and report on it. Check whether your current tooling already stores findings and decisions with an audit trail before you buy anything new.

What should we ask a partner to include in a fixed-scope quote?

Ask for a written scope that names the systems, finding sources and teams involved. A useful quote lists the following:

The systems and boundaries covered by the response process and which SP 800-53 baseline applies to them
The finding sources feeding the process, such as assessments, monitoring, audits and scanning
The tools to be configured, how they are hosted and who administers them
The response categories, decision record fields and approval steps to be built
The evidence package delivered, including the plan of action and milestones format
What the partner will not do, such as making risk acceptance decisions or issuing assessment results
Acceptance criteria, deliverable dates and the process for changes to scope

Confirm the baseline with your own assessor or authorizing official before the scope is final.

What will an assessor check for RA-7, and what will they not do?

An assessor reviews whether you respond to findings from assessments, monitoring and audits in line with your risk tolerance. Under SP 800-53A Release 5.2.0, RA-7 has four determination statements, and the assessor examines items such as assessment reports and audit records or event logs, and may interview staff about how decisions are made. The assessor will check whether decisions are recorded and whether they match the tolerance you set. An assessor does not design your response process, select your tools or decide which risks to accept. Those choices remain yours. Confirm the exact assessment approach with your assessor before they start, and for cloud providers, confirm how FedRAMP's Rev5 requirements apply to your system.

Does FedRAMP add requirements that change RA-7 effort?

Yes, if you are a cloud provider seeking or maintaining FedRAMP authorization. FedRAMP's Rev5 baselines require RA-7 at Classes B, C and D under the Consolidated Rules for 2026, and direct providers to its Vulnerability Detection and Response and Vulnerability Evaluation and Reporting rules. Those rules can set remediation expectations that affect how quickly decisions must be made and recorded. Because these requirements change over time, confirm the current rule text with FedRAMP and your authorizing body before you finalize the process and scope. Ask any partner how they track rule changes and whether those changes are included in the fixed scope.

How DeployOpen scopes and prepares RA-7 evidence

DeployOpen is a Chainscore Labs company that plans, implements, integrates and documents self-hosted open-source platforms inside the client's own infrastructure. For RA-7 Risk response, we prepare the systems, decision records and evidence that show findings are answered under the organization's risk tolerance, while the organization keeps ownership of its risk decisions and an independent assessor tests them.

How we scope

Agree in writing which assessment, monitoring and audit sources feed RA-7 decisions in your environment
Confirm the risk tolerance thresholds and who the decision owners are for accept, mitigate, transfer and avoid
Define which systems, baselines and privacy baseline components fall inside the RA-7 boundary
List the existing tools, such as ticketing or scanners, that will hold response records and the evidence each must produce

How we build

Configure a self-hosted findings register that deduplicates findings from assessments and scanners into one response queue
Set up ticket workflows that record each risk response decision, owner, due date and the rationale behind it
Connect plan of action and milestones entries to the tickets so each open item traces to a dated decision
Test the workflows with sample findings to confirm that decisions and status changes are logged and retrievable

How we hand over

Deliver configuration documentation covering the tools, data flows, roles and approval steps used for RA-7
Provide an evidence map that links each determination statement area to the records an assessor can examine
Document the procedure for updating the risk tolerance and reviewing accepted risks on the schedule you set
Train named staff to run the workflows so decision records continue after the engagement closes

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work is complete
Review tool versions and workflow changes when your risk tolerance or assessment cycle changes
Confirm with your independent assessor which evidence formats they accept before the assessment begins
Keep certification and audit decisions with your organization and the independent assessor, not with DeployOpen