Continuity of Operations Planning

Continuity of Operations Planning (COOP) is the bridge between incident response and business continuity. Incident response focuses on containing and eradicating a cybersecurity event; COOP focuses on sustaining the delivery of the function while the event is ongoing and restoring normal operations afterward. C2M2 RESPONSE-3.A (MIL1) sets a baseline expectation: you have established plans for sustaining and restoring functional delivery during and after a cybersecurity incident (Cybersecurity Capability Maturity Model v2.1).

For a CCO, compliance officer, or GRC lead, the operational goal is simple: make the plan “real” for the people who will run it under pressure. That means: (1) defining service-level priorities and minimum operating modes, (2) assigning decision authority and escalation criteria, (3) mapping dependencies (including third parties), (4) establishing communications patterns, and (5) testing the plan and capturing improvements. If you can’t show those elements with evidence, you will struggle in internal control testing, customer diligence, or regulator review (Cybersecurity Capability Maturity Model v2.1).

This page translates the requirement into a buildable, auditable COOP package you can implement quickly.

Requirement overview (C2M2 RESPONSE-3.A)

Requirement intent: Ensure the organization can keep delivering an in-scope function during a cybersecurity incident and restore it afterward with a planned, repeatable approach (Cybersecurity Capability Maturity Model v2.1).

What “function” means in practice: The business or operational capability in scope for your C2M2 assessment (for example: grid operations, generation support, pipeline monitoring, customer billing, market operations, or a plant control room workflow). Treat “function” as an outcome that stakeholders depend on, not a system name.

Regulatory text

Excerpt (requirement text): “Plans to sustain and restore the delivery of the function during and after a cybersecurity incident are established.” (Cybersecurity Capability Maturity Model v2.1)

Operator interpretation (what you must do):

• Define how the function will continue at a minimum acceptable level during a cyber event.
• Define how you will restore the function to normal delivery after containment/eradication.
• Establish the plan in a controlled form (documented, owned, versioned, accessible).
• Make it executable: named roles, decision criteria, communications workflow, and escalation path (Cybersecurity Capability Maturity Model v2.1).
• Prove it works through exercises or post-incident reviews, then track improvements to closure (Cybersecurity Capability Maturity Model v2.1).

Plain-English interpretation

You need a written, ready-to-run playbook that answers: “If we lose systems, integrity, or availability due to a cyber incident, how do we keep the function going, who decides what to shut down or fail over, how do we communicate, and what is the path back to normal?” The requirement is satisfied when the plan exists and is demonstrably operational, not when it is merely drafted.

Who it applies to

Entity scope

• Energy sector organizations and critical infrastructure operators using C2M2 to assess cybersecurity maturity (Cybersecurity Capability Maturity Model v2.1).
• Business units or operational environments (including OT) included in your defined C2M2 scope (Cybersecurity Capability Maturity Model v2.1).

Operational context (where it shows up)

• OT environments where safety and availability constraints limit “standard IT” response actions.
• Shared services (identity, network, SOC, endpoint tooling) that multiple functions depend on.
• Third-party dependencies that can become single points of failure (managed service providers, SaaS platforms, telecom, fuel logistics, OEM support).

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

Use the steps below to build an auditable COOP package aligned to RESPONSE-3.A.

1) Define the in-scope function and “minimum operating mode”

Create a one-page Function COOP Profile:

• Function description and owner (business and technical).
• Minimum operating mode definition (manual processing, degraded automation, alternate site, alternate control path).
• “Keep running vs. stop” safety and risk guardrails (especially for OT).

Tip: If you cannot describe the function without naming a system, you are not planning at the right level.

2) Map dependencies and constraints (include third parties)

Build a dependency map that is short enough to maintain:

• Critical applications, OT systems, data flows, and identity dependencies.
• People dependencies (specialist operators, on-call rotations).
• Physical dependencies (control rooms, radios, engineering workstations).
• Third-party dependencies and contact paths (support lines, escalation contracts, emergency access procedures).

Audit hangup to avoid: Treating third parties as “someone else’s problem.” COOP needs your side of the interface: who calls, what information you share, and what workaround exists if the third party is unavailable.

3) Write the COOP playbook (make it executable)

Your COOP plan should read like an operator’s runbook, not a policy. Include:

A. Activation and escalation

• Trigger criteria (examples: ransomware suspicion, loss of visibility, integrity compromise, widespread endpoint isolation).
• Who can declare COOP activation, and who must be notified.
• Escalation path to executives, legal/compliance, and operations leadership (Cybersecurity Capability Maturity Model v2.1).

B. Decision criteria

• Criteria for shutting down, isolating, or continuing operation in degraded mode.
• Criteria for failover to alternate tooling or sites.
• Data integrity decision points (when to distrust telemetry, billing data, historian data).

C. Sustainment procedures

• Steps to keep the function running while response teams investigate.
• Manual workaround steps and required approvals.
• “Golden sources” for instructions when standard systems are down (printed binders, offline laptops, secure mobile access).

D. Restoration procedures

• Preconditions for returning to normal operations (clean rebuild, validated integrity, monitoring restored).
• Restoration sequencing (most critical services first).
• Communications steps for status updates and stakeholder notifications (Cybersecurity Capability Maturity Model v2.1).

E. Communications workflow

• Internal audiences (ops, IT, executives, customer support).
• External audiences as applicable (partners, critical customers, regulators per your internal obligations).
• Approved channels if email/chat is compromised (Cybersecurity Capability Maturity Model v2.1).

4) Align COOP with incident response and disaster recovery (remove gaps)

Create a simple RACI that ties together:

• Incident Commander / SOC lead (investigation and containment).
• Function owner (continuity decisions and operational priorities).
• IT/OT engineering (technical execution).
• Comms lead (internal/external messaging).
• Compliance/legal (governance, obligations, documentation).

Common gap: IR declares containment actions that break operations because COOP priorities were never formalized. Fix this by requiring COOP sign-off on response actions that impact the function’s delivery.

5) Validate through exercises or post-incident reviews

Plan at least one of the following and retain evidence:

• Tabletop exercise that walks through activation, sustainment, and restoration.
• Technical exercise for one critical dependency (for example: alternate identity path, manual dispatch workflow).
• Post-incident review that explicitly assesses COOP performance and updates the plan (Cybersecurity Capability Maturity Model v2.1).

6) Track improvements to closure

Create after-action items with owners and due dates, then show closure evidence. Auditors accept imperfections; they do not accept “we found issues but didn’t fix them.”

Where Daydream fits naturally: Daydream can serve as the system of record for COOP artifacts, third-party dependency mappings, exercise evidence, and remediation tracking, so you can answer audits without hunting through chat logs and shared drives.

Required evidence and artifacts to retain

Maintain a tight evidence set that proves the plan exists, is executable, and was tested:

Artifact	What it proves	What auditors look for
COOP plan / playbook per function	Plans are established	Version control, owner, approval, accessibility
Function COOP Profile (one-page)	Clear scope and minimum mode	Explicit sustain/restore definitions
Dependency map (incl. third parties)	You understand critical dependencies	Named contacts, workaround paths
Escalation matrix + on-call roster	Clear decision path	Named roles, alternates, current contacts
Communications workflow templates	You can communicate under constraints	Alternate channels, pre-approved language where appropriate
Exercise materials + attendance	Plan was tested	Scenario, outputs, decisions made
After-action report + remediation log	You improve the plan	Issues, owners, closure evidence (Cybersecurity Capability Maturity Model v2.1)

Common exam/audit questions and hangups

Expect questions like:

• “Show me the plan for sustaining Function X if email, identity, or endpoint tooling is unavailable.”
• “Who can activate COOP and what triggers that decision?”
• “How do you coordinate OT safety constraints with cybersecurity containment actions?”
• “What third parties are required to restore service, and how do you contact them during an outage?”
• “Show evidence of a test or post-incident review and the resulting improvements.” (Cybersecurity Capability Maturity Model v2.1)

Hangups that slow reviews:

• Plans exist but are not function-specific.
• Plans are written but not accessible during an incident (stored behind SSO that might be down).
• No evidence of testing, or testing occurred but produced no tracked improvements.

Frequent implementation mistakes (and how to avoid them)

1. Copying generic BC/DR templates and calling it COOP.
   Fix: Add cyber-specific triggers, integrity decision points, and coordination with IR containment steps.

2. Leaving decision authority ambiguous.
   Fix: Name roles, define alternates, and document decision criteria and escalation (Cybersecurity Capability Maturity Model v2.1).

3. Ignoring third-party restore paths.
   Fix: For each critical third party, document emergency contacts, contract constraints, and fallback procedures.

4. Testing “once” with no follow-up.
   Fix: Every exercise must output after-action items and closure evidence (Cybersecurity Capability Maturity Model v2.1).

5. Assuming communications will work.
   Fix: Pre-plan alternate channels and pre-stage contact lists offline.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement. Practically, the risk is operational and evidentiary: without rehearsed, documented continuity planning, response becomes inconsistent, escalation slows, and you cannot prove control operation during audits, customer diligence, or regulator review (Cybersecurity Capability Maturity Model v2.1).

Practical 30/60/90-day execution plan

Use this as an execution backbone. Adjust the scope to your highest-criticality functions first.

First 30 days (stabilize and scope)

• Confirm which functions are in scope for your C2M2 assessment and name function owners (Cybersecurity Capability Maturity Model v2.1).
• Draft Function COOP Profiles for the top critical functions.
• Build dependency maps, including third-party restore contacts and constraints.
• Create an escalation matrix and COOP activation criteria.

By 60 days (publish executable playbooks)

• Publish a COOP playbook per critical function with sustainment + restoration steps.
• Align COOP with IR runbooks so containment actions require operational coordination.
• Implement document control and offline access for incident conditions.
• Draft communications workflows and templates for degraded communications.

By 90 days (prove it works and close gaps)

• Run at least one exercise or complete a post-incident review that explicitly validates COOP (Cybersecurity Capability Maturity Model v2.1).
• Produce an after-action report and track remediation items to closure.
• Update playbooks based on exercise outcomes and re-approve.
• Centralize artifacts and evidence (for example, in Daydream) to support audits and third-party diligence.

Frequently Asked Questions

Do I need a separate COOP plan if we already have incident response and disaster recovery documents?

Usually, yes. COOP must explain how you keep the function running during the incident and how you restore it afterward; IR and DR often miss decision criteria, sustainment procedures, and function-specific workarounds (Cybersecurity Capability Maturity Model v2.1).

What’s the minimum acceptable evidence for C2M2 RESPONSE-3.A at a baseline maturity level?

A documented plan (or playbook) that covers sustainment and restoration for the in-scope function, plus evidence the organization can execute it (named roles, escalation, communications) (Cybersecurity Capability Maturity Model v2.1).

How do I handle continuity planning when a third party runs the critical system?

Document your operational interface: triggers to contact the third party, emergency escalation paths, required information to share, and your internal workaround if the third party is unavailable. Treat third-party restoration steps as part of your plan, not an external assumption.

What should trigger COOP activation during a cyber incident?

Define triggers tied to loss of availability, loss of integrity, or loss of operational visibility for the function. Write triggers so an on-call leader can make a fast decision and start the escalation workflow (Cybersecurity Capability Maturity Model v2.1).

How do we “test” COOP without disrupting operations?

Start with a tabletop exercise that walks through sustainment and restoration decisions, then add targeted technical tests for one dependency at a time. Capture decisions made, gaps found, and after-action items (Cybersecurity Capability Maturity Model v2.1).

Where do teams usually store COOP plans so they’re usable during identity outages?

Keep a controlled copy in a location that remains accessible during an identity or collaboration-system outage, and ensure operators know where it is. Many teams also maintain a secure offline packet with contact lists and minimum operating procedures.