ID.RA-06 says risk responses are chosen, prioritized, planned, tracked, and communicated. That is five verbs, and a risk register entry that only says "mitigate" covers one of them. To meet the outcome, each significant risk needs a decision (accept, transfer, mitigate, or avoid), a plan with an owner and a date, a place where progress is tracked, and a way stakeholders hear about it.
What good looks like
Every risk above your agreed threshold has a recorded response. Nobody has to ask "what happened with that issue we discussed in March?" because the answer is in the register or ticket. Stakeholders who are affected, such as a product owner or the head of customer support, hear about planned responses in priority order instead of discovering them at release time.
NIST's examples lean on your vulnerability management plan. Apply its criteria for deciding whether to accept, transfer, mitigate, or avoid risk. Apply its criteria for selecting compensating controls. Track progress with a plan of action and milestones, a risk register, or a risk detail report. Use assessment findings to inform decisions. Communicate planned responses to affected stakeholders in priority order.
How to implement it
- Write the decision rules down. One page is enough. For example: Critical risks must be mitigated or avoided within 30 days, High within 90 days, and acceptance of anything High or above needs sign off from an executive.
- Define each response in plain words. Mitigate means reduce the likelihood or impact with a control. Transfer means shift the financial or operational burden, such as through insurance or a contract. Avoid means stop the activity. Accept means live with it on purpose, with a named approver and a review date.
- For each risk, record the choice and the reasoning in the register. Link it to a ticket in the tool where engineers already work, so the work is visible.
- Define compensating controls clearly. If a patch cannot ship this month, what reduces exposure meanwhile? A network restriction, a feature flag, extra monitoring. Record it and set an end date.
- Track status weekly for the top items and monthly for the rest. Overdue items get escalated to the risk owner.
- Communicate in a regular short note. List the top five risks, the chosen response, owner, and date. Send it to engineering, product, and leadership.
- For software vulnerabilities, rank by exploitability and reachability, not raw counts. A vulnerable function that your code never calls is a different decision from one on a live request path.
A worked example
A scan shows a High severity vulnerability in a library used by an internal admin tool. The register entry could look like this.
Decision: mitigate. Reasoning: the tool is reachable only from the office network, but it holds admin sessions, so avoiding is too costly and accepting is not justified.
Plan: upgrade the library in the next sprint, owner is the tools team lead, due in 21 days. Compensating control until then: restrict the tool to two named admin accounts and add an alert on logins from new devices. The compensating control ends when the upgrade ships.
Tracking: ticket linked to the register entry, status reviewed in the weekly engineering sync.
Communication: the product owner and the support lead are told on the Friday risk note that admin tool changes are coming and might cause a short maintenance window.
Compare that with a weak entry such as "Vulnerable library, mitigate." The first one can be audited, and the second cannot. If the fix slips, the first entry also shows exactly when the compensating control should be revisited.
Review what happened afterward too. Did the response reduce the risk as expected? A short note in the entry closes the loop and helps you improve the criteria next time.
Evidence to collect
- The written response criteria and who approved them
- Register entries showing a decision, owner, due date, and status
- Tickets linked to those entries, with closure dates
- Signed risk acceptances with review dates
- Examples of stakeholder updates and their distribution list
- Records of compensating controls and their expiry
Common gaps
- Acceptance is used as a way to close items without anyone senior agreeing
- Compensating controls have no end date and become permanent by neglect
- Responses are chosen but not tracked, so status is unknown
- Communication stops at the security team
- Plans exist for scanner findings but not for business risks such as supplier concentration
Quick check
Is accepting a risk a valid response?
Yes, when it is a decision made by someone with authority, recorded with the reason, and revisited on a date. Silent acceptance, where an item just sits open, is the gap.
How many risks need full response plans?
Set a threshold in your criteria, for instance everything rated High or above plus any item with an overdue date. Lower items can use a lighter process such as a batch review each quarter.
Sources
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 (February 2024), Appendix A, CSF Core: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- NIST CSF 2.0 landing page: https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final
The CSF is voluntary guidance. There is no CSF certification, so nothing here makes a company "CSF certified". You describe your own practices against the outcomes.
