Disaster Recovery Plan Template: Recovery Objectives, Runbooks and Testing

A disaster recovery plan that has never been run end to end, or that assumes the directory, certificates and secrets vault will simply be there, will not deliver the recovery times it promises. This template covers the IT side of recovery: recovery objectives per system, the dependency map and restore order, runbook structure, roles, and a testing schedule. It puts identity first in the restore sequence, because almost every other system needs the directory, PKI, a secrets vault and working service accounts before it can start. It follows the NIST SP 800-34 Rev. 1 phases (activation and notification, recovery, reconstitution) and notes the DORA Article 11 and 12 requirements for EU financial entities. Which business activities matter and how long they can stop is decided in the companion Business Continuity Plan Template; this plan takes those recovery time objectives as input. It is written for infrastructure, platform, identity and security teams and the IT leaders who approve the plan.

How to use this template

• Replace text in square brackets, such as [Organisation], [IT recovery lead] and [4 hours], with your own terms and values. Every value in brackets is a placeholder.
• Take the business recovery time objectives (RTOs) and data loss tolerances from the Business Continuity Plan Template; do not set them in IT. Where IT cannot meet a business RTO, record the gap in section 5 and report it back.
• Keep this document at plan level. Write one runbook per system or recovery group using the structure in section 4.5, held in [runbook repository] with an offline copy.
• Cyber incident containment and eradication come first and sit in the Incident Response Plan Template. Recovery from ransomware specifically is covered in the Ransomware Response and Recovery Guide. This plan starts when the incident lead releases systems for recovery.
• For background on architectures and the BC and DR plan family, see the Business Continuity and Disaster Recovery Guide.

1. Purpose

This plan sets out how [Organisation] will restore the IT systems, data and infrastructure that support its prioritised business activities, within agreed recovery time and recovery point objectives, after a disruption such as ransomware, data centre or cloud region loss, data corruption or major supplier failure. It defines the restore order, the procedures and authority to execute it, and the testing programme that proves it works.

2. Scope

• Systems: all systems listed in the recovery objectives register (section 4.1), and every system they depend on, including identity infrastructure, network and DNS, backup platforms and management tooling.
• Locations: [primary data centre], [secondary site], [cloud tenancies and regions], [SaaS services where [Organisation] holds the data recovery responsibility].
• Scenarios: loss of a site or region; destructive cyber attack with compromised administrative identities; data corruption or deletion replicated to secondary copies; failure of a critical provider.
• Out of scope: business workarounds, staff relocation and crisis management (Business Continuity Plan); incident investigation (Incident Response Plan).

3. Roles and responsibilities

4. Policy statements

4.1 Recovery objectives register

1. Every in-scope system must have a recovery tier, an RTO and a recovery point objective (RPO) derived from the business activities it supports. NIST SP 800-34 defines the RTO as the maximum time a system can be unavailable before unacceptable impact, which must be shorter than the maximum tolerable downtime, and the RPO as the point in time to which data must be recoverable.
2. Each entry must record the demonstrated recovery time from the last test, not only the target.

Tier 0 RTOs must be shorter than any tier 1 RTO, because tier 1 cannot start until tier 0 is restored.

4.2 Recovery strategies

1. Replication must not be the only copy: replicated deletion, corruption or encryption reaches the secondary too. Every tier must also have backups held offline or immutable, with write and delete access limited to [backup administrators] using credentials separate from the production directory. See the Backup Security and Immutable Backup Guide and the Backup Identity Isolation Guide.
2. Infrastructure must be reproducible from version-controlled infrastructure-as-code templates and golden images, with copies stored offline.

4.3 Dependency map and restore order

1. [IT recovery lead] must maintain a dependency map showing, for each tier 1 and 2 system, what it needs to start and authenticate: network, DNS, time, directory, certificates, secrets, service accounts, databases and external APIs.
2. Recovery must proceed in recovery groups in this order unless [IT recovery lead] records a reason to deviate:

4.4 Restoring identity first

If attackers held administrative or service credentials, restoring systems that still trust those credentials hands the environment back to them. In the Storm-0501 attacks the group took over domain controllers and Entra Connect Sync servers, which is why sync servers belong in tier 0 and their credentials must be rotated after any domain compromise. The identity recovery lead must:

1. Directory: follow the Microsoft AD forest recovery procedure: restore one writable domain controller per domain on an isolated network (forest root first), with a nonauthoritative AD DS restore and an authoritative SYSVOL restore on the first forest root DC only; seize FSMO roles; clean up metadata for DCs not being restored; raise the RID pool (Microsoft suggests by 100,000); reset the DC computer account password and the krbtgt password twice each; replace group managed service accounts; validate with repadmin /replsum and dcdiag /v; take fresh backups before redeploying other DCs. See the Identity Recovery Guide.
2. Cloud identity provider: regain control using [two or more] cloud-only emergency access accounts with phishing-resistant authentication, excluded from blocking Conditional Access policies. Microsoft recommends validating these accounts at least every 90 days.
3. PKI: restore the issuing CA from [backup and HSM key material], publish a current CRL, and decide whether certificates issued during the compromise window must be revoked and reissued. [Root CA offline ceremony procedure reference.]
4. Secrets vault: promote the standby or restore from backup. For HashiCorp Vault DR replication, promotion is manual and needs a DR operation token, which otherwise requires a threshold of unseal or recovery keys; hold a pre-generated batch DR operation token and the key holder list in [sealed offline store]. Demote or disable the old primary to avoid two active clusters.
5. Service accounts and secrets: rotate privileged human credentials, service account passwords, API keys and customer-managed encryption keys exposed in the compromise window before reconnecting dependent systems, using the Secrets Rotation Runbook Template. CISA's ransomware guide advises resetting passwords only once the environment has been cleaned and rebuilt, otherwise the new credentials can be stolen again.

4.5 Runbooks

Each system or recovery group must have a runbook with these sections:

1. Owner, deputy, tier, RTO, RPO, and the dependencies that must already be running.
2. Activation criteria and who may authorise failover or rebuild.
3. Access needed: break-glass accounts, vault paths, HSM or key custodians, vendor support contacts and contract numbers.
4. Recovery steps in order, with expected duration and commands or console paths, including the restore source and how to select a clean restore point.
5. Validation: health checks, data integrity checks and reconciliation against [source of truth], with sign-off by the data owner.
6. Reconstitution: failback to primary, resynchronisation, decommissioning temporary resources and removing temporary access.
7. Rollback: how to abandon a failed restore and return to the last known state.

4.6 Activation

1. [CIO or deputy] declares a disaster when [a tier 0 or tier 1 system is expected to exceed its RTO, or the incident lead requires rebuild]. The declaration time starts the RTO clock and must be logged.
2. The recovery bridge must open within [30 minutes] on [out-of-band channel], not on systems that may be down or compromised.
3. Recovery status must be reported to the Crisis Management Team every [2 hours] against the recovery objectives register.

4.7 Testing schedule

Each test must record the actual recovery time and data loss, update section 4.1, and raise actions with owners and dates.

5. Exceptions

1. A system whose demonstrated recovery time or data loss exceeds its RTO or RPO must be recorded as an exception with interim mitigation, a remediation date and an owner, and reported to the business continuity manager.
2. Exceptions must be approved by [CIO] with the business activity owner's acceptance, and expire after no more than [12 months].

6. Compliance and monitoring

1. [IT recovery lead] must report [quarterly] on:
   • Percentage of tier 0 and tier 1 systems recovered within RTO in their last test.
   • Backup success rate and restore test success rate.
   • Gap between demonstrated recovery time and RTO, per tier.
   • Runbooks reviewed in the last 12 months.
   • Emergency access accounts validated in the last 90 days.
   • Open test actions past due.
2. Backup jobs, backup deletion and retention changes, and emergency account sign-ins must generate alerts to [security operations].

7. Review and approval

Implementation guidance

1. Build the dependency map first: trace authentication for your top five systems. Most teams find an undocumented service account, a certificate or a vault lookup that would block start-up.
2. Test identity recovery in isolation: a clean-room AD forest recovery is the single test most likely to expose a gap, and the one most often skipped.
3. Measure, then commit: run each restore once, record the real time, and only then agree the RTO with the business. Do not publish targets you have never met.
4. Check backups are clean before use: CISA recommends offline, encrypted backups tested regularly and rebuilding on a clean recovery network so restored systems are not reinfected; the NCSC advises never having all backups connected at the same time.
5. Roll back safely: keep the original environment powered off and untouched until the restored one is validated, so you can fall back or support forensics.

• EU financial entities: DORA Article 12 requires documented backup and restoration procedures tested periodically, restore systems physically and logically segregated from the source, and recovery time and point objectives for each function; Article 11 requires testing at least yearly. See the DORA Guide.
• Sources: NIST SP 800-34 Rev. 1; Microsoft: AD forest recovery, initial recovery; Microsoft: emergency access accounts; HashiCorp: Vault disaster recovery replication; CISA: #StopRansomware Guide; AWS: disaster recovery options in the cloud.

Related NHI Mgmt Group resources: Business Continuity and Disaster Recovery Guide · Business Continuity Plan Template · Ransomware Response and Recovery Guide · Identity Recovery Guide · Incident Response Plan Template