Business continuity planning is the work of deciding, in advance and in writing, how the organisation keeps operating when something takes a critical part of it away. Not what caused it — plans built around specific scenarios age badly — but what the business does when it cannot access its building, its systems, its data, its people or its main supplier.
Start with impact, not with threats
The foundation is a business impact analysis: for each activity the organisation performs, how quickly does its loss start to hurt, and how badly? Two numbers come out of it and drive everything else.
Two terms get run together here, and the distinction is the useful part. The maximum tolerable period of disruption is how long an activity can be unavailable before the consequences become unacceptable. The recovery time objective is the target for getting it back — a management decision that has to sit inside the tolerable limit, with margin, rather than being set equal to it. The recovery point objective is how much data the organisation can afford to lose, measured in time — a nightly backup means up to 24 hours of work gone, which is entirely acceptable for some systems and catastrophic for others. That figure is a design intention rather than an achieved outcome: until a restore has actually been tested end to end, the real recovery point is unknown.
Doing this properly produces the uncomfortable conversation that makes the plan real. Every department will say its activity is critical; the analysis forces a ranking, and the ranking determines where the money goes. A business that has not ranked has, in practice, decided to protect everything equally, which means protecting nothing adequately.
The dependencies people forget
Continuity failures rarely occur in the activity itself. They occur in something the activity quietly depends on:
- Key people. The person who knows how the pricing model works, or holds the only relationship with the largest customer. Succession and documentation are continuity controls, not HR ones;
- Single suppliers. A sole-source component, a single payment processor, one haulier. Concentration risk is cheap until it is not, and the analysis should extend to the supplier's own dependencies where the exposure is material;
- Systems and their interconnections. The ERP might be recoverable in four hours, but not if the integration that feeds it is hosted somewhere nobody has documented;
- Premises, including access to physical records, stock and equipment that cannot simply be worked around remotely;
- Cash. Continuity events consume cash — replacement equipment, expedited freight, overtime — while revenue is interrupted. A plan that does not address funding for the first month is incomplete.
Cyber has changed the shape of the problem
The dominant continuity scenario is no longer fire or flood. It is ransomware, and it breaks assumptions that older plans relied on. Backups connected to the network are encrypted along with everything else, which is why immutable or genuinely offline copies matter. The recovery is not a restore but a rebuild, since systems cannot be returned to service until they are known to be clean. And there is a regulatory clock running in parallel: a personal data breach that is likely to result in a risk to people's rights and freedoms must be notified to the ICO without undue delay and, where feasible, within 72 hours of the organisation becoming aware of it. Note both qualifications: not every incident or outage is notifiable, and the clock starts at awareness rather than at the moment of the breach. A plan that focuses only on getting systems back will miss the assessment as well as the deadline.
The practical tests are specific. Can you restore from a backup that was not reachable from the compromised network? Do you know, without the network, who to call and in what order? Is there a communications route that does not depend on the systems that are down?
Writing something people can use
The plans that work in an incident are short, role-based and available offline. A 90-page document on the intranet is not a plan; it is a compliance artefact. What is needed is: who declares an incident and who leads it; the immediate actions for the first hour; contact details for the response team, key suppliers, insurers, the bank and the regulator; the sequence in which systems and activities are recovered, taken from the impact analysis; and a communication plan for staff, customers and — if relevant — the media.
Insurance sits alongside it rather than inside it. Business interruption cover pays for loss; it does not restore operations, and the claim will be much easier where the plan generated a record of decisions and costs as they happened.
Testing is what makes it real
An untested plan is a hypothesis. Testing runs on a ladder: a desktop walkthrough of a scenario with the response team, then a functional test of a specific capability such as restoring a system from backup, then a full simulation. Most organisations should be doing the first annually and the second more often than that — a backup that has never been restored is not a backup, it is a belief.
Every test produces findings, and the findings are the output. A test where nothing went wrong was almost certainly too easy.
Then maintain it. Plans decay because the business changes: new systems, new suppliers, people who left. A plan reviewed annually and after every significant change stays usable; one written for an accreditation three years ago does not.
Acumon works on the control and assurance side of this through risk management, IT risk and cyber security audit work, and on the financial resilience side through cash flow monitoring and scenario modelling. If your plan has never been tested by actually restoring something, that is the test to run first.