How do organisations get started with continuity of operations?

What to define before writing the first continuity plan

continuity of operations starts with a clear business view of what must keep running, for how long it can be interrupted, and what minimum service level is acceptable while normal capacity is unavailable. That means identifying the essential functions, the dependencies behind them, and the recovery order before anyone starts writing procedural detail. If that first scoping step is vague, the plan will usually protect the wrong things.

The most useful early output is not a long document, but a short, agreed inventory of priority functions, critical people, core systems, key suppliers, and the assumptions those functions depend on. Organisations that treat continuity as a site-recovery exercise often miss a different failure mode, such as identity services, remote access, communications, or a single operational role that no one else can replace.

For a practical starting point, anchor the work around business impact analysis and recovery objectives. NHIMG’s Business Continuity and Disaster Recovery Guide covers the relationship between continuity planning, RTO, RPO, maximum tolerable downtime, and identity dependencies, which is the right structure for getting beyond generic preparedness.

How continuity planning should be shaped around real dependencies

A useful continuity plan describes how the organisation will keep operating under constraints, not just how it will restore systems after an outage. That is why the first pass should map upstream and downstream dependencies, including suppliers, cloud services, identity services, communications channels, and any manual workaround the business would actually use during disruption. The plan should also state which degraded-mode processes are acceptable and which are not.

Write the plan so it can be executed by people who may not be working from their normal environment, with reduced access, incomplete tooling, or partial team availability. The practical question is not whether an ideal restore path exists, but whether the organisation can still approve transactions, serve customers, meet obligations, and coordinate decisions when the normal operating model is unavailable. That requires recovery priorities to be explicit and communication paths to be tested as part of the plan, not left as an assumption.

Continuity also needs to account for the loss of staff as a real operational constraint. Cross-training, role substitution, escalation paths, and decision authority become part of continuity design when a key approver, operator, or specialist is unavailable. If the plan depends on one person or one team to interpret it, the organisation has not yet reached continuity maturity.

What should be tested first, and what failure modes matter most

The first tests should focus on the failures most likely to stop operations, not the most technically interesting ones. That usually means loss of site, loss of identity services, loss of communications, loss of key staff, and loss of a supplier or platform that sits on the critical path. These are the situations that expose whether the organisation can continue working in a constrained state rather than simply recover after the fact.

Testing should also verify whether recovery priorities match business reality. A continuity exercise is useful when it reveals that the documented sequence does not match how people actually need to work, or that a dependency assumed to be secondary is in practice the gatekeeper for the whole function. NHIMG’s Cyber Resilience Guide is a strong companion for this because it frames important business services, impact tolerance, recovery testing, and crisis exercises as one connected operating problem.

Testing should produce evidence that the plan can be executed, not just that it exists. The most useful evidence is whether teams can follow the process from memory, whether fallback communications work, whether dependencies were correctly identified, and whether the recovery sequence still makes sense when the normal environment is degraded. If a test only proves that a document is readable, it has not yet proven continuity.

Risk and Threat Considerations

Continuity planning fails most often when organisations assume the outage will be isolated to one obvious system. In practice, loss of identity services, staff unavailability, supplier failure, or communications breakdown can cascade into a broader operational outage even when the primary platform is still technically available. That makes continuity a resilience and dependency problem as much as a recovery problem.

Failure mechanism: A single point of dependency, such as one identity provider, one critical supplier, or one operator team, can block multiple business functions at once when the disruption hits. If the continuity plan does not model those shared dependencies, the organisation may restore infrastructure while still being unable to operate.

Impact: Recovery time becomes longer than expected, degraded-mode workarounds fail, and the organisation may be unable to meet service commitments, regulatory obligations, or internal decision deadlines. The damage is often amplified because the plan appears complete on paper but has not been exercised against the real failure path.

Practitioner Guidance

What to prioritise: Start with the few functions that would create the biggest operational or regulatory problem if they stopped, then trace the minimum people, systems, and suppliers needed to support them. That gives you a continuity scope that is small enough to test and useful enough to matter.

What to verify: Confirm that the plan covers degraded operations, not only full restoration. If the organisation cannot continue safely with partial capability, reduced staff, or delayed approvals, the plan is incomplete.

Decision rule: If a dependency can stop more than one essential function, treat it as a continuity priority even if it is not the most visible asset. If a test exposes that the documented recovery order is unrealistic, update the plan before the next exercise rather than after a real outage.

Practitioner takeaway: Good continuity planning begins with business dependency clarity, then proves the plan through realistic disruption tests; the goal is not a perfect restore path, but a survivable operating mode.

Related resources from NHI Mgmt Group

• How do organisations get started with a Business Continuity Plan?
• How do organisations get started with OT Security Operations Centre?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?