ID.RA-06 risk responses: requirements and evidence

What ID.RA-06 asks for and why teams struggle with it

An assessor or customer asking how identified risks are handled usually wants to know one thing: where the decision is recorded. ID.RA-06 is the NIST CSF 2.0 Subcategory that addresses this. In plain terms, it expects an organization to select a risk response for each significant risk, prioritize those responses, plan them, track them to completion and communicate them to the people who need to know. The outcome is about decisions and their follow-through, not about the scanner or tool that first surfaced the problem. Teams often struggle because the answer is scattered. Vulnerability results sit in scanner output, remediation work sits in tickets, and the reasoning sits in meeting notes or an email thread about a risk someone chose to accept last quarter. No single record shows what was decided, who owns it, what the due date is and whether the decision still holds.

The Subcategory has a long history in the framework. ID.RA-06 keeps the identifier ID.RA-6 from CSF 1.1, and NIST's transition spreadsheet shows that it absorbs part or all of CSF 1.1 RS.MI-3, which covered mitigating newly identified vulnerabilities or documenting them as accepted risks. Teams that used the older Subcategory should check their existing mitigation records against the new wording, because accepted risks now sit squarely inside the response decision rather than in a separate mitigation step. A useful first check is to pick three open high-impact findings and confirm that each has a recorded response option, an accountable owner, a target date and an entry in a plan of action and milestones or risk register. Any finding missing one of these is the gap an assessor is likely to find.

Before engaging anyone to help, confirm what the organization is actually being asked to show. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. A CSF assessment is therefore a self-assessment, an independent review or a customer questionnaire, and each will define its own evidence expectations. An independent assessor can test whether the response records exist and are current, but only the organization owns the decisions. Implementation partners can prepare the registers, workflows and evidence, but they do not certify the result. Ask the assessor or customer which records they will sample and in what format before building anything.

Which risks, systems and teams fall under ID.RA-06

ID.RA-06 only works on the risks that reach the register, so the scope decisions you make upstream determine how much response planning and tracking you carry. The cards below cover the risk sources, owners and third-party risks that most change the workload.

Vulnerabilities from ID.RA-01

Every validated vulnerability that enters the register needs a response decision: accept, transfer, mitigate or avoid. Scanning all assets on a broad schedule can multiply the number of items needing a decision well beyond what a team can plan. Check which asset classes feed the register, how often scans run, and whether low-severity findings get a documented disposition or are filtered out before they reach a POA&M. Ask who approves a finding that stays open past its planned fix.

Threats from ID.RA-03

Threats that are identified but never linked to a vulnerability or asset do not usually need a response plan, yet they still affect prioritization. Decide whether the register holds only threats that map to an identified weakness or every recorded threat. The first option keeps the register small, while the second adds review work each time threat intelligence changes. Confirm how threat entries are retired when the actor or technique stops being relevant.

Inherent risk from ID.RA-05

Inherent risk scores, which combine threats, vulnerabilities, likelihood and impact, set the order in which responses are planned. Without them, teams work from scanner severity alone, which often ignores business impact. Check that the scoring method is documented, that thresholds for mandatory response plans are agreed with risk owners, and that threat modeling outputs are included when systems change. Scoring criteria should be reviewed on a stated cycle.

Changes and exceptions from ID.RA-07

Accepted risks, approved exceptions and changes with residual risk all land in the response record. Each one carries a review date, a rollback plan and an owner, which means expired exceptions can quietly become open findings. Decide which change types create a register entry, who approves exceptions, and how long an accepted risk stays valid before revalidation. Confirm that the change system and the risk register share identifiers so the two can be reconciled during an assessment.

Business units that own risk

A response is only planned well when a named owner accepts the risk or funds the fix, and that owner is often in a business unit rather than IT. Map each system and data set to an accountable executive before the first register review, and record who can accept a risk at each rating level. Unowned systems tend to show up as stalled POA&M items. Ask whether shared platforms have one owner or several, because split ownership multiplies the sign-offs needed.

Critical suppliers from ID.RA-10

Risks inherited from critical suppliers can be planned for only if you carry them into your own register with a response. Choose whether the register holds supplier risks you can influence through contract terms, or also risks that sit entirely in a supplier's environment. The first scope is narrower and easier to track, while the second requires supplier evidence on a recurring basis. Confirm which supplier findings you receive, how often, and who records a transfer decision when a supplier takes on a risk.

How to choose between accept, transfer, mitigate and avoid

Choose the response before you choose the control. For each risk, the organization decides whether to accept it, transfer it (for example, through insurance or a contract with a supplier), mitigate it by reducing likelihood or impact, or avoid it by stopping the activity or removing the exposure. Acceptance fits risks that already sit inside appetite and where the cost of any other response exceeds the loss. Transfer shifts financial consequences but not accountability for regulators or customers, so the record should say what remains with the organization. Avoidance fits a service or data flow that cannot be secured to an acceptable level. Mitigation is the default for most vulnerabilities, but when a patch or redesign is delayed, a documented compensating control such as network isolation, added monitoring or tighter access can reduce exposure while the fix is scheduled.

The thresholds come from the vulnerability management plan criteria and from the risk appetite and tolerance set under GV.RM. Those criteria should state which severities or asset classes must be mitigated within a defined window, which may be accepted, and who may approve each. Informative references for ID.RA-06 point to SP 800-53 Rev. 5.2.0 controls PM-9 (risk management strategy), PM-18 (program plan), PM-30 (supply chain risk management strategy) and RA-7 (risk response), which give useful vocabulary for these decisions. They are references for the outcome, not a one-to-one mapping, so confirm with your own assessor how each one applies to your program.

Every decision needs a named owner, a written rationale and a review date. The owner is the person with authority over the asset or business process who accepts the residual risk, not the security team alone. The rationale should record the threat, the vulnerability, the compensating controls and the expected residual exposure. The review date forces revisiting accepted risks and delayed mitigations, so an exception does not become permanent. Track each response in a POA&M or risk register with its status, milestones and closure evidence. Ask whether your register captures transfers and avoidances as clearly as mitigations, because auditors often find those decisions undocumented.

How an assessor tests ID.RA-06 and what they ask for

This table shows how an assessor typically samples and tests risk response decisions under ID.RA-06, what evidence they request for each step, and where programs most often fall short. Read it as a pre-assessment checklist: each row is a question the assessor will ask, and the evidence column is what should be ready before they arrive.

Test area	Test approach and evidence requested	Common findings
Sample of risks selected	Assessor selects a set of risks from the register or POA&M, often across severity levels and sources, and asks for the full record of each. Confirm with the assessor how the sample will be drawn and whether it includes closed risks.	Register holds only high-severity items, so low-rated risks with no documented response go untested and unexplained.
Rationale for each chosen response	Assessor reads the recorded decision to accept, transfer, mitigate or avoid and checks that it references the criteria in the vulnerability management plan. Evidence includes the decision memo, approver and date.	Responses recorded as a single word with no criteria, or accepted risks approved by someone without authority to accept them.
Traceability from risk to plan to status	Assessor follows one risk from its entry through the planned action, owner, due date and status updates, and checks that each link points to the same item. Evidence includes linked tickets, POA&M milestones and change records.	Risk register and POA&M use different identifiers, so status updates cannot be matched to the original risk.
Evidence of communication to owners	Assessor looks for proof that planned responses reached the people who own the asset or process, such as acknowledgments, meeting minutes or assigned tickets. Confirm which forums the organization treats as formal communication.	Responses recorded as communicated, but no owner acknowledged them or the owner named in the register has since left.
Evidence of periodic review and closure	Assessor checks that open responses are reviewed on a defined cycle and that closed items show verification, not only a status change. Evidence includes review minutes, re-scan results or retest records.	Items marked complete without retesting, or review meetings that happen irregularly with no recorded outcomes.
Exceptions without expiry	Assessor looks for accepted risks and exceptions that carry a review date, owner and conditions for revisiting them. Open-ended acceptances without an expiry date are a frequent focus.	Accepted risks recorded years earlier with no review date, so the acceptance no longer reflects the current environment.

How to implement risk response tracking step by step

This sequence turns ID.RA-06 from a policy statement into a working cycle in which every open risk has a documented response, an accountable owner, and a record an assessor can follow from decision to closure. Each step names the artifact that proves it was done.

Define response criteria and approval authority
Start by writing down how the organization chooses between accepting, transferring, mitigating and avoiding a risk, and which roles may approve each choice. Include the thresholds that trigger escalation to leadership and how compensating controls are justified. Leadership or the risk committee should approve the document, and the approval record should name who holds authority at each level. The step is complete when a written response criteria standard exists, has an approval date and an owner, and is linked from the risk management policy.
Set the register or POA&M fields
Decide where response tracking lives, whether a risk register, a plan of action and milestones, or both, and define the mandatory fields for each entry. Typical fields include risk identifier, description, source finding, inherent rating, selected response, rationale, owner, planned actions, status, and closure evidence. Confirm that the tool your team uses can hold these fields and keep an audit trail of changes. The output is a field specification and a sample record that a reviewer can read without asking the author for context.
Classify and prioritize open risks
Pull the open risks from vulnerability scanning, threat intelligence, threat identification and risk analysis records, then sort them by the inherent rating and business impact recorded in earlier risk assessment outputs. Remove duplicates so one underlying weakness does not appear as several unrelated items. The deliverable is a prioritized list with a stated ordering method, reviewed by the risk owner who will accept responsibility for the ranking.
Select responses with documented rationale
For each prioritized risk, choose one response and record why. Accepting a risk should name who accepted it and under what limit. Transferring should identify the contract, insurance or outsourced party involved. Mitigating should list the controls to be applied, and avoiding should describe the change to the activity that removes the exposure. Where a compensating control is used, record the gap it covers. The artifact is a decision record per risk that an assessor can trace back to the criteria from step one.
Assign owners and planned actions
Name one accountable owner for every response and break mitigations into planned actions with a responsible person for each. Owners should be people who can allocate budget or change systems, not only reporters of status. Record the target dates the organization has agreed, and confirm each owner has accepted the assignment. Completion is visible when every open entry has an owner, at least one planned action, and a target date, with no blank fields.
Run a recurring review and communicate status
Hold a review on a cadence the organization sets in its policy, walking through overdue items, new risks and responses that have changed. Send a summary of planned responses and progress to the stakeholders named in the communication plan, including leadership for high-impact items. Keep the meeting notes, the status report and any decisions to change a response, since these show the response was actively managed. The output is a dated review record and a distribution list.
Close or re-assess each response
When planned actions finish, collect evidence such as a configuration change record, a test result or a signed transfer agreement, and close the entry only after someone other than the owner has verified it. Accepted risks should return to the register on a schedule that the organization sets, so they are re-evaluated when conditions change. Closed entries should stay in the record with their evidence rather than being deleted. The step is complete when each closed item links to verification evidence and each accepted item has a scheduled re-review.

Evidence that shows ID.RA-06 is working between audits

ID.RA-06 is only credible if the decisions behind each risk response can be traced from identification to closure. The cards below describe the records an assessor will ask to see between formal reviews, and what each one should show before it is accepted as evidence.

Risk register or POA&M export

A dated export of the risk register or plan of action and milestones (POA&M) lists each risk, its chosen response, the named owner, the target date and the current status. The NIST Implementation Examples for ID.RA-06 name the POA&M or risk register as the place where progress is tracked, so this export is the central artifact. Check that every open item has an owner and a date, and that overdue items show a revised date with a recorded reason rather than a silent change.

Response decision records

For each risk, a decision record states whether the organization chose to accept, transfer, mitigate or avoid it, and why. The record should name the approver and cite the criteria from the vulnerability management plan that were applied. An assessor will test whether the rationale matches the risk appetite set under GV.RM and whether the approver held the authority to accept that level of risk.

Compensating control records

When a mitigation cannot be applied on time, a compensating control record shows which substitute control reduces the exposure, how it was configured and who verified it. The Implementation Examples for ID.RA-06 specifically include choosing compensating controls, so this record is expected wherever a vulnerability stays open. Confirm that each record names an expiry or review date and links back to the original risk entry.

Review meeting minutes

Minutes from risk review meetings show that planned responses were prioritized and progress was examined by people with authority. Each set of minutes should list the risks reviewed, the status changes agreed, the decisions taken on overdue items and the attendees. Minutes that record only attendance, without decisions tied to specific register entries, will not demonstrate that tracking happened.

Stakeholder communication records

ID.RA-06 includes communicating planned responses, so keep records of what was sent to system owners, business leaders and, where contracts require it, customers. Store the message, the recipients, the date and the response requested. Check that communications on accepted risks went to the people who carry the consequence, since an acceptance that nobody was told about is weak evidence.

Closure evidence tied to retest

A risk should close only when evidence shows the response worked. Closure records should reference the retest or scan result that confirmed the fix, the ticket or change record that applied it and the person who validated closure. Tools such as DefectDojo can keep finding history with deduplication, which helps show that a reopened finding was linked to its earlier record rather than treated as new. Check that no item was closed on the basis of a status change alone.

Keeping evidence current

Between audits, schedule exports of the register or POA&M at a fixed interval and store them with version history so that changes to owners, dates and statuses can be reconstructed. Keep the export location, retention period and access rights documented in the risk management procedure. Ask the implementation partner to confirm how the tooling records changes, since the answer determines whether an assessor can see who changed a date and when.

What meeting ID.RA-06 costs in money and effort

This table compares the main cost components of planning and tracking risk responses for ID.RA-06, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to structure a written scope and quote request, since no supplied price or duration applies to a specific organization.

Cost component	One-time or recurring	Cost drivers	How to reduce it
Tooling and licenses	Recurring (subscription) or one-time (perpetual)	Number of risk register users, integrations with scanners, hosting and backup scope	Self-hosted open-source platforms such as CISO Assistant (AGPL-3.0-only) or DefectDojo (BSD-3-Clause) remove license spend, though hosting and upkeep remain
Engineering time to configure the register	One-time, with later changes	Number of risk categories, mapping to existing POA&M fields, import pipelines from scanners	Start from a minimal register template and expand only where an assessor or contract requires it
Staff time for risk decisions and reviews	Recurring	Number of risks needing accept, transfer, mitigate or avoid decisions, and the approval chain	Set risk acceptance thresholds in the risk management strategy so routine decisions need less review time
Evidence upkeep	Recurring	Frequency of status updates, number of owners, linkage between POA&M items and tickets	Automate status pulls from ticketing and scanner tools so records stay current without manual edits
External review or testing	Recurring or per engagement	Scope of testing, depth of review of risk decisions, number of systems in scope	Agree scope in writing and test the response process on a defined sample before a formal review
Auditor or assessor sampling effort	Recurring, per assessment cycle	Number of risk responses sampled, completeness of rationale and approval records	Keep a dated decision record for every accepted risk with owner, rationale and review date

Which open-source tools can support risk response evidence

ID.RA-06 is satisfied by a record of decisions and their follow-through, so the tooling has to hold risk responses, link them to findings and show their status over time. The three tools below cover different parts of that record: the governance register, the findings workflow and the scanning source.

CISO Assistant for the response register

CISO Assistant (AGPL-3.0-only) is a self-hosted GRC application that ships more than 200 frameworks, including NIST CSF, and runs audits and compliance assessments against them with automatic mapping between frameworks. It can hold the risk responses your organization chose (accept, transfer, mitigate or avoid), with owners and target dates, so the plan of action and milestones or risk register has one authoritative home. Confirm that the framework mappings match the version of NIST CSF your assessor uses, and that your use of an AGPL-3.0-only product fits your distribution and hosting obligations with counsel.

DefectDojo for finding lifecycle

DefectDojo (BSD-3-Clause) imports and reimports findings from more than 500 security tool report formats through its UI or API, including the open source edition, and deduplicates them using per-tool hashcode fields. That means a vulnerability raised by several scanners becomes one tracked item, and a response such as a compensating control stays attached to it when the next scan repeats the finding. Confirm which report formats your scanners produce and test that reimports keep the response status intact before you rely on it as evidence.

Greenbone Community Edition as scan source

Greenbone Community Edition (OpenVAS, AGPL-3.0-or-later) runs through gvmd, which stores results in PostgreSQL, manages users and permissions and schedules scan tasks, with results reviewed in the Greenbone Security Assistant web interface. It supplies the dated scan records that show whether a mitigated or accepted risk is still present, which is the evidence an assessor asks for when checking that responses are tracked to closure. Confirm the scan schedules, retention of PostgreSQL data and how exported results reach your register, and review AGPL-3.0-or-later obligations if you modify the software.

Who owns, implements and audits risk responses

Your organization owns every risk response under ID.RA-06. Risk owners, typically the managers of the business service or system carrying the risk, choose whether to accept, transfer, mitigate or avoid it. The risk committee or the equivalent governance body approves responses above agreed thresholds, and the security function maintains the criteria, challenges weak justifications and keeps the register current. No outside party can make these decisions for you, and an implementation partner should never be recorded as the approver of a risk.

Decision rights: Name the owner and approver for each risk and write down the thresholds that trigger committee review.
Response criteria: Document the vulnerability management plan criteria that determine when a finding must be mitigated, transferred or accepted with compensating controls.
Plan and tracking records: Keep the POA&M or risk register as the system of record, with target dates, owners, status and the rationale for every decision.
Communication: Decide who receives planned responses, including leadership, affected application owners and, where contracts require it, customers.
Acceptance review: Set a schedule for revisiting accepted risks when systems, threats or contracts change.

Before relying on the register as evidence, confirm that every open item has a named owner and a recorded decision.

Common questions about ID.RA-06 cost, effort and readiness

How much effort does ID.RA-06 usually take, and what drives it?

No researched figure is available for the effort ID.RA-06 takes, so treat any number you see elsewhere with caution and ask for your own estimate. The work scales with the number of risk responses already open, how many systems and suppliers those risks touch, and whether a plan of action and milestones (POA&M) or risk register already exists. An organization with a consolidated register and clear risk criteria will spend far less time than one reconstructing decisions from email threads. Ask any provider to break effort down by activity: reviewing existing risks, drafting response criteria, recording decisions, setting up tracking and running the first review cycle.

Can a small team meet ID.RA-06 without outside help?

Yes, a small team can meet the outcome of ID.RA-06 without an outside partner, because NIST's CSF 2.0 is voluntary and does not prescribe tools or staffing. The team needs one accountable owner, written criteria for choosing accept, transfer, mitigate or avoid, and a single place where each decision and its progress is recorded. Outside help is most useful when the team lacks time to configure a tracking tool, when the scope spans many systems, or when a customer or regulator asks for evidence the team has never produced. Confirm with any reviewing party which evidence format they expect before you decide.

What does ID.RA-06 need from risk owners and leadership?

ID.RA-06 needs named risk owners who can accept a residual risk, fund or assign a mitigation, and agree when a risk will be reviewed again. Leadership needs to approve the criteria that decide which response applies, including who may accept a risk and at what severity. Without that authority, responses stay as recommendations and the POA&M or register shows open items with no decision behind them. Ask leadership to set the approval path in writing, because an assessor will look for evidence that the person who accepted a risk had the authority to do so.

How long does readiness take, and what sets the pace?

No researched duration exists for ID.RA-06 readiness, so confirm the timeline against your own environment rather than a generic estimate. The pace is usually set by the upstream inputs: how quickly vulnerabilities, threats and impacts are recorded under ID.RA-01 through ID.RA-05, how many decisions need leadership sign-off, and how many systems must be re-tracked. Teams that already run a vulnerability scanner and a findings database can often move faster than teams starting from spreadsheets. Agree on a milestone plan in writing before work starts so the timeline is visible to everyone.

Does NIST certify organizations against CSF 2.0?

No, NIST does not certify anyone against CSF 2.0. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. Any claim of a NIST CSF certificate should be treated as a red flag. Organizations can show alignment through their own assessment, and some customers or sector bodies may ask for independent review, which is provided by an assessor you engage, not by NIST. Ask any provider to explain exactly what their review produces and who issues it.

What should I ask an implementation partner for in a quote?

Ask for a written scope that names the systems, risk register sources and suppliers covered, along with the deliverables and the dates each one is due. The quote should separate one-time work, such as defining response criteria and configuring tracking, from recurring work, such as review cycles and support. Ask who performs each task, what the organization must supply, and what evidence the partner will hand over. A reputable partner prepares systems and evidence but does not issue audit reports or certificates, so confirm that the independent assessor is named as a separate cost. DeployOpen works from a fixed written scope and does not publish a price list, so expect a quote based on that scope.

Is a POA&M alone enough to satisfy ID.RA-06?

A POA&M alone is not enough. The subcategory expects risk responses to be selected, prioritized, planned, tracked and communicated, and a POA&M records only some of that. It shows planned actions and milestones, but the selection rationale, the acceptance decisions, the approving owner and the communication to stakeholders must also be documented. For example, an illustrative record might list a mitigation with a due date but no note of who accepted the residual risk for a delayed item. NIST's Implementation Examples name the POA&M or a risk register as the tracking vehicle, so combine the two: keep the POA&M for actions and the register for decisions.

How DeployOpen scopes and prepares ID.RA-06 evidence

DeployOpen helps teams set up the systems and records that show how risk responses are chosen, planned and tracked for ID.RA-06. The organization keeps ownership of its risk decisions, and DeployOpen prepares the working records and evidence inside the client's own infrastructure, so an independent assessor can review them.

How we scope

Engagements are fixed-scope, with the systems, risk register and POA&M tooling agreed in writing before work starts.
The written scope names which risk response options (accept, transfer, mitigate, avoid) are recorded and who approves each one.
We confirm which vulnerability sources and tickets feed the risk register and which decisions remain manual.

How we build

We deploy self-hosted open-source platform components in your cloud accounts, data centers or air-gapped networks.
We configure risk registers and POA&M workflows with fields for owner, response type, due date, status and compensating controls.
We connect scanner findings and deduplicated issues to the register so each mitigation has a traceable, tracked record.

How we hand over

Deliverables include configuration documentation, role and permission settings, and a sample of completed response records.
We provide a runbook describing how risk responses are reviewed, escalated, communicated and closed.
Your staff receive walkthroughs so the organization can operate and evidence the process after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement.
Retainers can cover periodic review of overdue POA&M items and updates to response criteria as systems change.
DeployOpen prepares evidence for an independent auditor or assessor, but does not issue reports, attestations or certifications.