Restore Testing Methodology

Purpose

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.

This methodology shows [[Organisation Name]] how to prove that its backups restore. It sets 22 rules, BR-01 to BR-22, and seven steps that turn them into practice: list and classify the data, choose the restore tests each data set needs, set how often to run them, run a test, judge it against six pass criteria, record the evidence, and fix what the test finds. Results are reported as counts, with every gap named.

The other documents of the Backup & Restore Assurance pack put it into practice: the Backup Operations & Restore Test Procedure runs a restore test step by step, the Backup Coverage & Retention Matrix finds gaps in coverage, the Restore Test Workbook records each test, the Immutable & Offline Backup Protection Checklist checks that backups are out of an attacker's reach, the Backup Failure & Restore Findings Tracker follows every finding to closure, the Restore Test Evidence Report Template gives an auditor or an insurer the evidence and the Backup Assurance Dashboard reports the measures. The Backup & Restore Assurance Pack — Guide shows how they fit together.

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.

Scope

This methodology covers:

• Data sets and copies: every data set that a critical service needs, the data the foundations need to be rebuilt (BR-01), and every backup copy of them, including copies a supplier holds and data in cloud and software-as-a-service systems (BR-19). A critical service is a business service, such as taking orders. A data set is a body of data backed up and restored as a unit, such as one database, one file share or one mail tenant.
• Restore tests: the five types in Step 2, run by the organisation or by a supplier on its behalf.

Where it stops. The methodology works alongside three other packs and changes nothing they set:

Every test is measured against the recovery time objective and the recovery point objective of the service that needs the data. Those objectives belong to the service's business owner under P22, and this methodology never sets one. Where a test shows an objective cannot be met, the gap is raised under P22 RR-15 (BR-18).

An exercise, a tabletop or a drill is not a restore test, and no document in this pack counts one as a restore test (BR-13; P22 RR-14). An exercise tests decisions around a table. A restore test restores data and measures it.

How the method works

The seven steps, in order. Each is a section below.

Step 1: List and classify the data

Every data set a critical service needs is listed in the coverage matrix with its owner, class, location, how it is backed up, how often, for how long and by whom (BR-01). The data owner is the manager accountable for the data set. For the data a critical service needs, that is the service's business owner (P22 RR-02), who also agrees the interval, because the recovery point objective is the longest gap of data they will accept (P22 RR-04). A data set that is not listed is treated as not backed up.

The three classes

The class says how much the organisation depends on a data set, and it sets how often the data set is restored in a test (BR-13).

The coverage checks

Before any test, six checks find gaps in the list itself: listed and owned (BC-01), backed up as often as the recovery point (BC-02), copies meet the rule (BC-03), retention meets the longest need (BC-04), restored and checked in time (BC-05) and cloud and provider-held data covered (BC-06). The coverage matrix runs them for every data set. A failed check is a finding (BR-18).

Step 2: Choose the restore test types

There are five types of restore test (BR-12). Each one proves something the others do not. A test of a higher type counts for the lower types it includes.

A system you run needs TT-1 and TT-2. Data in a provider's tenant needs TT-1 and TT-5. The foundations (directory, network configuration, backup catalogue, build sources) need TT-1 and TT-4. Data a provider holds with no copy of ours is tested through the provider's own recovery test, checked against the objectives (P22 RR-14).

For a critical service, the full service test (TT-3) is P22's recovery test (RR-14). One record serves both packs. The rebuild test (TT-4) is the only test that measures the cyber recovery time.

Step 3: Set how often to test

Each type is repeated at least as often as its table sets for the data set's class (BR-13). For a critical service, the system, end-to-end and rebuild tests are never less frequent than P22 RR-14 sets, and one test serves both rules where it meets both.

A first test of a type other than TT-1 is due within [[6]] months of the day the data set is first listed. A new data set does not wait for the first full interval.

Three more rules decide the date of each test:

• Alternate the copy. For a critical data set, alternate between the online copy and the immutable or offline copy, so each is shown to restore (BR-03).
• One test, two jobs. 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.
• A higher type counts, if it passed. A system restore (TT-2) also counts as the restore check (TT-1) for the same data set, provided its integrity check passed. A restore whose integrity check failed is a finding and does not start the clock for the next test.

Step 4: Run the test

Every test follows the same nine steps. The Backup Operations & Restore Test Procedure gives the working version, with the commands and screens for your own backup system.

Where to restore

A restore from an immutable or offline copy goes to an isolated place (P22 RR-13), never straight onto production (BR-07). A rebuild test has no route to production at all. Where a test is also a rebuild test, the clean-room gates apply (P22 CG-13, CG-14).

Two integrity checks. Every test checks integrity twice (BR-16). The first check is of the copy, before it is restored (P09 IM-10). The second check is of the restored data, afterwards. It compares the data with a source or a sample, runs the application's own consistency check, and has the data owner open records that matter. The first check finds a damaged copy. The second finds a restore that completed and produced the wrong thing.

Step 5: Judge the result

A restore test passes only when every criterion holds (BR-14). The six criteria are below. Two of them, the time and the data lost, apply only where the test is timed. TT-1 and TT-5 are not, and a test that is not timed claims nothing about recovery time.

A test that misses a criterion is a finding (BR-18). It is not a failed backup. It is the test doing its job.

Who judges. The person who runs the restore does not judge it alone. The restore checker checks the result and the data owner confirms that the data is usable (TC-05). The checker is somebody who did not run the restore. This is separation of duties, and it is the criterion most often skipped (PF-09).

Two times, side by side

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). Reports show both.

Step 6: Record the evidence

Every 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 (BR-17). The record holds eight things:

• 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.

The evidence report is issued within [[10]] working days of the test. Records are kept for [[3]] years, or longer where law or a contract asks. The Restore Test Evidence Report Template sets out the report in nine sections: summary, scope, method, evidence list, results by criterion, times against objectives, findings, limits of the test and sign-off.

Step 7: Fix, retest and report

Every failed criterion, failed check, unmet protection control and repeated job failure is a finding with an owner, a severity and a due date (BR-18). The owner agrees a plan within [[10]] working days.

A finding is Open until the plan is agreed and the fix is done, then Fixed, awaiting retest, and Closed only when the retest passes.

A finding closes only when a retest or new evidence shows that the fix works (BR-18). A finding that is also an objective gap is linked to it and keeps the date P22 RR-15 sets. A High finding is told to the owner of the risk it bears on, and the risk is reassessed (P05 RM-10).

Backup assurance is reported to [[executive management]] each quarter and to [[the approver]] each year (BR-21). Every measure is a count with the gaps named. None is turned into a percentage, a score or a colour for the whole programme (P22 RR-20). Four data sets of six that meet the copies rule is reported as 4 of 6, with the other two named.

The Backup Assurance Dashboard reports eight measures, BAM-01 to BAM-08: backed up as often as the recovery point, copies rule met, protection controls met, failed backup jobs, restore checked in time, restored within the recovery time, data lost within the recovery point in tests and findings open and past due.

Roles

Each role below has a named holder and a named deputy. One person may hold several roles, with three limits: the restore checker is not the person who ran the restore (TC-05), the protection reviewer does not administer the backup system, and the resilience coordinator runs no system in scope.

The Backup Operations & Restore Test Procedure and the Backup Assurance Dashboard give who is accountable, responsible, consulted and informed for each activity, from planning the year's tests to reporting.

The rules

The statements below keep the IDs BR-01 to BR-22 that every document in the Backup & Restore Assurance pack cites. Values in [[brackets]] are the pack's defaults.

What is backed up, how often and for how long

BR-01 Every data set that a critical service needs (P22 RR-01, RR-09), and the data the foundations need to be rebuilt, is listed in the coverage matrix with its owner, class, location, how it is backed up, how often, for how long and by whom. A data set that is not listed is treated as not backed up.

BR-02 Each critical data set is backed up at least as often as the recovery point of the service that needs it (P22 RR-04, MX-03). Where a supplier runs the backup, the interval the supplier reports counts. When a job fails, the data set is outside that interval until a good copy exists again, and its data owner is told (BR-11).

BR-05 Each data set's retention is the longest of three needs: how far back the business may need to go, any legal or contractual duty, and the recovery need, which is long enough to reach a copy taken before an attacker's earliest sign (P22 RR-12). The data owner records each need and its source. Nothing is kept longer than the longest need without a recorded reason.

BR-10 A backup holds what a restore needs, and not only the data: configuration, the sign-in directory, the backup catalogue, build sources and the keys (BR-09). Data in cloud and software-as-a-service systems is included, or covered under BR-19.

BR-22 A new or changed system, and every new data set, is added to the matrix before it goes live. A retired system's backups are kept for their retention and then deleted, with a record. The matrix, the backup suppliers' contacts and the instructions to recover the keys are kept where they can be reached when the main systems are down (P22 RR-16).

How the copies are protected

BR-03 Each critical data set has at least [[3]] copies of the data (the live data and two backups), on at least [[2]] kinds of storage or media, with at least [[1]] copy offsite and at least [[1]] copy that is immutable or offline. The immutable or offline copy cannot be changed or deleted with production administrator credentials (P22 RR-11), nor with the everyday credentials of the backup administrators (BR-06).

BR-04 No more than [[0]] copies of a critical data set are unverified. A copy is verified when a restore of that data set was checked for integrity within the restore check period for its class (BR-13). A copy that has never been restored is unverified.

BR-06 The backup system, its storage and its management consoles are administered with accounts that are separate from the production sign-in directory, used only for backup administration, protected by multi-factor authentication and held by named people. No one holds both production domain administrator rights and the right to delete an immutable copy or shorten its retention. During an incident, P09 C4 applies.

BR-07 The backup storage and the systems that manage it cannot be reached from user or server networks with ordinary or production credentials. An offline copy is connected only while it is written or restored, and each connection is recorded. A restore from an immutable or offline copy goes to an isolated place (P22 RR-13), never straight onto production.

BR-08 Each immutable copy carries a retention lock for its full retention period. Shortening or removing a lock needs two named people and a recorded reason. A lock that administrator credentials alone can remove does not make a copy immutable.

BR-09 Backups are encrypted wherever they leave the organisation's control. The keys and the recovery credentials for the backup system are kept outside the estate that is backed up, can be reached by at least two named people when production is down, and are proved in a restore test. A backup whose key cannot be found is treated as lost.

Running the jobs

BR-11 Every backup job reports its result to a named person, and the results are reviewed each working day. A failed job is rerun, or its cause fixed, so that a good copy exists again within [[24]] hours of the failure for a critical data set, [[72]] for an important one and [[168]] for any other; a failure not put right in that time is escalated to [[the backup owner]] then. [[2]] failures in a row on one data set are raised as a finding (BR-18). Every failure is logged with its data set, its cause, when it was found and when a good copy existed again, and the data owner is told when it took the data set outside its recovery point. A job stopped on the incident manager's instruction under P09 C3 is not a failure, and P09's steps decide when it restarts.

Cloud services and suppliers

BR-19 For every cloud or software-as-a-service system that holds a critical data set, the data owner records what the provider backs up, for how long and how it restores, and what it leaves out, such as deleted items, data changed by an attacker and administrator errors. Where the provider's commitment is shorter than the data set's recovery point or retention, the organisation keeps its own copy outside the provider's account. The tenant restore is tested (TT-5).

BR-20 Where a supplier runs a backup, its contract gives a restore time no longer than the service's recovery time objective (P22 RR-10), and the supplier shares the results of its own restore checks. A contract that gives no time or a longer one is recorded as a failed P22 check (MX-04).

Restore tests

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.

BR-13 Each type is repeated at least as often as the methodology's table sets for the data set's class. For a critical service, the system, end-to-end and rebuild tests are never less frequent than P22 RR-14 sets, and one test serves both rules where it meets both. A first test is due within the period shown from the day the data set is first listed. A tabletop, a drill or any other exercise under P10 is not a restore test and is never counted as one (P22 RR-14).

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).

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.

BR-16 Every restore test checks integrity twice: the copy before it is restored (P09 IM-10), and the restored data afterwards, by comparing it with a source or a sample, running the application's own consistency check and having the data owner open records that matter. Where a test is also a rebuild test, the clean-room gates apply (P22 CG-13, CG-14).

Evidence, findings and reporting

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.

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).

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).

Example: the distributor's first baseline

EXAMPLE, not part of the methodology. The organisation used throughout the pack is a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. It is an important entity under NIS2 in its Member State, and not a financial entity, so DORA's reporting duties do not apply. After incident INC-2026-014 and the resilience review that followed it, the backup owner, Head of IT, listed its data sets on 30 Sep 2026. The resilience coordinator, Head of Risk, who runs no system in scope, coordinates. Replace this with your own, or delete it before approval.

Six data sets, as at 30 Sep 2026. The last column lists the coverage checks each one fails.

The six tests recorded so far. One of them, RT-01, restored no backup. Times are hours, against the service's objective.

RT-02 shows why Step 5 has six criteria. The ordering platform restored and passed its integrity check, but took 96 h against an objective of 24 h. RT-04 restored the warehouse system in 5 h, inside its 8 h objective, but lost 24 h of data against the 4 h the service can lose. Two High findings follow (BF-01 and BF-02).

The restore time beside the cyber recovery time (BR-15), from the tests above and the recovery estimates of the resilience review:

The two clocks differ most for Warehouse dispatch: 5 h to restore, within its 8 h objective, and 17 h after a destructive attack. Where a service has had no restore test, there is no restore time to show, and the cyber recovery time is only an estimate.

The year's plan holds ten more tests, from 13 Oct 2026 to 10 Mar 2027. Each is dated no later than the day it falls due, and five of them are P22 recovery tests, where one record serves both packs.

Which laws ask for this

Several texts ask for backup, restore and testing arrangements. This section says, in summary, what each asks. It does not say that this methodology, or following it, fulfils any of them. The framework references at the end list which parts of this document relate to each text.

NIS2 Directive

Article 21(2)(c) of the NIS2 Directive lists, among the measures essential and important entities take, “business continuity, such as backup management and disaster recovery, and crisis management”. Directive (EU) 2022/2555 binds Member States, which ensure that essential and important entities take the Article 21 measures. Whether it reaches an organisation depends on its sector, its size and national law.

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. Section 4.2 of its Annex, "Backup and redundancy management", covers backup plans, integrity checks and regular recovery tests (NIS2 IR 1).

DORA (financial entities only)

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. Article 12 asks for backup policies, periodic tests of restoration and recovery, restoring on segregated systems and integrity checks after a recovery. The Article 16(1) entities are asked for back-up and restoration measures (Article 16(1)(f)) and for a yearly test of backup and restore with documented results (Delegated Regulation, Article 40).

GDPR

Regulation (EU) 2016/679 binds controllers and processors of personal data. Article 32(1) lists measures as appropriate to the risk. Article 32(1)(c) names, among the measures that may be appropriate, the ability to restore the availability of and access to personal data in a timely manner after a physical or technical incident. Article 32(1)(d) names a process for regularly testing, assessing and evaluating the effectiveness of the measures.

NIST SP 800-209 and the NCSC post are guidance. They bind nobody, and an organisation may weigh each recommendation against its own risks. The NCSC post asks whether at least one backup is offline at any time, and says the "3-2-1" rule does not require any copy to be offline. NIST SP 800-209 asks for a periodic test restore and for validation of copies at least once a year. The 3-2-1-1-0 rule of thumb in BR-03 and BR-04 is an industry practice and no legal requirement.

Adapting this template

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).

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