An IT disaster recovery plan should restore a usable business activity, not just recover files. For each essential application, record who makes the decision, the target recovery time, the dependencies and the business test required before reopening. These templates help you prepare that work with your IT provider; downloading them does not demonstrate recovery capability.
What belongs in the plan
This guide covers IT recovery supporting business operations. It complements arrangements for working during an outage: accepting orders by phone, postponing a delivery or keeping a temporary transaction register. The business owner sets priorities and acceptable interruption. Your IT provider checks which resources are needed to meet them.
The French ANSSI control reference connects recovery planning with acceptable downtime and data loss. Our original template brings together scope, contacts, application priorities, dependencies, recovery steps and an exercise report. Adapt it to your organisation, then test it.
Start with an activity and trace its dependencies
“The server must restart within four hours” does not say what users can do afterwards. A better acceptance criterion is: “The order team can retrieve confirmed orders and save a new order.” That criterion prevents a running virtual machine from being mistaken for a recovered service.
Recover a complete business activity
Fictional sequence to adapt to your actual dependencies.
- 01Access
Network and identity available in the recovery environment.
- 02Restore
Consistent database and application, with licences and configuration.
- 03Validate
The business retrieves an order and saves a new one.
- 04Decide
Reconcile outage transactions and authorise reopening.
In a fictional example, order entry depends on networking, identity, a database and the sales application. Restored files are insufficient if nobody can sign in. Include licences, administrative access, available storage and the workstation used to coordinate recovery. The actual sequence depends on your architecture; the illustration is not a universal runbook.
Separate the approved target from the result demonstrated in the latest exercise. With no evidence, record “not tested”. Our restore-testing guide explains RTO and RPO: the recovery-time target and the maximum acceptable age of the recovered data point.
A worked example that exposes a gap
The following training scenario is entirely fictional. A small business loses its sales application at 09:00. Its recovery target is four hours, with a maximum data recovery point age of two hours. In the simulated exercise report, the business acceptance test passes at 13:45 and the latest usable backup is from 06:00.
| Check | Fictional target | Simulated result | Finding |
|---|---|---|---|
| Usable recovery after the 09:00 outage | No more than 4 hours | 4 hours 45 minutes | 45 minutes late |
| Recovered data point age at 09:00 | No more than 2 hours | 3 hours | 1 hour beyond target |
| Orders received during the outage | All reconciled | Temporary register awaiting entry and checking | Controlled reopening needed |
This is deliberately not a successful recovery result. Investigate the delay, review the backup chain or ask the business owner to reconsider the objectives. Editing the targets afterwards to conceal the gap would make the report misleading.
The RPO comparison does not establish that three hours of orders are permanently lost. Application logs or the temporary register may support further recovery; that requires a separate check.
Keep recovery resources available during the outage
A plan stored only on the failed file share will be unavailable when needed. Keep a protected copy accessible independently of the affected system, an emergency contact list and an alternative communication channel. ANSSI's Preparing remediation guide covers these preparations and the limitations of plans designed only for ordinary outages.
Record where emergency access is held, who can release it and how its use is logged. Do not put passwords or recovery codes in the plan. Have authorised staff test the access process before the exercise and identify a deputy.
Where compromise is suspected, coordinate recovery with containment and investigation. Restoring into an environment that remains compromised can restart the incident. The incident-response lead and business owner must agree the conditions for reopening.
Test before committing to a recovery time
Begin with a tabletop exercise: the main decision-maker is absent, email is down and the provider must locate contacts and dependencies. Then arrange an authorised restore into an isolated environment without overwriting live data. These exercises answer different questions.
The NIST SP 800-34 guide covers recovery preparation and validation. It is a methodology reference for US federal information systems, not a general compliance requirement for small businesses.
Record timestamps, the backup point used, business tests, errors, deviations and corrective actions with owners. Restoring a few files does not validate recovery of the whole application. The 3-2-1 backup guide addresses the copies; your recovery plan connects them to people and systems.
Agree reopening and the next review
Before users return, obtain business acceptance, reconcile transactions recorded during the outage and define post-recovery monitoring. If a return to the previous system remains possible, state how new writes will be preserved. Otherwise, a technically successful recovery can still lose data during rollback.
Choose one priority application, complete its worksheet and ask your provider to check its dependencies. Review after significant changes, incidents or exercises. Our infrastructure services can help scope the inventory, backups and testing; recovery times must be established in your own environment.