Organisations get started by identifying essential functions, the dependencies that support them and the maximum acceptable downtime for each. From there, define alternate processes, staffing, communications and recovery steps, then test them. Security and resilience teams should align the COOP with incident response, backup, identity recovery and third-party dependency planning.
What a COOP should cover first
A useful starting point is not the document format, but the operating reality behind it: which functions must keep running, what business dependencies they rely on, and how long the organisation can tolerate interruption before the impact becomes unacceptable. That is the point where continuity planning becomes a decision-making tool rather than a generic policy statement. A COOP should reflect service criticality, not just organisational charts.
For many teams, the first practical task is to separate “important” from “essential” and then define the minimum acceptable service level for each essential function. That distinction drives staffing plans, alternate processing methods, escalation thresholds and the order of recovery. It also helps avoid a common failure mode where every team treats itself as critical and the plan becomes too broad to execute under stress.
How to build the plan around dependencies and alternate operations
Once essential functions are identified, map the dependencies that make them possible, including systems, people, facilities, vendors, communications, and data access. A continuity plan is only as strong as its weakest upstream dependency, so the mapping should include the support paths that are easy to overlook, such as identity services, backup access, and third-party operational handoffs. NHIMG’s Business Continuity and Disaster Recovery Guide is useful here because it connects business impact analysis, recovery objectives, testing, and identity dependencies in one continuity view.
From that dependency map, define alternate ways to perform the work if the normal environment is unavailable. In practice, that means deciding what can be done manually, what can move to a backup location or backup system, and what needs a temporary workaround versus a true recovery. The best COOPs are explicit about who can invoke the alternate process, what information they need to do so, and what conditions end the workaround and trigger a return to normal operations.
Planning also needs to reflect cyber resilience, not only physical disruption. Organisations increasingly need a continuity plan that assumes some disruptions will be caused by cyber incidents, identity outages, or degraded trust in core services. NHIMG’s Cyber Resilience Guide is a helpful companion when the COOP must account for graceful degradation, crisis exercises, and recovery metrics as part of normal preparedness.
Testing, communications, and recovery decisions that make the COOP usable
A COOP only becomes credible once it is exercised under realistic conditions. Start with table-top testing for decision flow, communications and role clarity, then progress to functional tests that prove alternate processes and recovery paths actually work. Testing should confirm that teams can reach the right people, that the right approvals are available, and that recovery steps do not depend on assumptions nobody has verified in months.
Communications deserve the same discipline as technical recovery. If staff, customers, suppliers or partners do not know what status updates mean, the plan fails even if the underlying systems are restored. The communications section should define primary and backup channels, message ownership, approval authority and the trigger for declaring a continuity event versus a local operational issue. External guidance such as NCSC UK Advice and Guidance is useful for teams looking for practical operational and resilience advice to support this work.
Recovery planning should also include what happens to security controls during an outage. Some controls may be temporarily relaxed to keep critical functions going, but that decision should be explicit, time bound and logged. If backup systems, identity recovery, or third-party services are part of the recovery path, they should be tested on the same schedule as the core continuity steps so the plan does not fail at the handoff point.
Risk and Threat Considerations
COOPs often fail when they are written around the normal-state organisation instead of the degraded-state organisation. The main risks are hidden dependencies, outdated contact trees, unrealistic recovery assumptions and alternate processes that have never been tested with the people who would need to use them.
Failure mechanism: A disruption removes one critical dependency, such as a site, service, supplier, or identity path, and the continuity plan discovers too late that the substitute process still depends on the same unavailable component.
Impact: Essential functions stall, recovery is delayed, and the organisation can lose control of communications, access, and service prioritisation at the moment it most needs clarity.
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 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 | GV.RM-01 — Risk Management Strategy | COOP scoping depends on business impact, downtime tolerance, and recovery prioritisation. |
| RC.RP-01 — Recovery Plan Execution | COOPs require tested recovery steps, alternate processes, and restoration sequencing. | |
| RC.CO-03 — Recovery Communications | Continuity planning relies on clear status updates and alternate communication paths during disruption. | |
| Recommendation — Define continuity priorities from business impact and recovery tolerance. Exercise recovery procedures so essential functions can be restored in order. Establish and test crisis communications for continuity events. | ||
| NIST SP 800-53 Rev 5 | CP-2 — Contingency Plan | A COOP is fundamentally a contingency planning artifact for essential operations. |
| CP-4 — Contingency Plan Testing | The plan must be exercised to validate alternate processes and recovery assumptions. | |
| Recommendation — Document contingency procedures for essential functions and supporting dependencies. Test contingency capabilities on a defined schedule. | ||
Practitioner Guidance
What to prioritise: Begin with one or two essential functions that are truly business critical, then work outward from their dependencies. A thin, tested plan for the highest-value services is more useful than an exhaustive but untested document that no one can execute under pressure.
What to verify: Confirm that the organisation can still authenticate users, contact decision makers, access data, and invoke alternate processes if the primary environment is unavailable. If any of those four elements depends on a single team, single vendor, or single location, the COOP is still incomplete.
What good looks like: A good starting COOP has named owners, clear downtime tolerances, documented fallback procedures, and evidence from exercises that the organisation can actually perform them. The best signal is not a polished template, it is whether a different team can follow the plan without tribal knowledge.
Practitioner takeaway: Treat the COOP as an operational recovery blueprint, not a static compliance artifact, and make sure it is built around the dependencies that can truly stop the business, not the ones that merely look important on paper.
Related resources from NHI Mgmt Group
- How do organisations get started with a Business Continuity Plan?
- How do organisations get started with continuity of operations?
- How should organisations structure a business continuity plan so critical operations can keep running during a major disruption?
- How do organisations get started with Privacy Program Plan (PPP)?