An IT disaster recovery plan you can read at three in the morning
Most plans we come across are not wrong, they are unusable: too long, too old, and written for someone who already knows everything. This is what does belong in an IT disaster recovery plan, and in what shape.
Six parts that must not be missing
Everything else in it is useful. These six are the difference between a plan that works and a document that exists.
- When the plan appliesOne sentence saying when you open this document, and who may decide that. Without it the plan stays shut during the very outage it was written for, because nobody dares say that this is the one.
- The order of recoveryWhich systems come back first and which can wait, with the reason next to them. The reason matters more than the order: the order changes, and then you can derive it again instead of inventing it again.
- Per system: where the copy sitsLocation, how you reach it and who holds the keys. Including how you reach it when the environment you normally log in through is unavailable — the most frequently missing line in any plan.
- Dependencies between systemsWhat has to be running before the next system starts: naming, licences, certificates, outbound integrations. This list writes itself the first time you actually restore, and almost never before that.
- Contact details that live outside the environmentPhone numbers for your own people, for suppliers and for whoever provides the line. On paper or on a phone, not inside the system that is down.
- How you know it is finishedOne check per system saying it genuinely works, not merely that it is switched on. Without it the organisation comes back to something half-running, and then the second outage starts.
How you can tell a plan is usable
Four properties that have nothing to do with content and everything to do with whether it gets used.
It fits in few pages
The core belongs in a handful of pages, with the detail in appendices. Anyone who has to leaf through it during an outage will not read it.
It is written for someone else
Not for the engineer who built it, but for the colleague on duty. So no abbreviations that only exist internally, and the steps spelled out.
It opens outside the environment
A plan living on the file share you are restoring does not exist at that moment. A printed copy in two locations is old-fashioned and works.
It carries a date and an owner
One person who keeps it current, and a date that tells you how old it is. A plan without an owner ages at exactly the speed the environment changes.
How the plan stays current
Maintenance is where plans come apart, not the writing. Three moments when it has to change.
- With every change that adds or removes somethingA system arrives, one leaves, an integration changes — the plan changes with it. That only works if it sits inside the change process and not inside an annual clean-up.
- After every rehearsalEvery rehearsal turns up things that ran differently than expected. Those go in straight away, because in three months nobody remembers them.
- After every real outageIncluding the ones that went well. Especially those, because then it is known what worked and why, and that is the part nobody normally writes down.
- When a supplier changesDifferent party, different phone numbers, different agreements on response time. A plan carrying the previous supplier’s number is worse than a plan with no number at all.
Further reading
What this connects to.
Questions we get about this
The ones that come up most, answered briefly.
How long should an IT disaster recovery plan be?
The core belongs in a handful of pages, with the detail in appendices. Anyone who has to leaf through it during an outage will not read it — and then the length is exactly the problem the plan should have solved.
Where do you keep the plan?
Outside the environment you are restoring. A plan on the file share that is down does not exist at that moment. A printed copy in two locations is old-fashioned and works, and a copy on a phone works too.
Who should keep the plan current?
One named person, and the updating belongs inside the change process rather than inside an annual clean-up. A plan without an owner ages at exactly the speed the environment changes.
Let us try to break the plan
Send us what exists now, or tell us what runs if nothing exists yet. We walk it through against the six parts above and say which ones are missing.
Practical IT knowledge in your inbox
New guides on management, security and the workplace, written by the people doing the work. No sales talk, and you can unsubscribe in one click.