Restore Test Evidence Report Template
Reports restore test results in a form auditors and insurers accept.
Available soon
- Format
- Word
- Size
- 67 KB
- Length
- 22 pages
- Version
- 1.0
- Updated
What's inside
What changed
- 1.0
Published.
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
About this template
This template is the form in which [[Organisation Name]] reports what a restore test showed. It is for the people who must be told the result, and for those who ask for proof: executive management, the approver, an auditor, an insurer, a customer's assessor and a supervisor. The Restore Testing Methodology sets the rules and the pass criteria. The Restore Test Workbook records each test as it happens. This report turns those records into something a person who was not there can read and trust.
Why a finished backup is not proof
Backup success is not recovery success. A backup job that finished says only that the job wrote something. It says nothing about whether the data restores, whether it restores within the time the service can wait, or whether the copy is one an attacker holding your administrator credentials could not have reached and deleted first. Only a restore shows that the copy is complete, that it opens, that the keys to it still exist, and how long recovery takes. Attackers look for the backups first, so protecting the copies and proving the restore are one piece of work.
So the report does not say that backups ran. It says what was restored, from which copy, how long it took, whether the data was whole and usable, who checked it, and what failed.
What this report leaves to others
The recovery time objective and recovery point objective of each critical service are P22's, set by the service's business owner. This report measures a test against them and never sets one. P22's rule on recovery tests (RR-14) says how often a critical service is recovered; a test that meets both that rule and Restore Testing Methodology's serves both, and one record covers it. P09 runs the incident and checks the backups before a restore (D3, IM-10). A tabletop, a drill or any other exercise under P10 is not a restore test, and this report never counts one (BR-13).
Legal note
This document helps you set up backups, protect them and prove that they restore. It is not legal advice, and following it is not a statement that you comply with NIS2, DORA, the GDPR or any standard. Which backup and testing duties apply to you depends on your sector and your national law: confirm them with counsel or your supervisor.
Implementing Regulation (EU) 2024/2690 binds only the providers its Article 1 names: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online market places, of online search engines and of social networking services platforms, and trust service providers. Other organisations may use its Annex as good practice. Regulation (EU) 2022/2554 binds financial entities. Articles 5 to 15, including 11 and 12, do not apply to the entities of its Article 16(1), which follow Article 16(1)(f) and Articles 39 and 40 of Delegated Regulation (EU) 2024/1774. Articles 7 and 8 of the Delegated Regulation are in its Title II, for the other financial entities. EXAMPLE: the distributor is an important entity under NIS2 in its Member State, and not a financial entity, so DORA's reporting duties do not apply.
How to use this template
The report has nine sections, ES-1 to ES-9, in the order a reader needs them. Each opens with a line naming its ID, what it holds and the rule behind it, then a guidance box on what good looks like. Delete the boxes before the report is issued. Your entries are in [[double brackets]]; beside them, or in rows marked EXAMPLE, is the worked example.
Two kinds of report
Use the same nine sections for either. They differ in what each section covers.
Kind | Covers | How to complete it |
|---|---|---|
Test report | One restore test | Complete every section once. Issue it within the working days BR-17 sets, counted from the test. |
Period report | Every restore test held in a period, such as a quarter or a year | Complete ES-1, ES-2 and ES-5 to ES-8 once for the period. Attach a completed ES-3, ES-4 and ES-9 for each test, which is the test report's own record. Sign ES-9 once more for the period, as the backup owner. |
Issue a test report within 10 working days of the test (BR-17). A period report is the roll-up, for executive management each quarter and for the approver each year (BR-21).
The worked example
EXAMPLE. The example is a period report for wholesale distributor with about 900 staff, three warehouses and an online ordering service, as at 30 Sep 2026. It covers the six tests held from 20 Jan 2026, after its ransomware incident INC-2026-014 (P09). Its Head of Risk, who runs no system in scope, wrote it; the Head of IT owns the backups. Where a section needs the record of one test, the example shows the May restore of the ordering platform (RT-02), the test that missed its recovery time.
The example uses only values the pack records. Where the pack records none, such as the copy's identifier or the date the report was signed, the example keeps a placeholder.
Summary
ES-1 · The counts: tests held, criteria met, findings raised, in the period or for the test · Rule BR-21 · Complete once for the report
This is the page most readers read, and some read nothing else. It answers one question: do our backups restore? Write it last, and keep it to one page.
Guidance — delete before approval
What good looks like. The first sentence states the result and the failures. The counts use the words “of” and the numbers, with every miss named.
The rule behind it. BR-21: “Backup assurance is reported to [[executive management]] each quarter and to [[the approver]] each year, as counts with every gap named: no score and no share of success (P22 RR-20).”
1. Lead with what failed. A reader who stops after the first paragraph must know whether the data restores, in time, from a copy an attacker could not reach.
2. Use counts, such as 3 of 5, and name every test or criterion that missed. Never a share, a grade or a colour (BR-21).
3. Say which tests restored a backup, and what you will do about each failure (ES-7). A supplier's failover, a tabletop or a drill is not a restore test and is never counted here (BR-13).
Count | Your report | EXAMPLE, 20 Jan 2026 to 30 Sep 2026 |
|---|---|---|
Period or test | [[the period, or the test ID and date]] | 20 Jan 2026 to 30 Sep 2026: every test in the register |
Tests held | [[number]] | 6 |
Of those, tests that restored a backup | [[number]] | 5 of 6. RT-01 was a supplier's failover that restores no backup, so it counts for P22 and not here |
Restore tests that passed | [[n of n]] | 3 of 5 |
Restore tests that missed a criterion | [[n of n, and which]] | 2 of 5: RT-02 (TC-03); RT-04 (TC-04) |
Pass criteria met | [[n of n]] | 22 of 24 that applied |
Timed tests within the recovery time objective | [[n of n]] | 1 of 2 |
Timed tests with data lost within the recovery point objective | [[n of n]] | 1 of 2 |
Critical services restored within their recovery time objective in the last 12 months | [[n of n, with the others named]] (the BAM-06 count) | 2 of 5 |
Data sets with no restore test | [[n, and which]] | 2: DS-06, DS-05 (ES-2) |
Findings raised, and open | [[n raised; n open; n High]] | 2 raised, 2 open, 2 High: BF-01, BF-02; none past due |
EXAMPLE. Three of five restore tests passed. The ordering platform's full restore took 96 hours (4 days) against a recovery time objective of 24 hours (1 day) (RT-02), and the warehouse system's restore lost 24 hours of data against a recovery point objective of 4 hours (RT-04). Each has a High finding (ES-7). The foundations have never been restored (ES-2).
Scope
ES-2 · The data sets and services, the test types, the copies used and what was left out · Rule BR-12 · Complete once for the report
A result means little until the reader knows what it covers. This section lists every data set and service the report speaks for, the type of test, the copy used, and what was left out. What is left out is as important as what is in.
Guidance — delete before approval
What good looks like. Every test is listed with its type from the five in Restore Testing Methodology (TT-1 to TT-5). The copy is named, including whether it was the online copy or the immutable or offline one. Anything not restored in the period is listed, with the date it will be.
The rule behind it. BR-12: “Restore tests are of five types: file, item or data set restore (TT-1), full system restore (TT-2), full service end to end (TT-3), bare-metal or clean-room rebuild (TT-4) and cloud or software-as-a-service tenant restore (TT-5). A system is tested by TT-1 and TT-2, a cloud or software-as-a-service tenant by TT-1 and TT-5, and the foundations by TT-1 and TT-4. Data a provider holds with no copy of ours is tested through the provider's own recovery test (P22 RR-14). A test of a higher type counts for the lower types it includes.”
Tests in the report. Add a row for each test; delete the example rows.
Test | Data set and service | Type | Date | What was restored |
|---|---|---|---|---|
EXAMPLE RT-01 | DS-03 Ledgers and payroll records Finance and payroll (CS-04) | TT-5 cloud or software-as-a-service tenant restore Restores no backup | 20 Jan 2026 | The ERP provider's failover between its data centres, with results shared (P06 CON-05). It restores no backup. |
EXAMPLE RT-02 | DS-01 Orders and customer accounts Online ordering (CS-01) | TT-2 full system restore | 20 May 2026 | The ordering platform restored from its nightly backup into the hosting provider's spare environment |
EXAMPLE RT-03 | DS-03 Ledgers and payroll records Finance and payroll (CS-04) | TT-5 cloud or software-as-a-service tenant restore | 15 Jul 2026 | A copy of the ledgers restored by the ERP provider into a test instance, and checked for integrity (P11 MC-35) |
EXAMPLE RT-04 | DS-02 Stock and dispatch records Warehouse dispatch (CS-02) | TT-2 full system restore | 27 Aug 2026 | The warehouse management system restored from backup and checked by the warehouse team |
EXAMPLE RT-05 | DS-04 Email and office documents Customer contact (CS-05) | TT-1 file, item or data set restore | 10 Sep 2026 | A sample of mailboxes restored from the daily export and opened (P11 MC-35) |
EXAMPLE RT-06 | DS-01 Orders and customer accounts Online ordering (CS-01) | TT-1 file, item or data set restore | 17 Sep 2026 | The latest of the ordering platform's monthly restore checks, with the backup provider (P10 EA-04, P11 MC-35): the database restored and checked for integrity |
[[RT-xx]] | [[data set ID and name; service]] | [[TT-1 to TT-5]] | [[YYYY-MM-DD]] | [[what was restored, and from which copy]] |
What was left out
Every data set in the coverage matrix that no restore test reached in the period, and every test type not run:
Left out | Why | When it is planned |
|---|---|---|
EXAMPLE DS-06 Directory, network configuration, backup catalogue and build images | Never restored and checked | RT-2026-10, 18 Nov 2026: the first restore of the directory backup, the network configuration and the backup catalogue, into an isolated environment |
EXAMPLE DS-05 Card payment records | The payment provider holds the data and the distributor keeps no copy, so there is nothing of its own to restore | The provider's own recovery test, RV-2027-01, 13 Jan 2027 |
EXAMPLE TT-3 and TT-4 tests | No full service or rebuild test has been held | RV-2027-03, 17 Feb 2027, the first rebuild; the full service test follows (RV-2027-04, 10 Mar 2027) |
[[data set or type]] | [[why]] | [[test ID and date]] |
Method
ES-3 · The restore environment, the people, the steps followed and the dates · Rule BR-14 · Complete once for each test
This section says how the test was done, so the reader can judge whether it was fair. It names the place the data was restored into, the people and the steps. A reader who knows the method can see what the result does and does not show.
Guidance — delete before approval
What good looks like. The restore went into an isolated place with no route to production for a rebuild. Someone other than the tester checked it. The steps match the nine in Backup Operations & Restore Test Procedure, with a date for each, and any step skipped is said plainly.
The rule behind it. BR-14: “A restore test passes only when every criterion holds: the restore completed, the integrity checks passed, the time achieved was within the service's recovery time objective where the test is timed (P22 RR-04), the data lost was within its recovery point objective, someone other than the tester checked the result with the data owner, and the evidence is recorded. A test that misses a criterion is a finding (BR-18).”
Field | Your report | EXAMPLE: RT-02, Orders and customer accounts |
|---|---|---|
Test ID, type and date | [[RT-xx; TT-n name; YYYY-MM-DD]] | RT-02; TT-2 full system restore; 20 May 2026 |
Data set and service | [[ID, name; service and its recovery time and point objectives]] | DS-01 Orders and customer accounts; Online ordering (CS-01), recovery time objective 24 hours (1 day), recovery point objective 24 hours (1 day) |
What was restored and what was left out | [[scope of the restore]] | The ordering platform restored from its nightly backup into the hosting provider's spare environment. [[what was left out]] |
Restore environment and whether it was isolated | [[where; route to production]] | The hosting provider's spare environment. [[whether it had a route to production]] |
Tester ran the restore | [[Backup administrator]] | IT Operations Manager |
Restore checker independent of the tester | [[Restore checker]] | Information Security Manager |
Data owner confirmed the data is usable | [[Data owner]] | Chief Operating Officer |
Supplier involved | [[supplier and what it did, or None]] | [[the backup service provider's part, if any]] |
Steps followed
The steps of one restore test, as Backup Operations & Restore Test Procedure runs them. Mark each as done, with the date, or say why it was not. The last column shows the criterion or rule each step feeds.
Step | What | Feeds | Done |
|---|---|---|---|
RS-1 | Choose the data set, the type and the date, and tell the data owner and the backup supplier. | BR-13 | [[Yes / No, date]] |
RS-2 | Choose the copy. For a critical data set, alternate between the online copy and the immutable or offline copy. | BR-03 | [[Yes / No, date]] |
RS-3 | Prepare an isolated place to restore into, with no route to production for a rebuild test. | BR-07 | [[Yes / No, date]] |
RS-4 | Check the copy's integrity before restoring it, and note the result. | TC-02 | [[Yes / No, date]] |
RS-5 | Start the clock at the decision to restore. Restore, and stop the clock when the data owner confirms the data is usable. | TC-03 | [[Yes / No, date]] |
RS-6 | Check the restored data against its source or a sample, run the application's own consistency check, and have the data owner open records that matter. | TC-02, TC-05 | [[Yes / No, date]] |
RS-7 | Work out the data lost: the time between the copy used and the point at which the data was last known to be complete. | TC-04 | [[Yes / No, date]] |
RS-8 | Record the evidence, and have the restore checker and the data owner sign. | TC-05, TC-06 | [[Yes / No, date]] |
RS-9 | Clean up the test environment and delete the restored data. Raise a finding for every failed criterion, and an objective gap under P22 RR-15 where the test shows an objective cannot be met. | BR-18 | [[Yes / No, date]] |
EXAMPLE. The worked example does not record each step for RT-02, so the column stays as placeholders. The test's own facts are above.
Evidence list
ES-4 · Each item of evidence, where it is kept and who holds it · Rule BR-17 · Complete once for each test
This is the list a reader asks for when they say “show me”. It names every item of evidence, where it is kept and who holds it, so someone who was not there can find it. The report does not repeat the evidence. It points to it.
Guidance — delete before approval
What good looks like. All eight items are listed. Times come from system logs and not from memory. The place is somewhere that can be reached when the main systems are down, and the holder is a role with a deputy. The list is complete on the day the report is issued.
The rule behind it. BR-17: “Every restore test leaves a record that lets someone who was not there see what was restored, from which copy, when it started and ended, the checks made and who made them. The evidence report is issued within [[10]] working days of the test. Records are kept for at least as long as P22 RR-20 keeps test records: [[3]] years, or longer where law or a contract asks.”
Keep the evidence for at least 3 years, or longer where law or a contract asks.
Evidence | Where kept and who holds it | EXAMPLE: RT-02, Orders and customer accounts |
|---|---|---|
EV-1 The data set, the copy used (identifier, date and time taken) and where it was held | [[place; role]] | DS-01's nightly backup, held in the provider's offsite backup storage. [[copy identifier; date and time taken]] |
EV-2 The result of the integrity check on the copy before the restore | [[place; role]] | Pass. [[tool and log reference]] |
EV-3 Start and end times of the restore, from system logs rather than from memory | [[place; role]] | 96 hours (4 days) from the decision to restore to the data owner's confirmation. [[log extract with start and end]] |
EV-4 What was restored, with counts or sizes, and what it was compared with | [[place; role]] | [[counts or sizes; the source or sample compared with]] |
EV-5 The result of the application's own consistency check, and the records the data owner opened | [[place; role]] | [[the consistency check's result]]. Records opened and confirmed by Chief Operating Officer: [[which records]] |
EV-6 The data lost, worked out from the copy's time | [[place; role]] | 24 hours, against a recovery point objective of 24 hours |
EV-7 Who ran the restore, who checked it, and who confirmed it for the data owner | [[place; role]] | Ran: IT Operations Manager. Checked: Information Security Manager. Confirmed: Chief Operating Officer |
EV-8 Every failed criterion, with the finding raised for it | [[place; role]] | TC-03 not met; finding BF-01 (ES-7) |
EXAMPLE. The worked example does not record the copy's identifier or time, the log extracts, the counts restored or the dates the report was issued and signed, so those rows stay as placeholders.
Results by criterion
ES-5 · Each pass criterion, met or not met, with the measurement · Rule BR-14 · Complete once for the report
A restore test passes only when every criterion holds (BR-14). This section shows each criterion, whether it was met, and the measurement behind the answer. A single missed criterion fails the test, and that is the first thing a reader looks for.
Guidance — delete before approval
What good looks like. Each criterion has a result and a measurement, not a general remark. A criterion that did not apply, such as time for an untimed test, says “Not applicable” and why. A missed criterion links to a finding in ES-7.
The rule behind it. BR-14: “A restore test passes only when every criterion holds: the restore completed, the integrity checks passed, the time achieved was within the service's recovery time objective where the test is timed (P22 RR-04), the data lost was within its recovery point objective, someone other than the tester checked the result with the data owner, and the evidence is recorded. A test that misses a criterion is a finding (BR-18).”
A test is passed or failed. Do not average the criteria, and do not write that a test “mostly” passed.
The criteria for one test
Field | Your report | EXAMPLE: RT-02, Orders and customer accounts |
|---|---|---|
TC-01 Restore completed | [[Met / Not met / Not applicable]]; [[measurement]] | Met. Everything in scope was restored |
TC-02 Integrity checks passed | [[Met / Not met / Not applicable]]; [[measurement]] | Met. Integrity check on the copy and on the restored data: pass |
TC-03 Time within the recovery time objective | [[Met / Not met / Not applicable]]; [[measurement]] | Not met.** 96 hours (4 days) achieved against 24 hours (1 day) |
TC-04 Data lost within the recovery point objective | [[Met / Not met / Not applicable]]; [[measurement]] | Met. 24 hours lost against 24 hours |
TC-05 Checked independently and confirmed | [[Met / Not met / Not applicable]]; [[measurement]] | Met. Tested by IT Operations Manager, checked by Information Security Manager, confirmed by Chief Operating Officer |
TC-06 Evidence recorded | [[Met / Not met / Not applicable]]; [[measurement]] | Met. The evidence is recorded (ES-4) |
Result the test passes only if no criterion is not met | [[Passed / Failed]] | Failed (TC-03 not met) |
The criteria across the report's tests
For a period report, show every restore test in one grid. A test that restored no backup (here RT-01) has no row, and ES-2 says why.
Criterion | EXAMPLE RT-02 | EXAMPLE RT-03 | EXAMPLE RT-04 | EXAMPLE RT-05 | EXAMPLE RT-06 |
|---|---|---|---|---|---|
TC-01 Restore completed | Met | Met | Met | Met | Met |
TC-02 Integrity checks passed | Met | Met | Met | Met | Met |
TC-03 Time within the recovery time objective | Not met | Not applicable | Met | Not applicable | Not applicable |
TC-04 Data lost within the recovery point objective | Met | Not applicable | Not met | Not applicable | Not applicable |
TC-05 Checked independently and confirmed | Met | Met | Met | Met | Met |
TC-06 Evidence recorded | Met | Met | Met | Met | Met |
Result | Failed | Passed | Failed | Passed | Passed |
EXAMPLE. 22 of the 24 criteria that applied were met. The two that were not each failed a whole test. RT-03, RT-05 and RT-06 were not timed, so TC-03 and TC-04 do not apply to them.
Times against objectives
ES-6 · The restore time, the service's recovery time objective and the cyber recovery time, side by side · Rule BR-15 · Complete once for the report
A restore in normal conditions shows how long it takes to restore a backup with the tools you have. It does not show how long recovery takes after a destructive attack, when the foundations must be rebuilt first. Show both times, side by side, for every critical service the tests touch.
Guidance — delete before approval
What good looks like. For each critical service: the recovery time objective, the time the last test achieved, and the cyber recovery time from P22's matrix. A service never tested says “Not tested”, not a guess. Where a rebuild test (TT-4) has been held, its result replaces the estimate.
The rule behind it. BR-15: “A restore in normal conditions shows the restore time. It does not show the cyber recovery time, which P22 works out with the foundations rebuilt first (P22 RR-07, MX-05). A rebuild test (TT-4) measures the foundations' rebuild, and its result replaces the estimate in P22's matrix. Reports show both times side by side.”
Take the objectives and the cyber recovery time from P22's objectives matrix (MX-05). This report copies them and sets none.
Service | Recovery time objective | Time the last test achieved | Cyber recovery time | P22 status |
|---|---|---|---|---|
EXAMPLE Online ordering CS-01 | 24 hours | 96 hours (20 May 2026): missed | 108 hours: missed | Not achievable |
EXAMPLE Warehouse dispatch CS-02 | 8 hours | 5 hours (27 Aug 2026): within | 17 hours: missed | Needs its workaround |
EXAMPLE Payments CS-03 | 24 hours | Not tested | 0 hours: no system of ours is rebuilt (P22 MX-05) | Not proven |
EXAMPLE Finance and payroll CS-04 | 48 hours | 3 hours (20 Jan 2026): within | 12 hours: within | Achievable |
EXAMPLE Customer contact CS-05 | 24 hours | Not tested | 12 hours: within | Not proven |
[[service]] | [[hours]] | [[hours (date); within or missed]] | [[hours; measured or estimated]] | [[status]] |
EXAMPLE. The ordering platform took 96 hours to restore with trusted tools in May, and about 108 hours after a destructive attack, because the foundations come first. Both are beyond its recovery time objective of 24 hours, and beyond its maximum tolerable downtime of 48 hours (P05 R-01). The finance and payroll figure of 3 hours is the ERP provider's failover (RT-01), which restores no backup, so it is the provider's recovery time and not a restore time of ours. The warehouse system's 5 hours is within its objective of 8 hours, but its cyber recovery time of 17 hours is not.
Findings
ES-7 · Every finding with its severity, owner, due date and link to any objective gap · Rule BR-18 · Complete once for the report
Every missed criterion is a finding with an owner, a severity and a due date (BR-18). This section lists the findings the tests raised, so the reader sees that a failure leads to a fix and not a shrug.
Guidance — delete before approval
What good looks like. Each finding says what failed in plain words, names one owner, takes its severity from the table below, and has a date that follows the severity or the plan that fixes it. A finding is closed only when a retest or new evidence shows the fix works.
The rule behind it. BR-18: “Every failed criterion, failed check, unmet protection control and repeated job failure is a finding with an owner, a severity and a due date. The owner agrees a plan within [[10]] working days. A High finding is fixed within [[90]] days, a Medium finding within [[180]] days and a Low finding within [[365]] days. A finding that is also an objective gap is linked to it and keeps the date P22 RR-15 sets. A finding closes only when a retest or new evidence shows that the fix works. A High finding is told to the owner of the risk it bears on, and the risk is reassessed (P05 RM-10).”
Severity and the days allowed, from the rule:
Severity | Meaning | Days to a fix |
|---|---|---|
High | A critical data set cannot be restored, or not within its recovery time or recovery point, or has no copy an attacker with administrator credentials could not reach. | 90 |
Medium | A weakness that other protection backs up. | 180 |
Low | An improvement, tracked to the next review. | 365 |
Findings raised by the tests in this report. Statuses are “Open”, “Fixed, awaiting retest” and “Closed”.
Finding | What failed | Fix and retest | Owner and dates | Linked |
|---|---|---|---|---|
EXAMPLE BF-01 High | The ordering platform took 4 days to restore in the May full restore test. Its recovery time objective is 24 hours. Raised by RT-02 TC-03 | Rebuild the platform's recovery (P05 TA-01), then retest end to end (RV-2027-04) | Head of IT Found 30 Sep 2026 Plan by 14 Oct 2026 Due 15 Dec 2026 Open | P22 OG-01; P05 TA-01; P12 GAP-03 |
EXAMPLE BF-02 High | The warehouse management system's August restore lost 24 hours of data. Dispatch can lose at most 4 hours. Raised by RT-04 TC-04, DS-02 BC-02 | Back up the warehouse database every 4 hours (P22 OG-05), then retest the recovery point (RT-2026-11) | Head of IT Found 30 Sep 2026 Plan by 14 Oct 2026 Due 15 Dec 2026 Open | P22 OG-05 |
[[BF-xx]] [[severity]] | [[what failed; the criterion]] | [[the fix, and the retest that proves it]] | [[owner]] [[found; plan by; due; status]] | [[objective gap or action it is linked to]] |
EXAMPLE. Both findings are High, because a critical service could not be restored within its recovery time or its recovery point. Each is linked to the plan that fixes it and keeps that plan's date, as BR-18 asks. Neither is past due at 30 Sep 2026. The owner of each agrees a plan within 10 working days of the finding, by 14 Oct 2026.
Limits of the test
ES-8 · What the test did not show, such as a service restored in a spare environment and not in production · Rule BR-14 · Complete once for the report
No test shows everything. This section says what yours did not show. It is the section that makes the rest believable, because a report that claims no limits is one a careful reader will doubt.
Guidance — delete before approval
What good looks like. Short, specific and honest. Each limit says what the reader might wrongly conclude, and what would remove the doubt. A limit is not an excuse for a failure, and it does not replace a finding.
The rule behind it. BR-14: “A restore test passes only when every criterion holds: the restore completed, the integrity checks passed, the time achieved was within the service's recovery time objective where the test is timed (P22 RR-04), the data lost was within its recovery point objective, someone other than the tester checked the result with the data owner, and the evidence is recorded. A test that misses a criterion is a finding (BR-18).”
Ask | Why it matters | Your report |
|---|---|---|
L-1 Where was it restored? | A restore into a spare environment shows the data comes back. It does not show that the live service would start, or that production tools and accounts would be there after an attack (BR-15). | [[your answer]] |
L-2 Which copy was used? | A restore from the online copy says nothing about the immutable or offline copy, and the reverse (BR-03). Name the copy, and the one you did not test. | [[your answer]] |
L-3 Was it timed? | Only a timed test shows the restore time (TC-03). A file or sample restore does not show how long a whole system takes. | [[your answer]] |
L-4 What did it not cover? | Data sets with no restore in the period, the foundations, a provider's copy that is not yours, and any type of test not run. | [[your answer]] |
L-5 What did it rely on? | A supplier's help, a key kept on a system that was up, or a person who was on hand. If any of these would be missing in a real recovery, say so. | [[your answer]] |
L-6 Who checked it, and how independent were they? | A restore checked by the person who ran it is weak evidence (TC-05). Say what independence you had. | [[your answer]] |
EXAMPLE: limits of the distributor's tests
Limit | What a reader might wrongly conclude | What would remove the doubt |
|---|---|---|
RT-02 restored the ordering platform into the hosting provider's spare environment, with trusted tools | That the platform would come back in 96 hours after a destructive attack | A rebuild test (RV-2027-04, 10 Mar 2027) on the rebuilt set-up |
RT-03, RT-05 and RT-06 were not timed | That the services restore within their recovery times | A timed system restore (TT-2) of each, at the interval the methodology sets |
RT-01 was the ERP provider's failover | That the distributor's own copy of the ledgers restores | RT-03 restored a copy of the ledgers in a test instance; RT-2026-07 repeats it on 13 Oct 2026 |
DS-06, the directory, network configuration and backup catalogue, was never restored | That a rebuild of the foundations would work | RT-2026-10, 18 Nov 2026, then RV-2027-03 |
The backup service provider's console, approval rules and encryption have not been checked (BP-03, BP-04, BP-10) | That a restore from the provider's copies shows the copies are safe from deletion | The provider's assessment, planned for 3 Nov 2026 (P06 SUP-011) |
[[Which copy each test used, online or offline: the worked example does not say]] | That the immutable or offline copy restores | Alternate the copy at each test (RS-2) and record which was used |
Sign-off
ES-9 · The tester, the restore checker, the data owner and the backup owner, with dates · Rule BR-14 · Complete once for each test, and once for the period report
A signature says a named person stands behind a statement. The tester, the restore checker, the data owner and the backup owner each sign their own, so nobody signs for someone else, and nobody marks their own work.
Guidance — delete before approval
What good looks like. Four roles, each signing with a date. The restore checker is not the tester (TC-05); in a small team one person may hold the other roles, and the report says so. The backup owner signs last, after reading the findings. A report with fewer than four signatures says why, and who will sign.
The rule behind it. BR-14: “A restore test passes only when every criterion holds: the restore completed, the integrity checks passed, the time achieved was within the service's recovery time objective where the test is timed (P22 RR-04), the data lost was within its recovery point objective, someone other than the tester checked the result with the data owner, and the evidence is recorded. A test that misses a criterion is a finding (BR-18).”
Role | Statement | Name, signature and date | EXAMPLE: RT-02, Orders and customer accounts |
|---|---|---|---|
Backup administrator | I ran the restore as recorded in this report, and the times and results are from the logs. | [[name]] [[signature]] [[YYYY-MM-DD]] | IT Operations Manager |
Restore checker | I checked the restored data against its source or a sample, independently of the person who ran the restore. | [[name]] [[signature]] [[YYYY-MM-DD]] | Information Security Manager |
Data owner | I opened records that matter, and I confirm that the data is usable, or I have named what is not. | [[name]] [[signature]] [[YYYY-MM-DD]] | Chief Operating Officer |
Backup owner | I have read this report. I accept its findings and I am accountable for fixing them. | [[name]] [[signature]] [[YYYY-MM-DD]] | Head of IT |
EXAMPLE. The tester and the restore checker are different people, as TC-05 asks. The signature dates are placeholders, because the worked example gives none. A test report for RT-02 was due by 3 Jun 2026, 10 working days after 20 May 2026; the example does not record when it was issued.
For a period report, the backup owner signs once more for the period and the resilience coordinator adds the date it went to executive management and to the approver.
Giving the report to an auditor or an insurer
An auditor, an insurer or a customer's assessor asks much the same questions. Answer them in the report, and point to where. A report that answers these in order is quick to read, and quick to trust.
Question a reader asks | Where this report answers it |
|---|---|
What was restored, and from which copy? | ES-2 and ES-4 (EV-1, EV-4) |
When did it start and end, and how long did it take? | ES-4 (EV-3) and ES-6 |
Was the copy whole before the restore, and the data right after it? | ES-5 (TC-02) and ES-4 (EV-2, EV-5) |
Was the time within what the service can wait, and the data lost within what it can lose? | ES-5 (TC-03, TC-04) and ES-6 |
Who checked the result, and was it someone other than the tester? | ES-5 (TC-05) and ES-9 |
What failed, who owns it and when is it fixed? | ES-7 |
What does this report not show? | ES-8 |
Handling the report
- Keep the signed copy unchanged. If something is wrong, issue a new version that says what changed and why, and keep both.
- Classify it. A report that names weak backups is information an attacker would value. Give it the classification you give your other security assessments, and share it under the terms you use for them.
- Share the report, and keep the evidence ready. The evidence list (ES-4) says where each item is kept. Give the underlying logs and screenshots when someone asks for them, and name who can find them.
- Keep it for as long as BR-17 asks. Records are kept for at least the number of years in the rule, or longer where law or a contract asks.
The report is evidence, not a claim of compliance. Whether a particular auditor, insurer or supervisor accepts it is theirs to decide, and the legal note above applies. Do not describe the report as meeting any law or standard.
Adapting this template
Guidance — delete before approval
Small organisation: keep all nine sections, each short, and one test report a quarter. If you have one IT person, the restore checker can be someone from another team or the supplier, as long as they are not the person who ran the restore (TC-05).
Guidance — delete before approval
A supplier runs the backup: ask the supplier for its own restore test results and attach them to ES-4. The report is still yours. Sign it, say in ES-8 what you relied on the supplier for, and record the supplier's restore time against the service's objective (BR-20).
Guidance — delete before approval
Regulated entity: whether the next two notes apply depends on whether the law binds you. Confirm that with counsel or your supervisor before you rely on either.
Guidance — delete before approval
A provider named in NIS2 Implementing Regulation Article 1: Annex point 4.2.6 asks for regular testing of the recovery of backup copies, documented results and corrective action where needed. ES-5 to ES-8 hold each of those. Others may use the point as good practice.
Guidance — delete before approval
A financial entity under DORA: keep the test results, analyse the deficiencies and report them to the management body (Delegated Regulation Article 40(3), for the entities of Article 16(1)). ES-7 and ES-9 show those steps. Other financial entities follow Article 12 of the Regulation. Confirm which applies to you with counsel.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2022/2554 (DORA) and Delegated Regulation (EU) 2024/1774; Regulation (EU) 2016/679 (GDPR); NIST SP 800-209 (October 2020); NCSC (UK) blog post "Offline backups in an online world" (2019).
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 8.13 — Information backup | The whole template: a record that backups were restored and checked |
NIST CSF 2.0 | RC.RP-05 — “The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed” | ES-4 to ES-6: integrity of restored data verified and normal status confirmed |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(c) — “business continuity, such as backup management and disaster recovery, and crisis management” | The whole template: backup management as a continuity measure |
NIS2 — Implementing Regulation (EU) 2024/2690 | Article 1 — lays down the technical and methodological requirements of the Article 21(2) measures, and further specifies when an incident is significant, for DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers | Legal note: who the Annex binds |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.2.6 — “The relevant entities shall carry out regular testing of the recovery of backup copies and redundancies to ensure that, in recovery conditions, they can be relied upon and cover the copies, processes and knowledge to perform an effective recovery. The relevant entities shall document the results of the tests and, where needed, take corrective action.” | ES-2 to ES-8: documented results and corrective action |
DORA — Regulation (EU) 2022/2554 | Article 12(2) — backup systems can be activated in accordance with the backup policies and the restoration and recovery procedures; “The activation of backup systems shall not jeopardise the security of the network and information systems or the availability, authenticity, integrity or confidentiality of data. Testing of the backup procedures and restoration and recovery procedures and methods shall be undertaken periodically.” | ES-3, ES-5: periodic testing of restoration |
DORA — Regulation (EU) 2022/2554 | Article 12(7) — “When recovering from an ICT-related incident, financial entities shall perform necessary checks, including any multiple checks and reconciliations, in order to ensure that the highest level of data integrity is maintained.” The checks also apply when reconstructing data from external stakeholders, so that all data is consistent between systems | ES-5 (TC-02), ES-4 (EV-5): checks that data is whole |
DORA — Delegated Regulation (EU) 2024/1774 | Article 40(3) — the results of the testing are documented, and identified deficiencies “shall be analysed, addressed, and reported to the management body” | ES-5, ES-7: documented results and deficiencies reported |
GDPR — Regulation (EU) 2016/679 | Article 32(1)(c) — the security measures include, as appropriate, “the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident” | ES-6: restoring access to data in good time |
GDPR — Regulation (EU) 2016/679 | Article 32(1)(d) — the security measures include, as appropriate, “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing” | The whole template: a regular test with a record |
NIST SP 800-209 (October 2020) | Section 4.8, RA-SS-R5 — “Perform a periodic test restore to ensure that it is completed successfully and that it meets the required timeframe.” | ES-5, ES-6: a test restore against the required time |
ISO/IEC 27001 references name the clause or control this document relates to, by number and title only. They do not say that meeting one meets any other framework's requirement.
Definitions
Term | Meaning in this report |
|---|---|
Critical service | A service the organisation delivers whose disruption beyond its maximum tolerable downtime would cause Severe harm on the risk register's impact scale (RR-01). It is a business service, such as online ordering, not a system. |
Cyber recovery time | The time a service would take to come back after a destructive attack: the foundations' rebuild, if the service depends on them, plus the slowest of the systems the organisation restores itself (MX-05). |
Data owner | The manager accountable for a data set. For the data a critical service needs, this is the service's business owner (P22 RR-02). |
Data set | A body of data that is backed up and restored as a unit, such as one database, one file share or one mail tenant. Each data set has an owner, a class and a place in the coverage matrix (BR-01). |
Finding | A failed pass criterion, a failed check, an unmet protection control or a repeated job failure, with an owner, a severity and a due date (BR-18). |
Immutable copy | A copy that nobody can change or delete, with administrator credentials or otherwise, until its retention lock expires (BR-08). |
Integrity check | A check that a copy is whole before it is restored, and that restored data matches its source or a sample of it, with the application's own consistency check and the data owner opening records that matter (BR-16). |
Offline copy | A copy that is disconnected from every network except while it is written or restored (BR-07). |
Recovery point objective (RPO) | the most data, measured in time, the service can lose. The backup interval of every data set it needs must be no longer (RR-04, MX-03). |
Recovery time objective (RTO) | the time within which the service must be back, counted from the decision to recover it. Always shorter than the MTD (RR-04). |
Restore test | A test that restores data from a backup and checks the result against the pass criteria (BR-14). A tabletop, a drill or any other exercise is not a restore test (P22 RR-14). |
Unverified copy | A copy of a critical data set that has not been restored and checked for integrity within the restore check period for its class (BR-04). |