ID.RA-06: Risk responses are chosen, prioritized, planned, tracked, and communicated

ID.RA-06 is the operational bridge between “we found risks” and “we reduced exposure.” Many programs can produce risk assessments, scan results, or third-party findings, but stall when it’s time to pick a response, fund it, assign an owner, and prove the work happened. This requirement expects discipline: consistent decision categories, prioritization rules, planned work with milestones, and ongoing status visibility.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to standardize a “risk response lifecycle” that works for multiple intake sources: enterprise risk assessments, vulnerability management, audits, incidents, and third-party due diligence. Your job is less about choosing technical fixes and more about enforcing governance: who decides, how fast, based on what criteria, and where evidence lives.

This page gives you requirement-level implementation guidance you can put into operation quickly: the minimum viable process, roles and handoffs, artifacts to retain, and exam-ready talking points. It also highlights common failure modes like informal risk acceptance, orphaned remediation items, and inconsistent stakeholder reporting. ¹

Regulatory text

Text (excerpt): “Risk responses are chosen, prioritized, planned, tracked, and communicated.” ¹

Operator meaning: you must run a managed process that (1) selects a response for each material risk, (2) prioritizes responses using defined criteria, (3) converts decisions into actionable plans, (4) tracks work to completion or formal acceptance, and (5) communicates status and decisions to stakeholders who can act or oversee. ¹

What an auditor is looking for: evidence that risk decisions are not ad hoc. They will try to trace a sample risk from identification → decision → plan → execution → closure/acceptance → reporting. If any link is missing, ID.RA-06 will be treated as “paper-only.” ¹

Plain-English interpretation (what “good” looks like)

ID.RA-06 means every significant risk has:

1. A named response (accept, avoid, mitigate, transfer, or a defined equivalent).
2. A priority that is defensible and consistent (based on impact, likelihood, regulatory exposure, and business criticality).
3. A plan with an owner, steps, dependencies, and target dates.
4. A tracking mechanism (tickets, GRC workflow, project plan) with status and proof of progress.
5. Communication that reaches decision-makers and affected operators (security leadership, IT owners, procurement, business owners, and executives as appropriate). ¹

Who it applies to

Entity scope: any organization operating a cybersecurity program and using NIST CSF 2.0 for governance and assurance. ¹

Operational scope (where this shows up):

• Enterprise and program risk assessments (annual, quarterly, or event-driven)
• Vulnerability and patch risk decisions (including compensating controls)
• Cloud security findings and architecture exceptions
• Third-party risk management and due diligence (e.g., “SOC 2 gap,” “no MFA,” “data residency risk”)
• Audit findings and management action plans
• Incident postmortems with corrective actions ¹

Teams involved: GRC/risk, Security, IT operations, Engineering, Procurement/Vendor Management, Legal/Privacy, and business owners for systems and data.

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

Step 1: Standardize risk response options and decision rights

Create a short “risk response taxonomy” and approval matrix:

• Mitigate (reduce likelihood/impact via controls)
• Transfer (insurance, contract terms, indemnity, outsourced control)
• Avoid (stop the activity, decommission, replace the third party)
• Accept (formal exception with rationale and expiration)

Define who can accept risk at each threshold (example: system owner for low, CISO/CCO for medium, executive risk committee for high). Document it in policy and a procedure the teams actually follow. ¹

Step 2: Define prioritization criteria that work across domains

Pick a consistent method and write it down. Keep it simple enough to use:

• Impact to confidentiality/integrity/availability
• Business criticality of the asset/service
• Regulatory/compliance exposure (e.g., customer data, financial reporting)
• Likelihood or exploitability signals (where available)
• Control gap severity and compensating controls
• Third-party concentration and substitutability (for supplier risks)

Output: each risk gets a priority (e.g., Critical/High/Medium/Low) plus a short justification. Consistency matters more than precision. ¹

Step 3: Convert each chosen response into a treatment plan

For every risk above your tracking threshold, create a “risk treatment plan” record that includes:

• Risk statement (cause → event → impact)
• Chosen response and rationale
• Owner (single accountable person)
• Actions/tasks (mapped to controls where possible)
• Dependencies (budget, vendor, engineering cycle)
• Target dates and milestones (or “next decision date” for acceptance)
• Required approvals (security, privacy, procurement, leadership)

This is where many programs fail: they log the risk but never create executable work. ¹

Step 4: Track execution in a system of record

Choose one system of record and enforce it:

• GRC tool workflow, or
• Ticketing system (Jira/ServiceNow), with a GRC “wrapper” record, or
• A controlled register with change history if tooling is limited

Minimum tracking fields:

• Status (Open / In progress / Blocked / Accepted / Closed)
• Last update date and updater
• Evidence link(s): change tickets, configs, test results, vendor commitments
• Closure criteria (what proves the risk is reduced or accepted)

Make “no record, no work” the rule for remediations tied to material risks. ¹

Step 5: Communicate decisions and status on a cadence

Communication must match stakeholder needs:

• Operational owners: what to do, by when, what “done” means
• Executives/committees: top risks, overdue items, accepted exceptions, systemic themes
• Third-party stakeholders: contractual remediation commitments, timelines, and residual risk decisions

Create a standard reporting pack:

• Top risks and changes since last report
• Overdue treatment plans and blockers
• New risk acceptances and expirations
• Third-party risk items that affect go-live/renewal decisions ¹

Step 6: Close the loop (validation and residual risk)

Don’t close a risk because a ticket says “done.” Define verification:

• Control implemented and tested (e.g., config evidence, scan results, access review output)
• Residual risk re-scored
• Risk record updated with outcome and evidence
• Lessons learned fed back into standards (secure baseline, vendor contract templates) ¹

Required evidence and artifacts to retain (audit-ready)

Keep artifacts that let an examiner trace end-to-end execution:

Artifact	What it proves	Where it usually lives
Risk register entries with response selection	“Chosen” and “prioritized” decisions exist	GRC tool / controlled register
Risk treatment plan / remediation plan	Planning, ownership, and due dates	GRC record, project plan
Risk acceptance memos / exception records	Formal acceptance with rationale, approver, expiry	GRC exception workflow
Tickets/changes linked to risks	Work was executed and controlled	Jira/ServiceNow/Change mgmt
Evidence of validation	Risk reduction is real	Scan outputs, config snapshots, test results
Governance reporting (slides, minutes)	Communication to oversight bodies	Committee materials repository
Third-party remediation correspondence	Supplier commitments and tracking	VRM tool / procurement records

Also retain the mapping from ID.RA-06 to your policy, procedure, control owner, and recurring evidence collection, because that reduces scramble during audits and internal control testing. ²

Common exam/audit questions and hangups

• “Show me three high risks and walk me from identification to closure.” Expect sampling.
• “Who can accept risk, and how do you prevent unauthorized acceptance?”
• “How do you prioritize across vulnerability findings, third-party risks, and audit issues?”
• “What happens when remediation is blocked by budget or vendor constraints?”
• “How do you ensure risk acceptances expire and get re-approved?”
• “Where is the evidence that stakeholders were informed (not just that a ticket exists)?” ¹

Frequent implementation mistakes (and how to avoid them)

1. Email-based risk acceptance. Fix: require a centralized exception record with approver, rationale, and expiry.
2. No linkage between risk and work. Fix: require every treatment plan to link to implementation tickets and evidence.
3. Priority inflation (everything is ‘High’). Fix: calibrate with a prioritization rubric and a review gate.
4. Closure without validation. Fix: define closure criteria per risk type; require verification evidence.
5. Third-party risks treated as “procurement’s problem.” Fix: route supplier control gaps into the same response-tracking workflow as internal gaps, with clear accountable owners. ¹

Enforcement context and risk implications

NIST CSF is a framework, not a regulator. Your exposure usually comes from sector regulators, contractual obligations, and incident aftermath where you must prove governance and due care. ID.RA-06 is often tested indirectly: after a breach, regulators and customers ask whether known risks were tracked, prioritized, and acted on, and whether leadership understood residual risk. The practical risk is defensibility. Weak evidence turns “we manage risk” into an unsubstantiated claim. ¹

A practical 30/60/90-day execution plan

First 30 days (stand up the minimum viable workflow)

• Name the process owner (GRC) and define decision-makers for acceptance/escalation.
• Publish a one-page procedure: response options, required fields, and approval rules.
• Pick the system of record and create templates for risk treatment plans and acceptances.
• Start weekly triage for new/high risks and open remediation items. ¹

Days 31–60 (make it real across intake sources)

• Integrate at least three feeders: risk assessments, vulnerability findings, and third-party due diligence.
• Create a single prioritized backlog and enforce owner assignment for each item.
• Produce the first consistent stakeholder report (ops + leadership view).
• Run a closure quality check: sample completed items and verify evidence standards. ¹

Days 61–90 (scale and harden for audits)

• Add exception expiration monitoring and re-approval workflow.
• Define metrics that drive behavior (overdue items, blocked items, aging by priority).
• Run a tabletop audit: pick samples and prove traceability end-to-end.
• If tooling is fragmented, consider Daydream to map ID.RA-06 to policy, procedure, control owners, and recurring evidence collection, then automate reminders and evidence capture so treatment plans do not decay between audits. ²

Frequently Asked Questions

Do we need a formal “risk treatment plan” for every single finding?

No. Set a threshold. Track material risks and any item requiring cross-team remediation, funding, or executive visibility. Keep smaller items in operational backlogs but link them to the originating risk theme when they roll up.

What counts as “communicated” for ID.RA-06?

Communication means the right stakeholders received the decision and status in a form they can act on or oversee. Meeting minutes, risk committee decks, and workflow notifications with approver identity are typical evidence. ¹

How do we handle risk acceptance for third-party gaps?

Use the same acceptance workflow as internal risks, but include supplier-specific terms: renewal date, contract remediation commitments, exit options, and compensating controls you control (segmentation, monitoring, data minimization).

Our remediation is blocked by engineering capacity. Are we automatically noncompliant?

Blockers happen. Record them, escalate based on your prioritization rules, and document interim compensating controls or an approved acceptance with an expiration date. Auditors focus on governance and traceability, not perfection. ¹

Can a ticketing system alone satisfy “tracked”?

Sometimes, if tickets capture risk context, prioritization, approvals, and evidence links. Most teams still need a risk register or GRC record that provides the decision trail and oversight reporting. ¹

What’s the minimum evidence set to survive an audit sample?

A risk record with response choice and priority, an assigned owner with a plan, linked implementation evidence, and proof of approval/communication. If any of those are missing, expect a finding against process design or operating effectiveness. ¹

Footnotes

1. NIST CSWP 29

2. NIST CSF 1.1 to 2.0 Core Transition Changes