IT Disaster Recovery Plan: What It Must Include

An IT disaster recovery plan is a written, tested description of how to bring technology back after an outage, a failure or an attack. It is related to, but different from, a business continuity plan. Business continuity covers how the organization keeps operating, including people, premises and processes. Disaster recovery covers how the systems that support it are restored. Both matter, and the disaster recovery plan is the technical half.

Two numbers shape the whole plan. The recovery time objective is how long a system can be down before the harm becomes unacceptable. The recovery point objective is how much recent data can be lost. A business impact analysis, which ranks systems by what their downtime costs, turns these into targets for each system. The answers are usually different for a payments system and for an internal wiki, and treating everything as equally urgent makes the plan slow and expensive.

List every system, where its data lives, who owns it and what it depends on. Dependencies are where plans usually fail: identity and directory services, DNS, networking, licence servers, certificates and encryption keys. A database cannot be restored if the system that holds its keys is also gone. Record vendor and support contacts alongside each entry.

For each system, note how it is protected, whether by backups, replication or snapshots, where the copies are kept, how long a restore takes and who can perform it. Include at least one copy that is offline or cannot be changed from the production network, because attackers often go after backups first. A plan that says "restore from backup" without saying where it is, how long it takes and who does it is not yet a plan.

A runbook is a step-by-step procedure for restoring a system, in the right order, with the decision points spelled out. Write it so that a capable person who did not build the system could follow it under pressure. Store copies where they can be reached when the main systems are down, such as printed, or on a separate service, together with the credentials needed, held securely.

Decide who leads the response, who deputizes and who can authorize spending or shutting systems down. Keep contact details for staff, suppliers and customers in a place that does not depend on your own email or phone system. Note any obligations to notify regulators, customers or insurers, which vary by country and sector, so that no one has to work them out during the incident.

Assume that production systems and connected backups may both be affected. The plan should cover isolating affected systems, preserving evidence, restoring into a clean environment, verifying before reconnecting, and rotating credentials. Restore order matters, because identity and core infrastructure usually have to come first.

A plan goes out of date every time a system, a supplier or a person changes. Review it on a schedule and after significant changes. Most important, test it. A plan that has never been exercised contains assumptions, not facts.