Risk Response

The risk response requirement means every identified cybersecurity risk must receive a documented treatment decision: mitigate it, accept it, avoid it, or transfer it, and you must be able to prove the decision was made, approved, and tracked to completion. Operationalize this by running a consistent risk treatment workflow with clear decision criteria, approvals, and evidence. ¹

Key takeaways:

• Every risk needs an explicit treatment outcome (mitigate/accept/avoid/transfer) tied to an owner, due date, and approval trail. ¹
• Audits fail this control more often on missing evidence (decision logs, approvals, exceptions, closure proof) than on tooling gaps.
• Treat third-party and OT risks the same way: a decision, rationale, and tracked follow-through inside your risk register.

“Risk Response” is where risk management stops being analysis and becomes accountable action. C2M2’s requirement is short, but the operational expectation is not: you need a repeatable way to take an identified cybersecurity risk and drive it to a documented outcome that the business accepts. The four outcomes (mitigate, accept, avoid, transfer) sound straightforward until you face real constraints: production uptime, operational technology (OT) safety constraints, contract limitations with third parties, and competing remediation work.

For a CCO, compliance officer, or GRC lead, the fastest path is to treat risk response like a production workflow. Each risk record should move through defined states (identified → analyzed → treatment selected → approved → implemented → validated/closed). You should be able to answer, on demand: What did we decide, who approved it, why, what changed, and how do we know it’s done?

This page translates the requirement into a working playbook: decision criteria, step-by-step operations, minimum evidence, common audit traps, and an execution plan you can run without rewriting your whole security program. ¹

Regulatory text

Requirement (C2M2 RISK-1.C, MIL1): “Identified cybersecurity risks are mitigated, accepted, avoided, or transferred.” ¹

What the operator must do:
For every cybersecurity risk your organization identifies within the C2M2 assessment scope, you must (1) select one of the four risk treatment options, (2) document the rationale and decision authority, and (3) follow through so the chosen response is actually implemented, tracked, and reviewable. The requirement is satisfied by consistent, provable decisions, not by informal conversations or scattered tickets. ¹

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

A compliant program shows that risks do not linger in limbo. Each risk gets:

• A treatment decision (mitigate/accept/avoid/transfer)
• A named owner accountable for execution
• A timeline or trigger for completion or reevaluation
• Approvals aligned to your governance (security leadership, business owner, or a risk committee for higher-impact items)
• Evidence of completion (or, for acceptance/transfer, evidence the organization knowingly took on the residual risk)

In practice, this becomes your “risk treatment workflow” and “risk response playbook,” with escalation paths and decision criteria so teams make consistent calls across IT, OT, and third-party dependencies. ¹

Who it applies to (entity and operational context)

This requirement applies when your organization has adopted C2M2 and defined a scope for assessment (for example, an OT environment, a critical business unit, or an enterprise-wide program). It is especially relevant for energy sector organizations and critical infrastructure operators where risk decisions often involve tradeoffs with reliability and safety. ¹

Operationally, it applies to:

• Security and risk teams maintaining the risk register and facilitating governance
• System/application/OT owners who implement mitigations or decide on avoidance
• Procurement/vendor management for third-party risk transfer (contract/SLA/insurance) and third-party-driven remediation
• Business leadership who accept residual risk when mitigation is not feasible

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

1) Define a risk response playbook (one page is enough to start)

Minimum content:

• Definitions of mitigate, accept, avoid, transfer in your environment
• Decision criteria (see the matrix below)
• Approval thresholds (who can accept what)
• Escalation path when owners disagree or due dates slip
• Communication workflow for time-sensitive risks (who gets notified)

This aligns to the expectation that risk response is consistent and can be demonstrated. ¹

2) Standardize your risk record fields (so every risk is treatable)

Add required fields to your risk register (tool-agnostic):

• Risk statement (cause → event → impact)
• Scope tags (IT/OT, site, system, data type, third party)
• Inherent risk rating and current controls
• Selected treatment option (one of four)
• Treatment plan (work items, compensating controls, contract actions)
• Residual risk assessment after treatment
• Approver + date (and meeting reference if approved in committee)
• Target completion date or review date (for accepted risk)
• Closure criteria and validation evidence link

3) Use a decision matrix to select the treatment option

Keep it simple and defensible:

Treatment	Choose it when	Typical actions	Evidence to capture
Mitigate	You can reduce likelihood/impact to an acceptable level	Patch, harden, segment, add monitoring, remove exposure	Change records, configs, test results, updated diagrams
Accept	Further reduction is impractical and residual risk is within tolerance	Document exception, compensating controls, review cadence	Signed risk acceptance, rationale, residual risk rating
Avoid	The activity/system introduces unacceptable risk	Decommission, disable feature, stop data flow	Decommission plan, architectural decision record
Transfer	A third party contractually assumes some impact/cost	Insurance, contractual controls, indemnities, managed service	Contract/SLA clauses, insurance certificate, shared responsibility mapping

The point is not perfection; it is consistent treatment selection, recorded and approved. ¹

4) Establish approvals that match real authority (and enforce them)

Define who can approve each response:

• Mitigation: system owner + security review
• Acceptance: business risk owner (and risk committee for high-impact items)
• Avoidance: business owner + architecture/operations sign-off if it changes service delivery
• Transfer: procurement/legal + security review, with confirmation that the transfer is real (not assumed)

If you do nothing else, require approvals for risk acceptance and risk transfer, because those are the easiest to “paper over” without real coverage. ¹

5) Execute and track to closure (risk response must be operational, not static)

Run a recurring cadence:

• Weekly/biweekly: working session for owners on active mitigations and overdue items (guidance)
• Monthly/quarterly: risk committee for escalations and acceptances (guidance)
• After major incidents: post-incident review that updates risk treatments and decision criteria ¹

6) Test the process (tabletops and post-incident reviews)

C2M2-oriented programs benefit from demonstrating the process was used, learned from, and improved. Run periodic exercises or post-incident reviews and retain after-action items that show what changed (decision criteria, escalation, playbooks, or treatment plans). ¹

Required evidence and artifacts to retain (audit-ready)

Keep artifacts tied to specific risk IDs so you can produce them quickly:

• Risk response playbook (versioned) and escalation/approval matrix
• Risk register entries showing treatment, owner, dates, and approvals
• Risk acceptance memos (or committee minutes) with explicit residual risk acknowledgment
• Mitigation implementation evidence: tickets, change approvals, test/scan results, screenshots/config exports
• Avoidance evidence: decommission records, architecture decisions, firewall rules removing exposure
• Transfer evidence: executed contracts/SOWs, security addenda, SLAs, insurance certificates (if used), shared responsibility notes
• After-action reports and tracked remediation items from exercises or incidents ¹

Tip: In Daydream, teams typically map each risk to its treatment artifacts and approvals so evidence is one click from the register, not a scramble across email and ticketing systems.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me three recent risks and the documented response for each. Who approved acceptance?”
• “How do you decide between mitigate vs accept? Where are the criteria written?”
• “How do you ensure accepted risks are revisited and not forgotten?”
• “For transferred risk, what exactly was transferred? Where is it in the contract?”
• “Show that mitigations were completed and validated, not just planned.”
• “How do you handle OT constraints where patching is limited?”

The common hangup is traceability: auditors want a straight line from risk identification → decision → approval → action → verification. ¹

Frequent implementation mistakes (and how to avoid them)

1. “Accepted” means “we didn’t get to it.”
   Fix: Require a formal acceptance record with rationale, residual risk, compensating controls, and an approver who owns the business impact.

2. Risk transfer is assumed, not proven.
   Fix: Tie transfer to specific contract terms or insurance coverage documentation. “They’re a big provider” is not evidence.

3. Mitigations exist only as backlog items.
   Fix: Define closure criteria (for example: patch applied + scan clean, segmentation rule implemented + validated traffic path). Link validation artifacts.

4. No escalation for stuck items.
   Fix: Put an escalation clock in the workflow (guidance): if due dates slip or owners contest feasibility, route to a risk committee decision, and capture the outcome.

5. OT and third-party risks live outside the main risk register.
   Fix: Keep one register, tagged by domain. Separate registers cause inconsistent decisions and missing approvals.

Risk implications (why regulators and customers care)

If risk response is not rehearsed and documented, teams respond inconsistently, lose time during escalation, and struggle to prove required actions during audits, customer due diligence, or regulator review. This becomes a credibility issue: you may identify risks correctly but still fail governance expectations because you cannot show disciplined follow-through. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up the workflow)

• Publish a one-page risk response playbook with the four treatment options and approval thresholds. ¹
• Normalize the risk register fields so treatment and approval are mandatory for “active” risks.
• Pick a single intake path for new risks (risk assessments, vuln management exceptions, third-party findings, incident learnings).

Days 31–60 (make it operational)

• Start a recurring risk treatment working session with owners; track overdue mitigations and pending acceptances (guidance).
• Implement a simple decision matrix and require it in risk records as “treatment rationale.”
• Pilot the process on a subset: top operational risks, top third-party risks, and top OT risks.

Days 61–90 (prove it works, then tighten)

• Run a tabletop or use a recent incident/post-incident review to test escalation, decision-making, and documentation; retain after-action items and update the playbook. ¹
• Add governance reporting: open risks by treatment type, overdue mitigations, accepted risks pending review.
• If evidence is scattered, centralize it (Daydream or your GRC) so each risk record links to its artifacts and approvals.

Frequently Asked Questions

What counts as “risk transfer” for this requirement?

Transfer means shifting defined consequences to another party through a mechanism you can evidence, such as contract terms, SLAs, or insurance documentation. Keep proof tied to the specific risk so it’s clear what was transferred and what residual risk remains. ¹

Can we accept risk without a formal committee?

Yes, if you define who has authority to accept which risks and capture their approval in a durable record (memo, workflow approval, or meeting minutes). The acceptance must name the owner, rationale, and residual risk. ¹

How do we handle risks we cannot mitigate quickly due to OT uptime constraints?

Document mitigation constraints, apply compensating controls where possible, and escalate for a formal decision (accept temporarily, avoid the exposure path, or transfer where feasible). Track the plan and revisit based on operational windows. ¹

Do we need to treat every vulnerability as a separate risk response decision?

No. Grouping is acceptable if your risk record clearly describes the exposure, affected assets, and a single treatment plan that covers the set. Auditors care that identified cybersecurity risks have a documented response, not that every scanner finding becomes its own record. ¹

What evidence is strongest for “mitigated”?

Closure evidence that shows the control change happened and worked (for example, approved change record plus validation output from testing or monitoring). A ticket marked “done” without validation is a common audit failure point. ¹

How often should accepted risks be reviewed?

Set a review trigger that fits the risk (time-based, change-based, or incident-based) and record it in the acceptance. The key is that accepted risks have a defined reevaluation point and don’t remain accepted indefinitely by default. ¹

What you actually need to do

Use the cited implementation guidance when translating the requirement into day-to-day operating steps. ²

Footnotes

1. Cybersecurity Capability Maturity Model v2.1

2. DOE C2M2 program