Technology recovered, business still stuck
Picture a regional outage. Engineers restore the database and bring the application up. Meanwhile support does not know what to tell customers, finance cannot approve emergency spend, sales is promising dates nobody can meet, and the chat tool everyone uses is down too. Technically, recovery is on track. Organisationally, it is chaos.
A business continuity plan (BCP) covers that gap. Disaster recovery restores systems. Continuity keeps the organisation functioning while it happens: who decides, who talks to customers, what work continues manually, and which suppliers matter. It is the top layer of our backup and disaster recovery service, tying the technical pieces to the people who must use them.
What good looks like
A usable plan is short, specific and owned. It names people, not just roles. It starts from the recovery objectives the business already signed off. It links to the technical runbooks rather than repeating them. And it has been read aloud in a room by the people who would use it.
Be wary of the opposite: a long document produced to satisfy a questionnaire, stored in a shared drive that nobody opens, with a contact list from two reorganisations ago.
What goes in the plan
Scope and scenarios
Decide what disruptions you are planning for. For a cloud-based company the realistic list is short: loss of a cloud region or major service, compromise of the cloud account or identity provider, ransomware or data corruption, failure of a critical vendor, loss of a key person or team, and loss of office access. Each scenario gets a short playbook, not a novel.
Roles and decision rights
The most valuable content is often the simplest: who can declare an incident, who leads it, who may approve failing over to the recovery site, who can spend money without the usual approval, and who covers if they are unavailable. Decisions such as failing over a database involve data loss risk, so the plan states who owns that trade-off.
Priorities and dependencies
The plan restates service tiers and recovery order. Order matters because of dependencies: identity and networking before databases, databases before applications. We include a one-page dependency view and list external suppliers, such as DNS, payment, email and identity providers, with how to reach them and what their own status channels are.
Communication
Communication is where trust is won or lost. The plan defines audiences, channels and owners:
| Audience | Channel | Owner | Template |
|---|---|---|---|
| Staff | Primary chat, with out-of-band backup | Incident lead | Initial notice, update |
| Customers | Status page, email | Communications lead | Incident notice, resolution |
| Partners and key accounts | Direct contact | Account owner | Personal note |
| Leadership and board | Short briefing | CEO or delegate | Summary |
Templates are written in advance and reviewed by whoever handles legal and customer relations. Agree an out-of-band channel, such as phone numbers or a separate messaging tool, because your usual chat may be affected by the same event.
Workarounds
What can the business do while systems are degraded? Manual order capture, read-only mode, a static status page, queued processing. These are often cheap to define and make a large difference to customer experience. We capture them as short playbooks owned by the relevant team.
How it is built in practice
We run a working session with leadership, engineering and operations, using existing documents as inputs. A first draft is written by us, then reviewed and edited by your owners, because ownership of the content matters more than elegance. Where possible we store the plan in version control or a documentation system that is independent of your main cloud, with a printable or offline export.
We then run a tabletop exercise: a facilitator presents a scenario in stages and the group talks through what they would do. It surfaces gaps quickly and cheaply. Typical findings include “we do not know who can authorise this” and “the status page login is held by one person”.
Decisions and trade-offs
Depth versus usability. Every added page lowers the chance it is read in a crisis. We bias toward a main document of a few pages and linked detail.
Standards and frameworks. Frameworks such as ISO 22301 exist for formal continuity management. Whether you need alignment depends on customers and sector. We write plans that can be mapped to a framework if required, and we do not claim any certification on your behalf.
Single owner or committee. A named owner who maintains the plan and a small group that exercises it works better than a large committee.
When to keep it minimal. A very small team can run on a two-page plan: contacts, decision rights, communications and links. Grow it as the company grows.
Common failure modes
- Contact lists out of date. Tie reviews to onboarding and offboarding.
- Plan inside the failed system.
- Roles without authority. The incident lead cannot actually approve spend or failover.
- Never exercised, so nobody has met the plan before the event.
- Technical and business plans disagree on priorities.
Writing scenarios people can follow under stress
A plan is read by tired people at the worst moment, so we write scenarios as short, structured playbooks rather than prose. Each one follows the same shape, which makes them quick to scan and easy to maintain.
- Trigger: what has happened and how you know, in plain words.
- First actions: the first few steps, with a named role for each.
- Decisions: who may approve failover, customer communication or spend, and what information they need.
- Communication: who is told, through which channel, and a template to start from.
- Return to normal: the conditions for stepping down and the review that follows.
Typical scenarios include loss of a region, a compromised account, a failed deployment that corrupts data, loss of a key supplier and loss of key staff. We deliberately keep each to a page or two and link to the technical disaster recovery runbooks for command level detail, so business readers are not buried in technical steps and engineers are not buried in policy.
Delivery and handover
You receive the plan, scenario playbooks, communication templates, a contact register with an owner, and the exercise report with actions. A review calendar is agreed: yearly at minimum, and after material change. Our Managed DevOps service can keep technical runbooks and on-call arrangements current for clients who want ongoing support, and the what is managed DevOps guide explains how that works.
How to tell it is working
Exercises complete with fewer open questions each time, contact details are verified on schedule, a new joiner can find and understand their role, and when something goes wrong, people act from the plan instead of improvising. To produce a plan your team will actually use, book a consultation.