Most continuity plans cover a few hours of downtime. Real events, such as the 2003 blackout where power took 4 days to return in some places, or a cloud fault of about 14.5 hours, show why a plan should also cover days. This post gives an outline you can adapt. It does not predict any event.
What the guidance says
Ready.gov's business continuity page lists six steps: prepare, define objectives, identify and prioritise risks and impacts, develop strategies, define teams and tasks, and test the plan.
NIST SP 800-34 Rev. 1 (May 2010, updated November 2010) offers "practical, real-world guidelines" on the purpose, process and format of information system contingency planning, and how it relates to emergency management and organisational resilience.
"Business Continuity in a Box," published 13 November 2023 by the Australian Signals Directorate's ACSC with contributions from CISA, is an interim solution to restore critical functions during or after a cyber incident. It has two components, continuity of communications and continuity of applications, for cases where the availability or integrity of data or systems is compromised.
What to put in the plan
- Critical functions and tolerances. List the five things you must keep doing, and how many hours or days each can stop.
- Dependencies. For each function, the systems, vendors, people and power it needs. This is where a dependency inventory pays off.
- Alternate communications. A way to reach staff when email and chat are down: a phone tree, a messaging app on personal devices, printed contacts. Test that it works without your main identity provider.
- Offline access. Printed or locally stored runbooks, recovery credentials in a sealed safe, and key contracts.
- Alternate working arrangements. Remote work, a second site, mobile hotspots, and who may spend money on the spot.
- Data. Backups kept apart from production, with a tested restore. State how long a restore of each system takes.
- Vendor plans. For critical vendors, their recovery targets, status pages and escalation contacts, and your fallback if they are down for days.
- Recovery order. A numbered order of restoring systems, with dependencies, such as DNS and identity first.
- Roles. Named decision makers and deputies, with who speaks to customers and regulators.
- Customer communication. Template messages and a status page hosted away from your main provider.
- Triggers. The conditions at which you declare the plan active, and who decides.
- Test schedule. At least one tabletop a year, and a restore test of your most important system.
What to do now
- Write the one page version first: functions, owners, contacts, order of recovery.
- Run a one hour tabletop with this scenario: no network and no main cloud region for three days. Note every question nobody could answer.
- Fix the top five gaps and date the next test.
- Store the plan where you can reach it during an outage.
How this could have been avoided
A plan cannot prevent an outage. It prevents improvisation. Most failures in tabletop exercises are dependencies nobody had written down.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
What are the six steps on the Ready.gov business continuity page?
Prepare, define objectives, identify risks and impacts, develop strategies, define teams and tasks, and test the plan.
What two components does Business Continuity in a Box contain?
Continuity of communications and continuity of applications.
