Restore Test Workbook
Records each restore test's scope, timing, integrity checks and achieved recovery time.
Available soon
- Format
- Excel
- Size
- 97 KB
- Length
- 12 sheets
- Version
- 1.0
- Updated
What's inside
What changed
- 1.0
Published.
Preview
The workbook's sheets as you will receive them, with its example rows and the values its formulas calculate. Highlighted [[text]] is for you to replace; rows marked EXAMPLE are for you to delete. Wide sheets scroll sideways. The cover, document control and changelog sheets are in the file.
Instructions
How to use this workbook
| Step | What to do |
|---|---|
| 1 | What this workbook is. The record the backup administrator keeps of each restore test, and the resilience coordinator reads to see what is due and what failed. A finished backup job says nothing about whether the data restores. Only a restore does, so every row here is a restore that was timed, checked and recorded (BR-14). |
| 2 | On the Results sheet, enter the As-at date. Type it; never use a formula that changes it. Every status and date is worked out at that date. The test window and the first-test period are set on the Lists sheet from the Restore Testing Methodology. |
| 3 | On the Services sheet, copy each critical service's recovery time objective (RTO) and recovery point objective (RPO), in hours, from your recovery objectives under P22 (RR-04), and its cyber recovery time from check MX-05. This workbook measures against those objectives. It never sets or changes one. |
| 4 | On the Data Sets sheet, copy each data set from the Backup Coverage & Retention Matrix: its identifier, name, the service it serves, its class (Critical, Important or Other), its kind and the date it was first listed. The sheet works out its last restore check, whether that check is in time (BC-05), and when its next tests are due (BR-12, BR-13). |
| 5 | On the Tests sheet, add one row for each restore test you hold. Enter the data set, the date, the type (TT-1 to TT-5), what was restored, the copy used, the result of the integrity check on the copy, whether the restore completed, the time achieved and the data lost in hours, who ran it, who checked it, who confirmed it for the data owner and whether the evidence is recorded. Take times from system logs, not from memory (EV-3). Never enter a tabletop exercise or a drill (BR-13). |
| 6 | Read the six criteria columns. A test passes only when none is Not met. For each test that fails, raise a finding in the Backup Failure & Restore Findings Tracker, then enter the finding number in the last yellow column. The row shows "Raise a finding (BR-18)" until you do (BR-18). Issue the evidence report (Restore Test Evidence Report Template) within [[10]] working days of the test (BR-17). |
| 7 | On the Test Plan sheet, list each planned test, one row for each data set it restores. A test that is also a recovery test under P22 keeps P22's date and number. The Data Sets sheet shows whether the next test is planned before it falls due. |
| 8 | Read the Results sheet: the counts, with names. Report them to [[executive management]] each quarter and to [[the approver]] each year as counts with every gap named (BR-21). Keep each version of this workbook with the evidence it records for [[3]] years, or longer where law or a contract asks (BR-17). |
| 9 | To start your own workbook, delete the contents of the first column and of every yellow cell on the Services, Data Sets, Tests and Test Plan sheets. The formulas stay. |
Legend
Yellow cells are inputs. Everything else is calculated or fixed — do not overwrite formulas.
| EXAMPLE | Rows marked EXAMPLE in the first column show how a completed row looks. Delete them before approval. |
Limitations: 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.
Why this workbook exists. 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.
Both times. 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 (BR-15). The Services sheet shows both beside the objective.
A tabletop exercise or a drill under P10 is not a restore test and is never counted here (BR-13; P22 RR-14).
EXAMPLE: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders, an important entity under NIS2 in its Member State; not a financial entity, so DORA's reporting duties do not apply. After INC-2026-014, its Head of IT, who owns the backups, filled the coverage matrix on 30 Sep 2026. The record is as at 30 Sep 2026. The tests are P22's recovery tests and the checks behind them.
Adapting this template
Small organisation: list the data sets a critical service needs and the foundations first. One test a quarter of each critical data set is the minimum the Restore Testing Methodology asks (BR-13). Where one person runs the backups and checks the restore, ask someone else to check, and have the data owner confirm. The workbook cannot mark a test as passed until a second person is named (TC-05).
Intervals: the Restore Testing Methodology sets them (BR-13). Where you change one there, change it on the Lists sheet; every date follows. A critical service's system, end-to-end and rebuild tests are never less frequent than P22 RR-14 sets.
Provider-held data: where a provider holds the data and you hold no copy, there is nothing of yours to restore. Record the provider's own recovery test under P22, and read the Backup Coverage & Retention Matrix for the gap (BC-06).
Where NIS2 or DORA applies: the Implementing Regulation's Annex binds only the providers its Article 1 names. DORA binds financial entities only, and its Article 12 does not apply to the Article 16(1) entities, which follow Delegated Regulation Article 40. The example is neither.
Restores into a separate environment (TT-1 and TT-5) touch no live service, so P22's peak-season freeze does not stop them. A test that is also a P22 recovery test follows P22's schedule.
This workbook is your own record. Keep it with the evidence it records.
Results
Restore test results
The counts the resilience coordinator reports to [[executive management]] each quarter (BR-21). Yellow cells are yours; everything else calculates from the Tests, Data Sets, Services and Test Plan sheets. Every figure is a count with names, and every status is in words; the colour only repeats it.
Report settings
| Setting | Value | Note | |||
|---|---|---|---|---|---|
| As-at date | 30 Sep 2026 | Every status, date and count is worked out at this date. | |||
| Months in the test window | 12 | The window for BAM-06 and BAM-07, and for 'held in the last 12 months'. It is P22 RR-14's period. | |||
| Months from first listing to a first test of a type other than TT-1 | 6 | BR-13. A data set never tested is due this many months after its first listing, or sooner where its interval is shorter. | |||
The counts (BR-21: counts with names, never a score or a share)
| Measure | Result at the As-at date | Target | Named | What it means | The decision it supports |
|---|---|---|---|---|---|
| Restore tests held | 6 | Per the year's plan | 6 in the last 12 months | Every restore test on the Tests sheet, including a provider's failover that restores none of our backups. | Whether the year's plan is on track. |
| Tests that restored a backup of ours | 5 | Per the year's plan | 1 restored none (a provider's own test) | The tests that restored a backup of ours. These are the only tests the six criteria judge. | Whether the evidence rests on restores of our own copies, or on a provider's word. |
| Tests that met every criterion (BR-14) | 3 of 5 | All | Failed: RT-02 (TC-03); RT-04 (TC-04) | Tests that restored a backup of ours and met every criterion TC-01 to TC-06. A test that misses one is named with the criterion. | Which failed tests need a finding, and which data sets need a retest. |
| Failed tests with no finding recorded | 0 | None | None | Tests that failed a criterion and have no finding recorded beside them. | Whether every failure has an owner, a severity and a due date in the tracker (BR-18). |
| BAM-05 Restore checked in time | 4 of 5 | All | Not restored and checked in time: DS-06 | Critical data sets with a copy of our own whose last restore passed its integrity check within the period for its class. A copy never restored counts as not checked. | Which data sets to restore next, before the plan's date. |
| BAM-06 Restored within the recovery time | 2 of 5 | All | Not within: Online ordering, Payments, Customer contact | Critical services whose last recovery test, within the last 12 months, came back within the recovery time objective. A service never tested counts as not within. | Which services need a rebuild of their recovery before they are tested again. |
| BAM-07 Data lost within the recovery point in tests | 2 of 3 | All | Beyond the RPO: RT-04 (24 h lost against 4 h) | Tests in the last 12 months that measured the data lost, where the loss was within the recovery point objective. | Which data sets need a shorter backup interval. |
Each figure counts named tests, data sets or services. Add none of them together, and never show one as a percentage or a colour total (P22 RR-20).
The measures BAM-05 to BAM-07 are the Backup Assurance Dashboard's. Each service's restore time and cyber recovery time are on the Services sheet.
What this workbook is not
It is not a score. Every figure is a count with names, and a test that misses a criterion is named.
A tabletop exercise or a drill is not a restore test, and is never entered or counted here.
A restore in normal conditions shows the restore time. It does not show how long recovery takes after a destructive attack, so each service shows both times side by side.
It does not say that any backup, test or law's requirement is met. It records what was restored, how long it took and what was found.
It does not run a restore or an incident. Stopping and protecting backups during an incident are the incident manager's steps.
Tests
One row for each restore test held. A restore test restores data and measures it (BR-14). A tabletop, a drill or any other exercise is not a restore test: never enter one (BR-13).
| Row | Test ID | Data set ID | Date held | Type of test (BR-12) | Restored a backup of ours | What was restored | Copy used and date taken (EV-1) | Integrity check on the copy (EV-2) | Restore completed (TC-01) | Time achieved, hours (EV-3) | Data lost, hours (EV-6) | Run by (EV-7) | Checked by (TC-05) | Confirmed for the data owner by (TC-05) | Evidence recorded (TC-06) | P22 recovery test | P10 action it follows | Findings raised (BR-18) | Data set (calc) | Service ID (calc) | RTO, hours (calc) | RPO, hours (calc) | Cyber recovery time, hours (calc, BR-15) | TC-01 Restore completed (calc) | TC-02 Integrity checks passed (calc) | TC-03 Time within the RTO (calc) | TC-04 Data lost within the RPO (calc) | TC-05 Checked independently and confirmed (calc) | TC-06 Evidence recorded (calc) | Result (calc, BR-14) | Criteria not met (calc) | Finding (calc) | Restore time against the RTO (calc) | Data lost against the RPO (calc) | Held in the last 12 months (calc) | Counts as a recovery test (calc) | Counts as a checked restore (calc) | Counts for TT-2 (calc) | Counts for TT-4 (calc) | Counts for TT-5 (calc) | Service and date (working) | Failed tests, so far (working) | Data lost beyond the RPO, so far (working) | Failed with no finding, so far (working) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | RT-01 | DS-03 | 20 Jan 2026 | TT-5 | No | The ERP provider's failover between its data centres, with results shared (P06 CON-05). It restores no backup. | Not applicable | Not applicable | Yes | 3 | 0 | ERP software provider | Yes | RV-2026-01 | Ledgers and payroll records | CS-04 | 48 | 1 | 12 | Restores no backup of ours | Within the RTO | Within the RPO | Yes | Yes | No | No | No | No | CS-04|46042 | |||||||||||||||
| EXAMPLE | RT-02 | DS-01 | 20 May 2026 | TT-2 | Yes | The ordering platform restored from its nightly backup into the hosting provider's spare environment | [[copy and date taken]] | Pass | Yes | 96 | 24 | IT Operations Manager | Information Security Manager | Chief Operating Officer | Yes | RV-2026-02 | BF-01 | Orders and customer accounts | CS-01 | 24 | 24 | 108 | Met | Met | Not met | Met | Met | Met | Fails | TC-03 | Finding raised | Missed the RTO | Within the RPO | Yes | Yes | Yes | Yes | No | No | CS-01|46162 | RT-02 (TC-03) | |||
| EXAMPLE | RT-03 | DS-03 | 15 Jul 2026 | TT-5 | Yes | A copy of the ledgers restored by the ERP provider into a test instance, and checked for integrity (P11 MC-35) | [[copy and date taken]] | Pass | Yes | ERP software provider | Information Security Manager | Chief Financial Officer | Yes | Ledgers and payroll records | CS-04 | 48 | 1 | 12 | Met | Met | Not applicable | Not applicable | Met | Met | Passes | Yes | No | Yes | No | No | Yes | RT-02 (TC-03) | ||||||||||||
| EXAMPLE | RT-04 | DS-02 | 27 Aug 2026 | TT-2 | Yes | The warehouse management system restored from backup and checked by the warehouse team | [[copy and date taken]] | Pass | Yes | 5 | 24 | IT Operations Manager | Information Security Manager | Head of Logistics | Yes | RV-2026-03 | BF-02 | Stock and dispatch records | CS-02 | 8 | 4 | 17 | Met | Met | Met | Not met | Met | Met | Fails | TC-04 | Finding raised | Within the RTO | Beyond the RPO | Yes | Yes | Yes | Yes | No | No | CS-02|46261 | RT-02 (TC-03); RT-04 (TC-04) | RT-04 (24 h lost against 4 h) | ||
| EXAMPLE | RT-05 | DS-04 | 10 Sep 2026 | TT-1 | Yes | A sample of mailboxes restored from the daily export and opened (P11 MC-35) | [[copy and date taken]] | Pass | Yes | IT Operations Manager | Information Security Manager | Sales Director | Yes | Email and office documents | CS-05 | 24 | 24 | 12 | Met | Met | Not applicable | Not applicable | Met | Met | Passes | Yes | No | Yes | No | No | No | RT-02 (TC-03); RT-04 (TC-04) | RT-04 (24 h lost against 4 h) | |||||||||||
| EXAMPLE | RT-06 | DS-01 | 17 Sep 2026 | TT-1 | Yes | 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 | [[copy and date taken]] | Pass | Yes | IT Operations Manager | Information Security Manager | Chief Operating Officer | Yes | EA-04 | Orders and customer accounts | CS-01 | 24 | 24 | 108 | Met | Met | Not applicable | Not applicable | Met | Met | Passes | Yes | No | Yes | No | No | No | RT-02 (TC-03); RT-04 (TC-04) | RT-04 (24 h lost against 4 h) |
Data Sets
One row for each data set, from the Backup Coverage & Retention Matrix (BR-01). Yellow columns are yours; white columns calculate at the As-at date on the Results sheet. A data set that is not listed is treated as not backed up.
| Row | Data set ID | Data set | Service ID | Class (BR-13) | Kind (BR-12) | First listed on | Service (calc) | Restore check period, months (calc, BR-13) | Last restore checked (calc) | Restore checked in time (calc, BC-05) | Next restore check due (calc, TT-1) | Next restore check planned (calc) | Restore check planned against its due date (calc) | Second restore type needed (calc, BR-12) | Months between tests of it (calc) | Last test of it (calc) | Next test of it due (calc) | Next test of it planned (calc) | Test of it planned against its due date (calc) | Critical, not checked in time, so far (working) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | DS-01 | Orders and customer accounts | CS-01 | Critical | System | 30 Sep 2026 | Online ordering | 3 | 17 Sep 2026 | Yes | 17 Dec 2026 | 15 Oct 2026 | Before its due date | TT-2 | 12 | 20 May 2026 | 20 May 2027 | 10 Mar 2027 | Before its due date | |
| EXAMPLE | DS-02 | Stock and dispatch records | CS-02 | Critical | System | 30 Sep 2026 | Warehouse dispatch | 3 | 27 Aug 2026 | Yes | 27 Nov 2026 | 12 Nov 2026 | Before its due date | TT-2 | 12 | 27 Aug 2026 | 27 Aug 2027 | 17 Feb 2027 | Before its due date | |
| EXAMPLE | DS-03 | Ledgers and payroll records | CS-04 | Critical | SaaS | 30 Sep 2026 | Finance and payroll | 3 | 15 Jul 2026 | Yes | 15 Oct 2026 | 13 Oct 2026 | Before its due date | TT-5 | 12 | 15 Jul 2026 | 15 Jul 2027 | 13 Oct 2026 | Before its due date | |
| EXAMPLE | DS-04 | Email and office documents | CS-05 | Critical | SaaS | 30 Sep 2026 | Customer contact | 3 | 10 Sep 2026 | Yes | 10 Dec 2026 | 28 Oct 2026 | Before its due date | TT-5 | 12 | 30 Mar 2027 | 28 Oct 2026 | Before its due date | ||
| EXAMPLE | DS-05 | Card payment records | CS-03 | Critical | Provider-held | 30 Sep 2026 | Payments | 3 | Not applicable | Not applicable | ||||||||||
| EXAMPLE | DS-06 | Directory, network configuration, backup catalogue and build images | Critical | Foundations | 30 Sep 2026 | No service: the foundations | 3 | No | 30 Dec 2026 | 18 Nov 2026 | Before its due date | TT-4 | 12 | 30 Mar 2027 | 17 Feb 2027 | Before its due date | DS-06 |
Services
One row for each critical service, from your recovery objectives under P22 (RR-04). Copy the objectives; never set or change one here. Each service shows its restore time and its cyber recovery time side by side (BR-15). Times are in hours.
| Row | Service ID | Critical service | RTO, hours (P22 RR-04) | RPO, hours (P22 RR-04) | Cyber recovery time, hours (P22 MX-05) | Last recovery test (calc) | Time achieved, hours (calc) | Tested in the last 12 months (calc) | Restore time against the RTO (calc) | Cyber recovery time against the RTO (calc) | Restored within objective (calc, BAM-06) | Not within, so far (working) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | CS-01 | Online ordering | 24 | 24 | 108 | 20 May 2026 | 96 | Yes | Missed the RTO | Beyond the RTO | No | Online ordering |
| EXAMPLE | CS-02 | Warehouse dispatch | 8 | 4 | 17 | 27 Aug 2026 | 5 | Yes | Within the RTO | Beyond the RTO | Yes | Online ordering |
| EXAMPLE | CS-03 | Payments | 24 | 0 | 0 | No | Never tested | Within the RTO | No | Online ordering, Payments | ||
| EXAMPLE | CS-04 | Finance and payroll | 48 | 1 | 12 | 20 Jan 2026 | 3 | Yes | Within the RTO | Within the RTO | Yes | Online ordering, Payments |
| EXAMPLE | CS-05 | Customer contact | 24 | 24 | 12 | No | Never tested | Within the RTO | No | Online ordering, Payments, Customer contact |
Test Plan
The year's restore tests, one row for each data set a test restores, so a test that restores two data sets has two rows. The Data Sets sheet checks each is planned before its due date (BR-13). Restores into a separate environment (TT-1 and TT-5) touch no live service, so P22's peak-season freeze does not stop them. A test that is also a P22 recovery test follows P22's schedule.
| Row | Test ID | Data set ID | Planned date | Type of test (BR-12) | Restores a backup of ours | P22 recovery test | What will be restored | Data set (calc) | Its second restore type (calc) | Counts for that type (calc) | Status (calc) |
|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | RT-2026-07 | DS-03 | 13 Oct 2026 | TT-5 | Yes | The ERP provider restores last month's ledgers to a test instance, and the IT Operations Manager checks them | Ledgers and payroll records | TT-5 | Yes | Planned | |
| EXAMPLE | RT-2026-08 | DS-01 | 15 Oct 2026 | TT-1 | Yes | The ordering platform's monthly restore check with the backup provider (P10 EA-04) | Orders and customer accounts | TT-2 | No | Planned | |
| EXAMPLE | RV-2026-04 | DS-04 | 28 Oct 2026 | TT-5 | Yes | RV-2026-04 | Mailboxes restored to a test tenancy, with the providers (P22 RV-2026-04) | Email and office documents | TT-5 | Yes | Planned |
| EXAMPLE | RT-2026-09 | DS-02 | 12 Nov 2026 | TT-1 | Yes | The warehouse management system's database restored to a separate environment and checked | Stock and dispatch records | TT-2 | No | Planned | |
| EXAMPLE | RT-2026-10 | DS-06 | 18 Nov 2026 | TT-1 | Yes | The first restore of the directory backup, the network configuration and the backup catalogue, into an isolated environment | Directory, network configuration, backup catalogue and build images | TT-4 | No | Planned | |
| EXAMPLE | RT-2026-11 | DS-02 | 17 Dec 2026 | TT-1 | Yes | Retest of the recovery point after the warehouse database moves to a 4-hourly backup (BF-02) | Stock and dispatch records | TT-2 | No | Planned | |
| EXAMPLE | RV-2027-01 | DS-05 | 13 Jan 2027 | TT-5 | No | RV-2027-01 | The payment provider's own recovery test, its results shared (P22 RV-2027-01) | Card payment records | Planned | ||
| EXAMPLE | RV-2027-02 | DS-03 | 20 Jan 2027 | TT-5 | No | RV-2027-02 | The ERP provider's failover (P22 RV-2027-02) | Ledgers and payroll records | TT-5 | Planned | |
| EXAMPLE | RV-2027-03 | DS-06 | 17 Feb 2027 | TT-4 | Yes | RV-2027-03 | Foundations rebuilt in an isolated recovery environment, then the warehouse management system restored: the first measure of the cyber recovery time (P22 RV-2027-03) | Directory, network configuration, backup catalogue and build images | TT-4 | Yes | Planned |
| EXAMPLE | RV-2027-03 | DS-02 | 17 Feb 2027 | TT-4 | Yes | RV-2027-03 | Foundations rebuilt in an isolated recovery environment, then the warehouse management system restored: the first measure of the cyber recovery time (P22 RV-2027-03) | Stock and dispatch records | TT-2 | Yes | Planned |
| EXAMPLE | RV-2027-04 | DS-01 | 10 Mar 2027 | TT-3 | Yes | RV-2027-04 | The ordering platform recovered on the rebuilt recovery set-up, against its objectives (P22 RV-2027-04) | Orders and customer accounts | TT-2 | Yes | Planned |
Lists
| YesNo | TestType | Integrity | Class | Kind |
|---|---|---|---|---|
| Yes | TT-1 | Pass | Critical | System |
| No | TT-2 | Fail | Important | SaaS |
| TT-3 | Not applicable | Other | Foundations | |
| TT-4 | Provider-held |
TT-5
Settings the formulas read (from the Restore Testing Methodology)
| Months between tests of the type, by class (BR-13). Empty: not required | Does a test of the type in the row count for the type in the column (BR-12) | |||||||
| Type | Critical | Important | Other | TT-1 | TT-2 | TT-3 | TT-4 | TT-5 |
|---|---|---|---|---|---|---|---|---|
| TT-1 | 3 | 6 | 12 | Yes | No | No | No | No |
| TT-2 | 12 | 24 | Yes | Yes | No | No | No | |
| TT-3 | 12 | Yes | Yes | Yes | No | No | ||
| TT-4 | 12 | Yes | Yes | No | Yes | No | ||
| TT-5 | 12 | 24 | Yes | No | No | No | Yes |
| Kind of data set | Second restore type |
|---|---|
| System | TT-2 |
| SaaS | TT-5 |
| Foundations | TT-4 |
| Provider-held | None |
TT-1 is needed by every kind of data set except one the provider holds. The restore check period for a class is the TT-1 row (Critical 3, Important 6, Other 12 months).
Definitions
Definitions
| Term | Meaning in this workbook |
|---|---|
| BAM-05 Restore checked in time | Critical data sets with a copy of our own that were restored and checked within their class's period (BC-05), out of those with one, with the others named. Target: All. |
| BAM-06 Restored within the recovery time | Critical services restored within their recovery time objective in a test in the last 12 months, out of all (the P03 BM-06 count, from P22's tests). Target: All. |
| BAM-07 Data lost within the recovery point in tests | Timed tests in the last 12 months whose data lost was within the recovery point, out of the tests that measured it. Target: All. |
| TC-01 Restore completed | Everything in scope was restored. |
| TC-02 Integrity checks passed | The copy passed its integrity check before the restore, and the restored data matched its source or sample after it (BR-16). |
| TC-03 Time within the recovery time objective | The time achieved, from the decision to restore to the data owner's confirmation, was no longer than the service's RTO (P22 RR-04). Applies only where a time was measured. |
| TC-04 Data lost within the recovery point objective | The data lost between the copy and the failure point was no more than the service's RPO (P22 RR-04). Applies only where a time was measured. |
| TC-05 Checked independently and confirmed | Someone other than the tester checked the result, and the data owner confirmed that the data is usable (BR-14). |
| TC-06 Evidence recorded | The record holds the copy used, start and end times, the checks made and who made them (BR-17). |
| TT-1 File, item or data set restore | A sample of files, mailbox items or records, or one whole data set such as a database, restored to a separate place and checked for integrity. It shows: the copy is whole, the keys work and the data opens. It does not show how long a whole system takes. |
| TT-2 Full system restore | A whole system, such as a server, a platform and its data, restored from backup into a spare environment and started, with the time recorded. It shows: the system comes back from backup, and how long that takes, against the service's recovery time objective. |
| TT-3 Full service end to end | A critical service recovered with all its systems and data, and used by its business owner. It is P22's recovery test (RR-14) and one record serves both packs. It shows: the service works, within its objectives, with its dependencies in place. |
| TT-4 Bare-metal or clean-room rebuild | The foundations, and the systems that depend on them, rebuilt in an isolated recovery environment from trusted build sources, with data restored from backup. It shows: recovery works when the attacker has the production tools and accounts. It measures the cyber recovery time. |
| TT-5 Cloud or software-as-a-service tenant restore | A tenant's data, such as mailboxes, files or ledgers, restored from the organisation's own copy or the provider's, into a test tenant, with the provider where needed. It shows: data the provider holds can be restored, including what it does not back up itself. |
| 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). |
| 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). |
| 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). |
| Class | How much the organisation depends on a data set: Critical, Important or Other (CLASSES). The class sets how often it is restored in a test (BR-13). |
| 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. |
| Recovery time objective (RTO) | Recovery time objective: the time within which the service must be back, counted from the decision to recover it. Always shorter than the MTD (RR-04). |
| Recovery point objective (RPO) | Recovery point objective: 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). |
| 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). |
| Recovery test | A technical test that recovers a critical service, or the systems behind it, and measures the time achieved and the data lost against its objectives; for a service a supplier runs, the supplier's own recovery test with its results shared. An exercise, a tabletop or a drill, is not a recovery test (RR-14). |
| 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). |
| Counts as a checked restore | A test that restored a backup of ours, passed the integrity check on the copy and was held on or before the As-at date. Only these tests count towards a data set's restore check. |
| Criterion columns (TC-01 to TC-06) | Met, Not met or Not applicable. A criterion that needs a time, TC-03 or TC-04, is Not applicable when no time was measured. A test that restored no backup of ours has none. |
| Passes, Fails | A test passes when no criterion is Not met. It fails when one or more is Not met. A test that restores no backup of ours is shown as such, and is neither. |
| Finding raised | Beside a failed test, whether a finding number is entered. Raise the finding in the tracker first, then enter its number. |
| Restore time against the RTO | The time achieved against the service's recovery time objective. It is the restore time in normal conditions. The cyber recovery time sits beside it. |
| Data lost against the RPO | The data lost between the copy and the failure point, against the service's recovery point objective. |
| Held in the last 12 months | A test dated after the day 12 months before the As-at date, and not after the As-at date. |
| Counts as a recovery test | A test with a P22 recovery test number entered. One record serves both packs (BR-13). |
| Restore check period | The months within which a data set's last restore must have passed its integrity check: Critical 3, Important 6, Other 12 (BR-13, BC-05). |
| Next test due | The last test of the type plus the months for its class. A data set never tested is due the months for its class after it was first listed, or 6 months for a type other than TT-1 where that is sooner (BR-13). |
| Evidence | What each test's record holds (BR-17): EV-1 the data set, the copy used (identifier, date and time taken) and where it was held; EV-2 the result of the integrity check on the copy before the restore; EV-3 start and end times of the restore, from system logs rather than from memory; EV-4 what was restored, with counts or sizes, and what it was compared with; EV-5 the result of the application's own consistency check, and the records the data owner opened; EV-6 the data lost, worked out from the copy's time; EV-7 who ran the restore, who checked it, and who confirmed it for the data owner; EV-8 every failed criterion, with the finding raised for it. |
| Restore steps | Each test follows steps RS-1 to RS-9 of the Backup Operations & Restore Test Procedure. |
| As-at date | The date every status, date and count is worked out at. |
| (calc), (working) | A column or cell the workbook calculates. Do not type or paste over it. Working columns hold running lists other cells read. |
| BR-nn, BC-nn, EV-n | The rules of the Restore Testing Methodology, the checks of the Backup Coverage & Retention Matrix and the items of evidence of the Restore Test Evidence Report Template. DS-nn are data sets, CS-nn critical services, RT-nn restore tests and BF-nn findings. |
| EXAMPLE | A worked example: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders, as at 30 Sep 2026. Delete before use. |
Framework References
Framework references
These references indicate relevance only and do not reproduce the text of any standard.
| Framework | Reference | Supported by |
|---|---|---|
| ISO/IEC 27001:2022 | Annex A 8.13 — Information backup | The workbook as a whole: the record that backup copies are restored and checked, not only taken |
| ISO/IEC 27001:2022 | Clause 7.5.3 — Control of documented information | Tests sheet: each test's evidence is recorded, kept for [[3]] years and found when it is needed |
| ISO/IEC 27001:2022 | Clause 10.2 — Nonconformity and corrective action | Tests sheet, finding column: each failed criterion leads to a finding, a fix and a retest |
| 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” | Tests sheet: the restored data is checked, and the data owner's confirmation shows normal operation is back |
| NIST CSF 2.0 | RC.RP-03 — “The integrity of backups and other restoration assets is verified before using them for restoration” | Tests sheet, criterion TC-02 and step RS-4: the integrity of the copy is verified before it is used |
| NIS2 — Directive (EU) 2022/2555 | Article 21(2)(c) — “business continuity, such as backup management and disaster recovery, and crisis management” | The workbook as a whole: a record of restore tests of the backups, showing what was restored, how long it took and what was found, with every gap named |
| 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 | Applies to the providers its Article 1 names. For them, the Annex points below; for others, a useful guide only |
| NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.2.3 — “The relevant entities shall perform regular integrity checks on the backup copies.” | Tests sheet, the integrity columns, and the last restore that passed its integrity check on the Data Sets sheet (providers Article 1 names) |
| 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.” | Tests, Data Sets and Test Plan sheets: restores of backup copies tested regularly, the results documented, and each failed criterion sent to the findings tracker for corrective action (providers Article 1 names) |
| 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.” | Tests and Test Plan sheets, for financial entities other than those of Article 16(1): the backup restoration and recovery procedures tested periodically |
| DORA — Regulation (EU) 2022/2554 | Article 12(6) — “In determining the recovery time and recovery point objectives for each function, financial entities shall take into account whether it is a critical or important function and the potential overall impact on market efficiency. Such time objectives shall ensure that, in extreme scenarios, the agreed service levels are met.” | Services sheet, for financial entities other than those of Article 16(1): each service's recovery time and recovery point objectives, which the tests measure against. The objectives are P22's; this workbook only measures against them |
| 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 | Tests sheet, for financial entities other than those of Article 16(1): the checks on restored data, and a second person's confirmation, behind criteria TC-02 and TC-05 |
| 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” | Tests and Results sheets, for the entities of DORA Article 16(1): results documented, and each failed criterion passed to the findings tracker so it can be analysed, addressed and 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” | Tests sheet: the time achieved against the recovery time objective, as evidence of how quickly personal data can be restored after an incident |
| 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.” | Tests and Test Plan sheets: a periodic test restore that completes and meets the required timeframe. Guidance only |
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)
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.
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard.