A Continuity of Operations Plan (COOP) sets out how an organisation will keep essential functions running during disruption. It covers roles, alternate processes, recovery priorities and communication steps. Security and resilience teams should test assumptions, confirm dependencies and rehearse failover, because a COOP that is not exercised often fails when staff, systems or facilities are unavailable.
How COOP works as an operational continuity playbook
A COOP works by defining what must keep running, who is responsible, what alternate methods exist, and when the organisation shifts from normal operations to a degraded but workable mode. It is less about perfect recovery and more about sustaining essential functions long enough to absorb the disruption and restore normal service.
The practical value comes from pre-deciding the hard parts: minimum staffing, manual workarounds, alternate sites or platforms, emergency communications and the order in which functions come back. Without those decisions, teams improvise under pressure and continuity breaks down at exactly the point it is needed most.
What a COOP actually contains
A usable COOP is usually built around essential functions rather than every process in the organisation. It identifies the critical services, the acceptable level of service during disruption, the people or teams that own each step, and the dependencies that can stop work, such as facilities, network access, suppliers, or key systems.
It also needs a trigger model. A COOP should say what conditions activate it, who declares activation, and what changes once it is live. That includes whether the organisation shifts to an alternate site, uses remote work, follows manual processing, or temporarily accepts reduced service quality to preserve the most important outcomes.
For continuity planning to be credible, it must connect business priorities to recovery order. NHIMG’s Business Continuity and Disaster Recovery Guide is useful here because it ties COOP thinking to recovery priorities, failover, testing and dependencies, which is where many plans become realistic or fail.
How COOP fails in practice
The most common failure is assuming that documented procedures will still work when people, systems, or facilities are unavailable. A COOP can look complete on paper and still fail if it depends on the same identity provider, the same office, the same admin access path, or the same small set of staff who may be unavailable during a real event.
A second failure mode is untested dependency drift. Over time, teams change software, suppliers, contact lists, escalation paths and operational ownership. If the plan is not refreshed, the continuity path may no longer match the real environment, so the team discovers the gap only during a disruption.
The resilience side of continuity is broader than one plan. NHIMG’s Cyber Resilience Guide is relevant because COOP is strongest when it sits inside a wider resilience strategy that includes exercises, impact tolerance and recovery testing rather than treating the document as a static checklist.
What good COOP testing proves
Testing should prove that the organisation can still execute essential work under constrained conditions. That means verifying that alternate processes are known, that people can reach the right contacts, that backups and failover paths are usable, and that the organisation can communicate decisions quickly when the usual channels are degraded.
Tabletop exercises are useful for decision-making and escalation paths, but they are not enough on their own. A strong programme mixes tabletop discussion with functional testing of communications, access, and recovery steps so the team learns where the plan breaks under real operational pressure.
When continuity depends on technology, testing should include the failure of a key supporting service, not just the primary business system. Otherwise the organisation may believe it has a working recovery path while the hidden dependency still creates a single point of failure.
Risk and Threat Considerations
COOP risk is usually created by hidden dependencies, over-centralised processes and untested assumptions about availability. The main exposure is not just downtime, but the possibility that staff can no longer perform essential functions because the plan assumes systems, locations, vendors or communications channels that are not there when needed.
Failure mechanism: A disruption removes a relied-on capability, such as the normal office, a core application, a communications channel, or a small group of key operators, and the organisation discovers that the continuity path was never truly independent.
Impact: Essential services slow down or stop, recovery priorities become unclear, manual workarounds are improvised, and the disruption can extend into a governance or compliance problem if the organisation cannot demonstrate operational continuity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan Execution | COOP is a recovery and continuity execution plan for disrupted essential functions. |
| GV.RR-01 — Roles, Responsibilities, and Authorities | COOP depends on named owners, activation authority and clear operational handoffs. | |
| PR.IR-04 — Backups and Recovery Capability | COOP relies on alternate processes, recovery priorities and workable restoration paths. | |
| Recommendation — Define and exercise recovery procedures that sustain essential services during disruption. Assign continuity ownership and authority for activation, fallback operations, and restoration decisions. Maintain tested backup and recovery capabilities that support essential functions under disruption. | ||
| CIS Controls v8 | CIS-11 — Data Recovery | COOP needs tested recovery methods and restore priorities for continuity under outage conditions. |
| Recommendation — Test recovery procedures and validate that critical services can be restored when needed. | ||
| NIST SP 800-53 Rev 5 | CP-2 — Contingency Plan | COOP is fundamentally a contingency planning problem for sustaining operations during disruption. |
| Recommendation — Document contingency actions that preserve essential functions during adverse events. | ||
Practitioner Guidance
What to verify: Confirm that each essential function has an owner, a fallback method, and a realistic recovery order. If any function depends on a single person, single site, or single system, treat that as a continuity weakness rather than a documentation issue.
Implementation sequence: Start with the most time-sensitive services, map their dependencies, define the minimum viable operating mode, then test the plan under degraded access and communication conditions. That sequence matters because continuity failures usually appear in dependencies before they appear in the business process itself.
Practitioner takeaway: A COOP is only useful when it describes how the organisation will keep operating under real constraints, not how it hopes to recover once everything is already available again.