A Disaster Recovery Runbook Your Team Can Actually Use

Plan, runbook and backup are different things

A business continuity plan covers how the whole organization keeps operating: people, facilities, suppliers and communication. A disaster recovery plan covers restoring IT services. A runbook is the step-by-step procedure for recovering from a specific scenario. Backups are an ingredient; restoring them in the right order, with the right people and credentials, is what the runbook describes.

Start with recovery objectives

• Recovery time objective (RTO): how long a service can be unavailable.
• Recovery point objective (RPO): how much recent data can be lost, measured in time.

Set both per service with its business owner, then group services into tiers. Compare the objectives with what the current design can deliver. When the design cannot meet an objective, that gap is a funding and risk decision for management, not a technical footnote.

Scenarios worth writing for

• Ransomware affecting servers and possibly backups.
• Loss of the server room through fire, flooding or a prolonged power outage.
• An outage at a cloud provider or a critical SaaS application.
• Corruption or accidental deletion of a key database.
• Loss of internet connectivity at the main office.
• Key people being unavailable, for example during a typhoon.

Each scenario changes the first hour. Ransomware requires isolation and investigation before restoration; a failed storage array does not.

What every runbook contains

• Scope and trigger: the scenario, and who can declare a disaster.
• Roles and contacts: incident lead, technical leads, communications lead, business owners and vendors, with alternates, contract numbers and support hours.
• Decision points: for example, "If the primary site cannot be restored within four hours, fail over to the recovery site."
• Prerequisites: access to the recovery site, break-glass credentials, licences and spare hardware.
• Recovery sequence: the order of restoration, based on dependencies.
• Procedures: numbered steps, each with an expected result and a check.
• Validation: how business users confirm the service works.
• Communication templates: for staff, customers and, where personal data is involved, regulators.
• Failback: how to return to normal operation afterwards.
• Version history: date, owner and what changed.

Recover in dependency order

1. Facilities and power.
2. Core network, firewalls and internet access.
3. Identity services: domain controllers, Microsoft Entra ID or other directories, MFA.
4. DNS, time synchronization and certificates.
5. Storage and backup platforms.
6. Databases.
7. Application servers.
8. Integrations and scheduled jobs.
9. User access: VPN, virtual desktops and endpoints.
10. Validation and handover to the business.

Write steps people can follow

• One action per step.
• Exact host names, console paths and commands.
• The expected result, and what to do if the result is different.
• Approximate duration, so the incident lead can track progress against the RTO.
• Clear warnings on destructive steps.
• No phrases like "restore the database as usual". Under pressure, nothing is usual.

Keep it available during the disaster

A runbook stored only on the file server that ransomware just encrypted is useless. Keep an encrypted offline copy with each incident lead, a printed copy in a secure location, and emergency access to credentials that does not depend on your main directory or email.

Test it

Record actual times against objectives, log every problem as an action with an owner and update the runbook immediately.

Notes for ransomware recovery

• Contain first: isolate affected systems and preserve evidence.
• Identify a clean restore point; malware may have been present before encryption started.
• Rebuild identity systems if they were compromised, and reset credentials.
• Scan restored systems before reconnecting them.
• Involve legal counsel. If personal data was affected, the National Privacy Commission's breach management rules require notification within 72 hours for breaches that meet their criteria.