Incident response and continuity

To meet the C2M2 incident response and continuity requirement, you must maintain a tested, repeatable capability to respond to cyber incidents and recover operations to an acceptable state. Operationalize it by defining scope, documenting IR and continuity plans, training and exercising teams, integrating third parties and OT/IT dependencies, and retaining evidence that proves the capability works in practice. ¹

Key takeaways:

• Documented plans are necessary but not sufficient; you need proof of execution through exercises and corrective actions. ¹
• Tie incident response to continuity and recovery outcomes: roles, communications, restoration steps, and decision rights. ¹
• Build audit-ready evidence: exercise reports, after-action items, recovery test results, and governance approvals. ¹

“Incident response and continuity” under C2M2 is a capability requirement: your organization must be able to detect and manage a cyber incident, contain harm, and restore critical services without improvising under pressure. The model’s language is short, but examiners and customers will judge you on operational reality: whether people know what to do, whether recovery steps are workable for your environment, and whether you can show records that the capability is maintained over time. ¹

For Compliance Officers, CCOs, and GRC leads, the fastest path is to treat this as an integrated control set spanning incident response (IR), business continuity/disaster recovery (BC/DR), and operational resilience. That means one consistent incident severity scheme, clear escalation and communications, validated backups and restoration procedures, and defined recovery objectives appropriate to the assets in scope (especially OT environments where safety and availability constraints change the playbook). ¹

This page gives requirement-level implementation guidance you can put into motion immediately: who owns what, the minimum plan content, step-by-step execution, artifacts to retain, and the audit questions that typically expose gaps.

Regulatory text

C2M2 requirement (C2M2-04): “Maintain capability to respond and recover from cyber incidents.” ¹

Plain-English interpretation

You need an end-to-end capability that works under stress:

• Respond: identify, triage, coordinate, contain, eradicate, and communicate during a cyber incident.
• Recover: restore systems and business/operational functions to an acceptable state, including validated restoration steps and decision-making for degraded operations. ¹

A written plan alone does not demonstrate capability. Capability is demonstrated by prepared people, working procedures, and evidence of testing with outcomes and follow-up. ¹

Who it applies to

In-scope entities

This applies to organizations that have adopted C2M2 for a defined scope, commonly:

• Energy sector organizations
• Critical infrastructure operators ¹

Operational context (scope matters)

Define scope the same way you scope your C2M2 assessment:

• Business unit(s), control center(s), plants, substations, corporate IT, or specific OT environments
• Shared services that affect recovery (identity, network, logging, backups)
• Key third parties that provide technology, remote access, monitoring, hosting, or managed response capabilities ¹

If you do not pin down scope, you will end up with generic plans that fail during an incident and cannot be defended in audits.

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

1) Set governance and decision rights

• Assign an Incident Response Owner (often Security/IR) and a Continuity/Recovery Owner (often IT/Operations resiliency).
• Define the incident commander role and alternates.
• Establish who can authorize containment actions that impact availability (especially in OT) and who can declare disaster recovery or activate continuity procedures. ¹

Practical tip: publish a one-page “authority matrix” that lists decisions (isolate network segment, disable remote access, failover, shutdown) and the approving role.

2) Define incident categories and severity that drive actions

• Create a small set of severity levels tied to:
  • expected operational impact,
  • data exposure risk,
  • safety or reliability impact (OT),
  • regulatory/customer notification triggers (if applicable to your organization).
• Map each severity to required actions: who gets paged, how fast you escalate, and whether continuity plans activate. ¹

3) Build (or fix) the IR plan so it is executable

Minimum content operators expect:

• Intake and triage process (including who can declare an incident)
• Roles and contact methods (primary and out-of-band)
• Containment and eradication playbooks for common scenarios (ransomware, privileged account compromise, remote access misuse, OT boundary compromise)
• Evidence handling and internal reporting expectations
• Communications plan (executives, operations, legal/compliance, HR, third parties, customers as relevant) ¹

Keep it usable. A plan that reads like a policy fails at 2 a.m.

4) Build continuity and recovery procedures that connect to IR

Continuity and recovery content should include:

• Critical services/assets list for the scoped environment (include OT dependencies where relevant)
• Restoration prerequisites (credentials, images, configs, vendor access, licensing keys)
• Backup and restore procedures (including how you verify integrity before reintroducing systems)
• Failover steps and “operate in degraded mode” procedures if full restoration is not immediately possible ¹

Third-party dependency mapping: document which third parties are required for restoration (managed service provider, OEM, cloud provider, comms carrier). If they are unavailable during an incident, your “capability” is not real.

5) Train the people who will execute the plan

• Role-based training for incident commanders, on-call responders, OT operators, comms lead, and continuity coordinators.
• Include alternates; incidents happen during vacations.
• Track completion and maintain updated call trees. ¹

6) Exercise and test, then fix what breaks

C2M2 practical guidance points to testing plans with documented outcomes. ¹

Run at least two types of validation:

• Tabletop exercises: decision-making, escalation, communications, and handoffs between IR and continuity teams.
• Operational recovery tests: restoration of representative systems, validation of backups, and proof that procedures are current.

For each exercise/test:

• record the scenario and scope,
• record what happened (timeline),
• record gaps and corrective actions,
• assign owners and due dates for remediation,
• rerun or validate fixes where appropriate. ¹

7) Integrate third parties into response and recovery

You need third-party-ready execution, not a contract clause nobody reads.

• Confirm notification paths and escalation contacts for critical third parties.
• Validate access methods for emergencies (including MFA break-glass handling consistent with your security model).
• Capture third-party IR support expectations (forensics support, log access, restore support) and ensure they align with your plan. ¹

Where Daydream fits: use Daydream to maintain a single system of record for critical third parties, their incident contacts, contractual response obligations, and evidence (exercise reports, attestations, remediation items) so you can prove continuity dependencies are actively managed.

Required evidence and artifacts to retain

Auditors typically want evidence that the capability exists and is maintained. Keep:

• Approved Incident Response Plan and Continuity/Recovery Plan (with version history)
• Incident severity matrix and escalation procedures
• Roles, on-call rosters, and out-of-band contact methods
• Training completion records (role-based)
• Exercise schedules, tabletop materials, attendance, and results
• After-action reports with corrective action plans and closure evidence
• Recovery test records (what was restored, how integrity was verified, issues found)
• Third-party dependency list and incident/continuity contact validation records ¹

Retention period depends on your internal policies and any sector requirements applicable to you; C2M2 itself does not prescribe a specific duration in the provided excerpt. ¹

Common exam/audit questions and hangups

Expect these questions and pre-answer them with artifacts:

1. “Show me that you can recover.” Provide recovery test evidence, not just DR diagrams. ¹
2. “When was the last time you exercised the plan, and what changed afterward?” Provide after-action items and closure proof. ¹
3. “Who declares an incident and who can shut down/isolate systems?” Provide decision rights documentation.
4. “How do third parties factor into recovery?” Provide dependency mapping and validated contacts.
5. “How does OT change the process?” Show adapted containment and recovery steps that respect safety/reliability constraints.

Frequent implementation mistakes (and how to avoid them)

• Mistake: IR and BC/DR are separate binders with no handoff.
  Fix: define explicit triggers for continuity activation and a handoff checklist from incident command to recovery lead.

• Mistake: No proof the plan works.
  Fix: run exercises and recovery tests; retain documented outcomes and remediation. ¹

• Mistake: Call trees that are wrong during the incident.
  Fix: validate contacts periodically as part of on-call administration; require updates after org changes.

• Mistake: Over-reliance on a single third party (MSP/OEM/cloud) without contingencies.
  Fix: document alternate contacts, alternate access paths, and minimum internal steps to stabilize and preserve evidence.

• Mistake: “Backup exists” is assumed, not proven.
  Fix: test restoration and integrity verification; record results and lessons learned.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this C2M2 requirement, so this page does not cite enforcement outcomes. ¹

Operationally, the risk is concrete: if IR and continuity are not rehearsed and documented, response becomes inconsistent, escalation slows, and you may be unable to prove required actions during audits, customer diligence, or regulator review. ¹

Practical 30/60/90-day execution plan

Use this as an operator’s rollout sequence; adapt to your scope and criticality.

First 30 days (stabilize the basics)

• Confirm scope for “incident response and continuity” (systems, sites, OT/IT boundaries, critical third parties). ¹
• Assign owners, incident commander role, and decision rights; publish authority matrix.
• Inventory existing IR/BC/DR documents; identify missing minimum content.
• Validate incident contacts (internal and critical third parties); establish out-of-band comms.
• Draft or revise severity matrix and escalation paths.

Days 31–60 (make it executable)

• Convert plans into checklists and playbooks for top scenarios relevant to your environment.
• Create restoration runbooks for the most critical services; confirm prerequisites and access.
• Deliver role-based training; document completion. ¹
• Stand up corrective action tracking for resilience gaps (a simple register is fine if it is maintained).

Days 61–90 (prove capability and generate evidence)

• Run a tabletop exercise that forces the IR-to-continuity handoff; produce an after-action report with assigned remediations. ¹
• Run at least one recovery test of representative systems; document outcomes and integrity checks.
• Close high-severity corrective actions or document compensating controls and a funded plan of action.
• Package an audit-ready evidence set (plans, training, exercises, recovery tests, third-party dependencies) for quick retrieval.

Frequently Asked Questions

Do I need both an Incident Response Plan and a Business Continuity/Disaster Recovery plan to meet this requirement?

You need a capability to respond and recover, so most organizations document IR plus continuity/recovery procedures that work together. Auditors will look for a clear handoff from incident command to restoration and business/operational recovery. ¹

What counts as “tested” for C2M2 incident response and continuity?

C2M2-aligned practice is to test plans with documented outcomes, which commonly includes tabletop exercises and recovery tests. The key is keeping records of results and corrective actions, not just a calendar invite. ¹

How should we handle OT environments where containment can disrupt operations?

Define decision rights and pre-approved containment options that reflect safety and reliability constraints, then exercise those decisions in scenarios. Document who can authorize isolation or shutdown actions and how continuity steps activate. ¹

How do we include third parties without turning this into a contract review project?

Start with the third parties you cannot recover without, then document incident contacts, escalation steps, and restoration dependencies. Validate those details during exercises so you learn where assumptions break. ¹

What evidence is most persuasive in an audit?

Exercise reports with after-action items and closure evidence, plus recovery test records that show restoration actually worked. Pair those with approved plans and training logs to show the capability is maintained. ¹

We have a plan, but it’s outdated. What’s the fastest way to get to “capability”?

Update the minimum executable sections first (roles, contacts, severity, escalation, initial containment, restoration prerequisites), then run a tabletop to force real decisions. Use the after-action report as your prioritized remediation list. ¹

What you actually need to do

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

Footnotes

1. DOE C2M2

2. DOE C2M2 program