When data is missing, a data recovery plan tells a named person which data and systems it covers. It also says how much loss and how long a wait each owner accepts, and who restores what in which order. Instead of a template to fill in, this article scores the plan you hold today. The recovery time objective for each system stays the business’s own decision, while the checks below show whether anyone has written it down. It is the review before a loss. Our guides on data loss causes and on getting data back also cover the causes and the steps. Our Recover from Data Loss use case covers the wider help.
Last reviewed 2026-11-02 by Manish Sharma.
What a Data Recovery Plan Is, and What Scoring It Shows
A plan is a document that a named person can pick up when data is missing. You judge it by whether anyone has proved it. In our working distinction, which is not a standard, a data recovery plan covers losing data for any cause. In contrast, a disaster recovery plan covers losing a site or a whole environment. For where that plan sits beside the wider continuity plan, see our guide on who owns each plan and where the line falls. For the ways data goes missing in the first place, see what removes, damages or locks away business data.
At least one vendor checklist page we read on 2 November 2026 ran plan checks and recovery steps together. This article keeps them apart, but leaves the steps to the sibling guide.
Ready.gov’s recovery guidance sets IT recovery priorities from the business impact analysis. It also says the recovery time of an IT resource should match the recovery time objective of the function that depends on it. The Ready.gov recovery planning page is a useful companion to the checks here.
Scoring shows where a plan exists on paper but nobody has proved it. However, it does not show that a restore will succeed, and the last section says why.
Recovery Time Objective and Recovery Point Objective, Set by the Business
The recovery time objective (RTO) is how long the business accepts waiting after an interruption. The recovery point objective (RPO) is how much recent data it accepts losing. Both are set by the organisation, as the AWS Well-Architected Framework defines them. It describes RTO as the longest acceptable delay between an interruption and restoration, and RPO as the longest acceptable time since the last recovery point.
AWS also separates RTO from mean time to recover (MTTR). RTO is a target for a single event, while MTTR is an average over several. Keep an MTTR figure out of the RTO column, because MTTR is an average over several events and RTO is a target for one.
The owner of the business function sets both numbers in the data recovery plan. IT says what the current setup can meet, while the gap is the finding. That is Signisys’ working rule.
The numbers below are invented for illustration and are neither a recommendation nor a norm:
| System | Data age the owner accepts | Wait the owner accepts | Last measured restore |
|---|---|---|---|
| The owner accepts losing up to 4 hours of recent mail. | The owner accepts 4 hours without mail. | The last trial restore took 40 minutes, less than the 4 hours the owner accepts. | |
| Finance application | The owner accepts losing up to 1 hour of entries. | The owner accepts 4 hours of downtime. | The last trial restore took 6 hours, which is 2 hours longer than the owner accepts. |
A Data Recovery Plan Compares the Agreed Wait with the Measured One
The table shows why a plan needs both columns: the agreed wait is a decision, while the measured restore is a fact. Checks 8 and 15 below also put the two side by side.
Marking the Checks: Proven, Partly Proven or Not Proven
Each check takes one of three marks. Proven earns 2 points when every system in scope meets the pass test and a dated file backs it. Partly proven earns 1 point if some systems meet the test, or if they meet it but the file is missing. Not proven earns 0 when the test fails or nobody can show it. Mark a claim Not proven when nobody can back it with a dated file, whatever the team believes.
There are 16 checks, so the maximum is 32 points. If a check does not apply to this firm, strike it out, take its 2 points from the maximum of 32, and note why.
Where a test says “sample”, draw the sample from the system list by a written method, such as every fifth entry. A second reviewer then gets the same sample.
This checklist sets no pass mark, because any cut-off would be invented. Read the total as a progress figure only, and look at where the Not proven marks cluster. In our view, four Not proven marks in one group say more than a few spread across all four.
Here is an illustrative example for check 15. Mail has a trial restore on a stated date, 40 minutes measured and the file kept, so it scores Proven. The finance application has a trial restore planned but not yet run, so it scores Not proven.
Key Takeaway Judge the plan by its proof, let the business own the targets, and read the lowest marks before the total.
Data Recovery Plan Checks 1 to 4: What the Plan Covers
A plan can only protect what it lists, so the first group asks what is on the list and who answers for it. Each row is a test that you run on your own documents.
| Check | Evidence to collect | Passes when |
|---|---|---|
| 1. Every system and data store has a named owner. | The system list shows each owner and a date. | Every row holds a person’s name, not a team alias; otherwise a restore request has nobody to approve it. |
| 2. SaaS and cloud data sit on the same list as servers and laptops. | The list shows mail, shared drives, line-of-business applications and cloud storage, with where each lives. | No known data store is missing, including those a provider holds. Read your own provider’s documentation for what it keeps and for how long. |
| 3. The plan lists what it leaves out. | The data owner signs an exclusion list. | Each exclusion carries a date and, once the owner has signed, the owner’s initials. |
| 4. The plan names the kind of copy each system relies on. | One line per system says which copy it is. | Every system has a line, but whether it is the right kind is a separate question that the guide on which kind of copy to restore from covers. |
Data Recovery Plan Checks 5 to 8: The Targets
This group turns the plan from a list into targets. Without agreed figures, a plan has nothing to measure a restore against. The recovery time objective in check 6 is the figure that the people waiting care about.
| Check | Evidence to collect | Passes when |
|---|---|---|
| 5. The owner agrees a data-age target (RPO) per system. | The owner’s agreement is on file in writing. | There is a figure per system, in hours or days, that the firm labels as its own. |
| 6. The owner agrees a recovery time objective (RTO) per system. | The owner’s agreement is on file in writing. | There is a figure per system, and “as fast as possible” is not a figure. |
| 7. The plan writes down the restore order and dependencies. | A numbered order is on file. | Where system B needs system A first, A appears before B. |
| 8. Someone compares the agreed recovery time objective with the measured time. | A table sets each target against the last measured restore, such as the one above. | Every gap has an owner, and the business owner either accepts each open gap in writing or asks for a change. |
Data Recovery Plan Checks 9 to 12: Who Does What
A plan that names no people stays a document. This group asks whether the right person can act on the day and can find the instructions.
| Check | Evidence to collect | Passes when |
|---|---|---|
| 9. Named restorers have a cover person. | A roster shows two names per class of system. | The cover person has the access, confirmed on a stated date. |
| 10. The plan writes down a request and approval route. | One page says who asks, who approves, who restores and who tells users. | Someone outside the IT team can find it and follow it. |
| 11. The plan and contact list still open when the main systems are down. | A copy exists, the plan states where it lives, and it does not depend on the affected systems. | Someone opens it from a personal device while the reviewer watches. |
| 12. Someone owns the alerts from copy jobs. | The name of the person who reads failure alerts, and one dated alert that person handled. | The name and a dated example both exist; if either is missing, the mark falls. |
The Improve Backup Reliability and Stop Failures use case covers how reliably copies run.
Data Recovery Plan Checks 13 to 16: History, Proof and Upkeep
The last group asks whether the plan reaches far enough back, whether anyone has proved it and whether it stays current.
| Check | Evidence to collect | Passes when |
|---|---|---|
| 13. Earlier versions reach back further than a mistake takes to surface. | The retention setting for each class of system, and how long a late-noticed deletion or corruption has taken to surface in this firm. | The retention setting is longer than the surfacing time. Read each provider’s own documentation for the setting. |
| 14. A leaver’s data has a written rule. | The leaver procedure names the mailbox and files. | It says who decides and for how long, and one recent leaver’s record shows whether the team followed it. |
| 15. A dated trial restore exists for each class of system. | A log shows the date, what the team restored, the measured time and who checked the result. | Each class has an entry, and the measured time feeds check 8. |
| 16. The team reviews the plan after a change, and the plan points to where it covers the attack case. | A review log and a pointer in the plan. | The last review is later than the last major system change, and the data recovery plan points to its document for the ransomware case. |
Ready.gov lists NIST SP 800-84, its guide to test, training and exercise programmes, among its resources. It is a place to look when you design the trial restores in check 15. This article gives no ransomware steps.
Key Takeaway A pass test passes only when you can show the dated file behind it.
From Marks to a Work List: What to Fix First
Work the zeros in a set order, which is Signisys’ working order and not a standard. Any Not proven in checks 1 and 2 comes first, because a system missing from the list has no plan to follow. Checks 5, 6 and 8 come after that, because they set the targets and show the gap. Check 15 follows as the proof, and the rest follow by group.
Before anyone considers spend, put each open recovery time objective or RPO gap in front of its business owner. The owner accepts the gap in writing or asks for a change, and you fill in the table below for your own plan.
| Mark | What to do | Who and when |
|---|---|---|
| If check 1 or 2 is Not proven | Add the missing system or owner to the list. | A named person, by your date. |
| If check 5 or 6 is Not proven | Ask the business owner for a figure in writing. | A named person, by your date. |
| If check 8 is Not proven | Measure a restore and record the gap. | A named person, by your date. |
| If check 15 is Not proven | Schedule a dated trial restore for the class of system. | A named person, by your date. |
| If a check is Partly proven | Find the missing file or the uncovered systems. | A named person, by your date. |
Turning the data recovery plan marks into work takes four moves.
Gather the system list and every agreed figure.
Give each of the 16 checks 2, 1 or 0.
Group the Not proven marks, then apply the order above.
Put one owner and one date on each.
Where a Self-Review Runs Out
A self-review covers the documents, and outside help makes sense in four cases. Nobody can run a trial restore without touching live data. Owners will not set figures. The system list is incomplete. Regulated data is in scope, in which case you check your obligations with your adviser, as this article names no India or GCC rule.
A full score does not prove a restore will work on the day. Signisys offers this kind of review, and the text below the box says what it covers.
The review looks at your lists and agreed figures, and Signisys agrees with you first whether it includes a trial restore. We promise no recovery, and this page states no price. See Recover from Data Loss, the Data Protection and Cyber Recovery solution and our cybersecurity services.
Left Out on Purpose
This checklist does not cover causes of loss, the steps after a loss, the choice of copy type, job health and the full backup review, or ransomware controls. It also leaves out access and encryption of data, staff training, replacement hardware and installation copies, paper records, and checksum checks on restored data. Still, the pages linked above cover the nearest of these. To score the wider plan that keeps the business running, see our continuity plan review.
Frequently Asked Questions
What should a data recovery plan include?
How is a data recovery plan different from a disaster recovery plan?
Who should own the data recovery plan?
What should the recovery time objective be?
Does the plan still matter if our data is in Microsoft 365 or another cloud service?
How do I know the plan would work without restoring everything?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.