Backup Operations & Restore Test Procedure
Covers job monitoring, failure handling and scheduled restore tests with evidence capture.
Available soon
- Format
- Word
- Size
- 75 KB
- Length
- 25 pages
- Version
- 1.1
- Updated
What's inside
- Purpose
- Legal note
- Why a finished backup job proves little
- Scope
- Roles
- How the routines fit together
- Routine 1: the daily job review
- Routine 2: handling a failed job
- Routine 3: planning the restore tests
- Routine 4: running a restore test
- Routine 5: the evidence a test leaves
- Routine 6: what to do when a test fails
- Cloud, software-as-a-service and supplier backups
- Keys and the way into the backup system
- What changes in an incident
- When to escalate
- Decisions and who takes them
- Pitfalls
- Worked example: the distributor's September 2026 baseline
- Related documents
- Adapting this template
- Framework references
- Definitions
What changed
- 1.1
When to escalate sends every failed job not put right in its class's time to the backup owner, as BR-11 says, not only a critical data set's; the critical class keeps the shortest time.
- 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.
Purpose
This procedure sets out how [[Organisation Name]] runs its backups day to day and proves that they restore. It has three routines: the daily review of backup jobs, the handling of a failed job, and the restore test, from planning the year's tests to the evidence each one leaves. It also says what changes in an incident.
It applies the rules BR-01 to BR-22 of the Restore Testing Methodology, which sets the restore checks that P22's rule RR-11 points to. It works from the Backup Coverage & Retention Matrix, which lists each data set and its class, and it feeds the Restore Test Workbook, the Backup Failure & Restore Findings Tracker and the Restore Test Evidence Report Template.
Guidance — delete before approval
Replace every value in [[double brackets]] before approval, and name roles, not people.
The settings in [[double brackets]] (hours to fix a failed job, months between restore checks, days to fix a finding, years to keep records) are shared with the Restore Testing Methodology. Change them there and here together.
Keep a printed or offline copy of this procedure, the coverage matrix, the suppliers' contacts and the instructions to recover the backup keys (BR-22). If the main systems are down, you will need them most.
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.
Where this procedure names a law, it says which text asks for what and whom it binds. The NIS2 Implementing Regulation binds only the providers its Article 1 names (NIS2 IR 1); other organisations may use its Annex as good practice. DORA binds financial entities only, and its Articles 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.
Why a finished backup job proves little
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 this procedure does two jobs. The daily review finds the jobs that failed, quickly enough to fix them. The restore test finds what the review cannot: a copy that is incomplete, a key that is lost, a restore that takes four days, a copy that an attacker could have deleted. Run both, and keep the evidence.
A backup job is "one scheduled run that copies a data set. It ends in success or failure. Its result says nothing about whether the copy restores"; a restore test is "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)".
Scope
This procedure covers every data set in the coverage matrix (BR-01): data on the organisation's own systems, data held in cloud and software-as-a-service systems, the data and configuration the foundations need to be rebuilt, and data held by a supplier that runs a backup for the organisation. It covers backup jobs run by staff and by suppliers.
It does not set the recovery objectives of a critical service. Those are P22's, in the Cyber Resilience & Recovery pack (P22), and a restore test here is measured against them. It does not cover detecting, containing or recovering from an attack: that is incident response, in the Security Incident Management pack (P09). It does not cover exercises, which the Cyber Incident Exercises & Tabletop Scenario Library pack (P10) runs. A tabletop or a drill is an exercise, not a restore test, and is never counted as one (P22 RR-14).
Roles
Role | What they do in this procedure |
|---|---|
Approver [[e.g. Chief Operating Officer]] | Approves the backup standard and receives the yearly report. |
Backup owner [[e.g. Head of IT]] | Is accountable for the backup system, its protection and the restore tests, and for fixing findings. |
Backup administrator [[e.g. IT Operations Manager, with the backup service provider]] | Runs the backup jobs, reviews their results each working day, fixes failures and runs restore tests. |
Data owner [[the manager accountable for each data set; for a critical service, its business owner (P22 RR-02)]] | Agrees the data set's class, interval and retention, and confirms that restored data is usable. |
Restore checker [[e.g. Information Security Manager, who did not run the restore]] | Checks the restored data against the pass criteria, independently of the person who ran the restore. |
Protection reviewer [[e.g. Head of Information Security, who does not administer the backup system]] | Reviews the protection checklist and the evidence behind each answer. |
Resilience coordinator [[the resilience coordinator under P22]] | Keeps the findings tracker, plans the year's restore tests with the backup owner, and reports. |
Supplier liaison [[e.g. Procurement Manager]] | Holds the backup and cloud suppliers to their restore times and gets their restore test results. |
Incident manager [[e.g. Information Security Manager (P09)]] | In an incident, stops and protects backup jobs and checks the backups under P09 C3, C4 and D3. |
The person who runs a restore does not check it alone. The restore checker is a different person from the backup administrator, and the data owner confirms that the data is usable (BR-14). The protection reviewer does not administer the backup system.
Every role has a named deputy. Where a supplier runs part of the backup, the supplier liaison holds it to the work (BR-20).
How the routines fit together
There are six routines, each with its own owner and record: the daily job review (1), handling a failed job (2), planning the restore tests (3), running a restore test (4), the evidence it leaves (5) and what to do when a test fails (6).
The Immutable & Offline Backup Protection Checklist holds the controls BP-01 to BP-15. This procedure runs the review log that BP-13 asks for. The protection itself (separate accounts, isolation, locks and keys) is set by BR-06 to BR-09.
Routine 1: the daily job review
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.
The review is the first line of defence. It does not prove a restore works. It finds the backup that did not run, quickly enough to fix it before the data set is outside its recovery point. Every data set in the matrix has a named person who receives its job result, and the review reads all of them.
The five steps, in order. Do them every working day, including the day after a bank holiday for the jobs that ran in between:
Step | What happens | Who |
|---|---|---|
JR-1 | Open the backup system's job report for every data set, and the reports from suppliers that run backups. Do it at a fixed time each working day, [[e.g. 08:30]], after the overnight jobs end. Take the report from the backup system itself, and ask each supplier that runs a backup for its own. An unread alert is not a review. | Backup administrator |
JR-2 | Note each failed, missed or partial job. A job stopped under P09 C3 is logged as stopped, not as failed. Mark each job as succeeded, failed, missed (it did not start) or partial (it ran but skipped data). Treat a missed or partial job as a failure. | Backup administrator |
JR-3 | For each failure on a critical data set, start the rerun and log the failure (BR-11). Start the rerun at once and open a log entry with the fields below. If the cause is plain, such as no space or an expired credential, fix it first. If the rerun fails too, have a person look at the cause. | Backup administrator |
JR-4 | Work out whether the data set is now outside its recovery point. If it is, tell the data owner the same day. Find the time of the last good copy. If the gap from it to now is longer than the recovery point of the service that needs the data set (BR-02), tell the data owner the same day, in writing, with when you expect a good copy. | Backup administrator |
JR-5 | Escalate any failure still open at the time BR-11 sets for the data set's class, and raise a finding for a repeat. Each morning, list the failures still open and how long each has run. Escalate any that has reached the time for its class. Count failures in a row on each data set. | Backup administrator; Backup owner |
The time to fix a failed job, by class
Each data set has a class, set by its data owner (BA-02). The class sets how long a failure may stay open before it is escalated (BR-11), and how often a restore of the data set is checked (BR-13):
Class | What it means | Fix or escalate within | Restore checked at least every |
|---|---|---|---|
Critical | Loss would stop a critical service (P22 RR-01), or it is data the foundations need to be rebuilt (P22 RR-09). | [[24]] hours | [[3]] months |
Important | Loss would cause Major harm on the risk register's impact scale, and no critical service stops. | [[72]] hours | [[6]] months |
Other | Any other data set the organisation backs up. | [[168]] hours | [[12]] months |
The restore check period is the longest gap between restores of that data set that were checked for integrity. A restore of a higher type counts for the lower ones it includes (BR-12).
Guidance — delete before approval
Most backup systems can send a daily summary and an alert on any failure. Send both to a shared mailbox that two people read, and to the supplier's contact. A review that depends on one person's inbox stops when that person is away.
Routine 2: handling a failed job
A failed job is a gap in the chain of copies. Until a good copy exists again, the data set is outside its recovery point if the gap is longer than the recovery point of the service that needs it (BR-02). The handling has one aim: close the gap fast, and tell the person whose service carries the risk.
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).
The steps, in order:
Step | What happens | Who |
|---|---|---|
F-1 | Log the failure with the fields above, as soon as the review finds it. | Backup administrator |
F-2 | Rerun the job, or fix the cause and rerun it. Where a supplier runs the job, ask it to rerun and to tell you the cause in writing. | Backup administrator; Supplier liaison |
F-3 | Work out whether the data set is now outside its recovery point, and tell the data owner the same day if it is. | Backup administrator |
F-4 | Confirm that the new copy completed, is not partial and is recorded with its time. Only then does a good copy exist again. | Backup administrator |
F-5 | If a good copy does not exist again by the time for the data set's class, escalate to the backup owner and say what the data owner has been told. | Backup administrator; Backup owner |
F-6 | On a second failure in a row for the same data set, raise a finding with the cause and the fix. Add the failure to the tracker. | Resilience coordinator |
F-7 | Close the log entry. Keep it with the review log (BP-13), where the protection reviewer and an auditor can read it. | Backup administrator |
The failure log holds, for every failure, at least these fields (BR-11):
Field | What it holds |
|---|---|
Data set | The data set and its class, from the coverage matrix |
Cause | What went wrong, in a line a colleague could act on |
When found | Date and time the failure was found. The review should find it the same day |
Last good copy | Date and time of the last copy that completed and was not partial |
Good copy again | Date and time a good copy existed again |
Data owner told | The date, and whether the failure took the data set outside its recovery point |
Status | Open or closed, with who closed it |
A job that was stopped is not a failed job
In an incident, the incident manager may stop backup jobs under P09 C3, so that encrypted files do not overwrite good copies. A job stopped on that instruction is logged as stopped. It is not a failure, and P09's steps decide when it restarts. See "What changes in an incident" below.
Repeat failures
Two failures in a row on the same data set are raised as a finding (BR-11, BR-18). A repeat points to a cause the rerun does not fix: a target that is too small, a credential that keeps expiring, a window that is too short for the data. The finding gets an owner, a severity and a due date, as in Routine 6.
Routine 3: planning the restore tests
A restore test needs a plan, or it will be put off until the week an auditor asks. The resilience coordinator and the backup administrator plan the year's tests with the backup owner (BA-08), once a year and again whenever a system or a data set is added.
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.
The five test types, with what each shows and needs, and how often each is due by class (the longest gap, in months). The Restore Testing Methodology says what each type is.
Type | What it is and what it shows | Critical | Important | Other |
|---|---|---|---|---|
TT-1 File, item or data set restore | The copy is whole, the keys work and the data opens. It does not show how long a whole system takes. Needs: a separate place to restore into and a data owner who can open records. Cheap enough to run often. It shows the copy is whole and the keys work. | [[3]] months | [[6]] months | [[12]] months |
TT-2 Full system restore | The system comes back from backup, and how long that takes, against the service's recovery time objective. Needs: spare capacity, such as a hosting provider's spare environment, and a time record. It is the first test that shows how long a system takes. | [[12]] months | [[24]] months | Not required |
TT-3 Full service end to end | The service works, within its objectives, with its dependencies in place. Needs: the business owner and the service's users. It is P22's recovery test (RR-14), so one record serves both packs. Check P22's peak-season freeze before you fix a date. | [[12]] months | Not required | Not required |
TT-4 Bare-metal or clean-room rebuild | Recovery works when the attacker has the production tools and accounts. It measures the cyber recovery time. Needs: the isolated recovery environment and trusted build sources. It measures the cyber recovery time, and its result replaces the estimate in P22's matrix. Check P22's peak-season freeze before you fix a date. | [[12]] months | Not required | Not required |
TT-5 Cloud or software-as-a-service tenant restore | Data the provider holds can be restored, including what it does not back up itself. Needs: the provider's help where the provider holds the data, and a test tenant. It shows what the provider can and cannot restore, including what it leaves out. | [[12]] months | [[24]] months | Not required |
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).
The types each kind of data set needs (BR-12):
Kind of data set | Types needed | Why |
|---|---|---|
System, such as a server, a platform and its database | TT-1 and TT-2 | Shows that the data restores, and that the whole system comes back and how long it takes |
Cloud or software-as-a-service tenant | TT-1 and TT-5 | Shows that data the provider holds, or that you export from it, can be restored |
Foundations: the directory, network configuration, backup catalogue and build images | TT-1 and TT-4 | Shows that everything else can be rebuilt on them |
Data a provider holds with no copy of ours | None of ours | Use the provider's own recovery test, and ask for its results (P22 RR-14; BR-20) |
Choosing and dating the tests
- Start from the coverage matrix. For each data set, find the class, the kind and the date of the last restore that was checked for integrity. The next restore check is due that many months later (BR-13).
- Where a test is also a P22 recovery test of a critical service, plan it once. One record serves both (BR-13). The date and the scope follow P22's schedule, including its peak-season freeze.
- A restore into a separate environment (TT-1 and TT-5) touches no live service. P22's peak-season freeze applies to a test that is also a P22 recovery test, not to these.
- For a critical data set, alternate between the online copy and the immutable or offline copy from one test to the next, so that both are proved (RS-2).
Guidance — delete before approval
Spread the first year's tests across the year. Do not run all of them in the month before a certification audit: you will find the problems when there is no time to fix them.
Routine 4: running a restore test
A restore test has nine steps. The first five set it up and run it, the next two measure it, and the last two record it and clean up. Keep the same steps for every type, adding the extra work each type needs.
The nine steps. Each feeds the rule or the pass criterion shown:
Step | What happens | Who | Feeds |
|---|---|---|---|
RS-1 | Choose the data set, the type and the date, and tell the data owner and the backup supplier. Take the data set and type from the year's plan. Tell the data owner, the restore checker and any supplier involved. Where the test is also a P22 recovery test, the plan and the date are P22's. | Backup administrator; Resilience coordinator | BR-13 |
RS-2 | Choose the copy. For a critical data set, alternate between the online copy and the immutable or offline copy. Record the copy by identifier and the time it was taken. If the offline copy must be connected, record the connection (BR-07). | Backup administrator | BR-03 |
RS-3 | Prepare an isolated place to restore into, with no route to production for a rebuild test. Prepare a place cut off from production. Never restore a test onto the live system. For a rebuild test, build the isolated recovery environment as P22's clean-room gates set out. For a tenant test, create a test tenant. | Backup administrator | BR-07 |
RS-4 | Check the copy's integrity before restoring it, and note the result. Run the backup system's own verification on the copy. If it fails, record the failure as a result, and try the next copy (P09 IM-10 asks for the same check in an incident). | Backup administrator | TC-02 |
RS-5 | Start the clock at the decision to restore. Restore, and stop the clock when the data owner confirms the data is usable. Take both times from system logs and messages, not from memory. | Backup administrator | TC-03 |
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. The restore checker compares counts, sizes or a sample with the source and runs the application's consistency check. The data owner opens records that matter to the service and says whether they are right. | Restore checker; Data owner | TC-02, TC-05 |
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. The hours between the copy's time and the last point the data was known to be complete are the data lost. Compare them with the recovery point objective. | Backup administrator | TC-04 |
RS-8 | Record the evidence, and have the restore checker and the data owner sign. Fill in the test record from the evidence items below. The tester signs for the restore, the checker for the checks and the data owner for usability. | Backup administrator; Restore checker; Data owner | TC-05, TC-06 |
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. Record that the restored data and the environment were deleted. Link each finding to any objective gap, and send the record to the coordinator for the tracker. | Backup administrator; Resilience coordinator | BR-18 |
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).
The pass criteria. Where a test is not timed, TC-03 and TC-04 do not apply, and the others still do:
Criterion | Name | What must hold |
|---|---|---|
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). Timed tests only. |
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). Timed tests only. |
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). |
Two integrity checks
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).
The first check is on the copy before the restore, with the backup system's own verification. The second is on the restored data. Record both results. A copy that fails the first check is a result: write it down, and try the next copy. In an incident, P09 IM-10 asks for the same check before any restore.
NIS2 Implementing Regulation Annex 4.2.3 asks relevant entities to perform regular integrity checks on backup copies (NIS2 IR 1 applies to the providers it names). NIST SP 800-209 recommends that backup copies are periodically validated as healthy (RA-SS-R8).
Where to restore, and how
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.
Restore into a place with no route to production, and delete what you restored when the test ends (RS-3, RS-9). NIST SP 800-209 recommends that cyber-attack recovery copies are not mounted or mapped to a production host, and are restored onto an isolated staging environment (IS-SS-R7). DORA Article 12(3) asks financial entities that restore backup data on their own systems to use systems physically and logically separate from the source.
Two times, side by side
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.
A restore test shows how long a restore takes in normal conditions, onto systems that can be trusted. The cyber recovery time is what P22 works out for a service: "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)." Record the restore time from the test (RS-5), and take the cyber recovery time from the service's row in P22's matrix. The evidence report shows both beside the service's recovery time objective (ES-6). A rebuild test (TT-4) replaces the estimate of the foundations' time with a measurement.
The recovery time objective (RTO) and the recovery point objective (RPO) belong to the service and to P22. A restore test measures against them and never sets them. "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: 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)."
Who checks, and who confirms
Someone other than the person who ran the restore checks the result (TC-05, PF-09). The data owner confirms that the data is usable, using records that matter to the service, and not only that the files opened. A restore the administrator judged alone has not been checked.
Guidance — delete before approval
Plan the data owner's time. A restore is often ready on a Friday afternoon when the data owner has gone home. Book the check in the plan, with a deputy.
Routine 5: the evidence a test leaves
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.
The record of every test holds these eight items, so that someone who was not there can see what happened:
Item | |
|---|---|
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 Restore Test Workbook records each test against the pass criteria. The Restore Test Evidence Report Template turns one test, or a period's tests, into a report with 9 sections, ES-1 to ES-9: summary, scope, method, evidence list, results by criterion, times against objectives, findings, limits of the test and sign-off. Issue the report within [[10]] working days of the test.
The report says what the test did not show (ES-8). A service restored in a spare environment has not been restored in production, and a file restore does not show how long a whole system takes. Say so. An honest limit makes the rest of the report more credible to an auditor or an insurer.
File the evidence where nobody who took part can change it. Keep the records as long as BR-17 sets, or longer where a law or a contract asks.
Routine 6: what to do when a test fails
A test that misses a pass criterion has done its job: it found the problem on a quiet day. Do not rerun it until it passes, and do not change the criterion. Record the result and raise a finding for each failed criterion.
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).
The severity sets how long the owner has to fix a finding (BR-18):
Severity | What it means | Fix within |
|---|---|---|
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]] days |
Medium | A weakness that other protection backs up. | [[180]] days |
Low | An improvement, tracked to the next review. | [[365]] days |
After a failed test, in order:
- Raise the finding with an owner, a severity and a due date. The owner agrees a plan within [[10]] working days.
- Where the test shows that a critical service cannot meet its recovery time or recovery point objective, raise an objective gap under P22 RR-15 as well, and link the two. The finding keeps the date P22 sets.
- Tell the owner of the risk the finding bears on, for a High finding, so that the risk is reassessed (P05 RM-10).
- Fix it, and retest. A finding closes only when a retest or new evidence shows that the fix works. The owner saying it is done does not close it.
A failed test is reported as a count with its name, for example "[[3]] of [[5]] tests passed every criterion, and the other [[2]] are named", and never as a score or a share (P22 RR-20).
Cloud, software-as-a-service and supplier backups
A provider that runs a platform does not necessarily back up what your people delete, what an attacker changes or what an administrator breaks. Never assume it does.
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).
Record the provider's scope for each system that holds a critical data set, in the Backup Coverage & Retention Matrix. Where its commitment falls short, keep your own copy outside the provider's account, and test the restore with 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).
Ask each supplier for the results of its own restore checks, and keep them with your test records. A supplier that runs a backup for you runs part of your procedure. The review, the failure handling and the tests apply to its jobs too.
Keys and the way into the backup system
A backup that cannot be decrypted, or a console no one can sign into, is lost. This is the failure that a restore test most often finds late.
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.
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).
What to do now, and at each test:
- Keep a key register: where each key and recovery credential is kept, and the two or more named people who can reach it when production is down.
- In a restore test, have a named person who is not the usual backup administrator recover a key from the register and decrypt a copy (RS-2, RS-4). Write down the date.
- Keep the matrix, the suppliers' contacts and the instructions on paper or offline, with the incident response plan. Check that you can open them from there.
What changes in an incident
The Security Incident Management pack (P09) owns the incident. It decides what is stopped, what is protected and what is restored, and who decides each. This procedure does not change any of it. It says where backup operations meet P09:
P09 step or rule | What it asks, in short | What this procedure does |
|---|---|---|
C3 | Stop synchronisation and scheduled backup jobs that touch affected systems | The backup administrator stops the jobs on the incident manager's instruction. Log each as stopped, not as failed (JR-2). P09's steps decide when they restart (BA-15) |
C4 | Protect the backups | The backup administrator carries it out. BR-06 and BR-07 are the standing protection that makes it quick. The incident manager decides (BA-15) |
D3 | Are the backups intact and clean? | The restore test records the integrity checks of each copy (TC-02). They show in advance which copies can be trusted |
IM-10 | Backups checked for integrity before they are restored | The first integrity check of every restore test (BR-16) is the same check, practised |
Restoring after an attack is P22's work, in its clean room, using the copy and the recovery point P22's procedure chooses. A restore test of type TT-4 practises it. Until an incident is closed, treat any backup that an attacker might have reached as unverified: it is not a good copy until a restore of it has been checked.
When to escalate
At any point, stop and escalate when:
When | What happens | To | Basis |
|---|---|---|---|
A failed job of any data set is still not put right at the time for its class: [[24]] hours for a critical data set, [[72]] for an important one and [[168]] for any other | Escalate with the log entry and what the data owner has been told. The backup owner decides what else to try, and whether the supplier's contract is in question. A critical data set has the shortest time, so its failures reach the backup owner first. | Backup owner | BR-11 |
A failure takes a data set outside its recovery point | Tell the data owner the same day. The data owner decides whether the service can carry the exposure until a good copy exists. | Data owner | BR-02, BR-11 |
A second failure in a row on one data set | Raise a finding, with the cause and the fix, and add it to the tracker. | Resilience coordinator | BR-11, BR-18 |
A restore test misses a pass criterion | Raise a finding for each failed criterion. The owner agrees a plan within the days BR-18 sets. | Resilience coordinator | BR-14, BR-18 |
A restore test shows that a service's objective cannot be met | Raise an objective gap under P22 RR-15 and link the finding to it. | Resilience coordinator | P22 RR-15; BR-14 |
A supplier gives no restore time, or will not share its restore results | Record a failed check (P22 MX-04) and press for the contract change. | Backup owner | BR-20 |
A key, a console password or a recovery credential for the backups cannot be found | Treat the backup as lost, and tell the backup owner now. Do not wait for the next test. | Backup owner | BR-09 |
A backup copy has been deleted, changed or reached by someone who should not have it | Tell the incident manager at once. P09 takes over and this procedure's jobs pause as P09's steps say. | Incident manager | P09 C3, C4 |
Decisions and who takes them
Who is accountable (A) and who does the work (R), from the responsibility table. The same table names who is consulted and informed. BA-15 is P09's step, not a decision this procedure adds:
Decision or task | Accountable | Does the work | Basis | |
|---|---|---|---|---|
BA-01 | Approve the backup standard and the coverage matrix | Approver | Backup owner | BR-01 |
BA-02 | Agree each data set's class, interval and retention | Data owner | Backup owner | BR-02, BR-05 |
BA-03 | Run the backup jobs and review their results each working day | Backup owner | Backup administrator | BR-11 |
BA-04 | Fix a failed job, or escalate it | Backup owner | Backup administrator | BR-11 |
BA-05 | Tell the data owner when a failure takes a data set outside its recovery point | Backup owner | Backup administrator | BR-11 |
BA-06 | Keep the backups protected: separate identity, isolation, locks and keys | Backup owner | Backup administrator | BR-06 to BR-09 |
BA-07 | Review the protection checklist against its evidence | Protection reviewer | Protection reviewer | BR-06 to BR-09 |
BA-08 | Plan the year's restore tests | Resilience coordinator | Backup administrator | BR-12, BR-13 |
BA-09 | Run a restore test | Backup owner | Backup administrator | BR-14 |
BA-10 | Check the restored data and confirm it is usable | Data owner | Restore checker | BR-14, BR-16 |
BA-11 | Issue the evidence report and sign it | Backup owner | Backup administrator | BR-17 |
BA-12 | Keep the findings tracker and chase due dates | Resilience coordinator | Resilience coordinator | BR-18 |
BA-13 | Fix a finding and show it works | Backup owner | Backup administrator | BR-18 |
BA-14 | Raise an objective gap when a test shows an objective cannot be met (P22 RR-15) | Resilience coordinator | Backup administrator | BR-14; P22 RR-15 |
BA-15 | Stop backup jobs and protect the backups during an incident | Incident manager | Backup administrator | P09 C3, C4 |
BA-16 | Get restore commitments and restore check results from suppliers | Backup owner | Supplier liaison | BR-20 |
BA-17 | Report to executive management and the approver | Resilience coordinator | Resilience coordinator | BR-21 |
Pitfalls
The mistakes this procedure is built to prevent, each with its fix:
Pitfall | Fix | |
|---|---|---|
PF-01 | Treating a finished job as proof that the data restores. | Restore it, check it and time it (BR-14). |
PF-02 | Testing a file restore and calling the service recoverable. | Test the type the data set needs: a system, a service end to end, a rebuild or a tenant (BR-12). |
PF-10 | Counting a tabletop or a drill as a restore test. | A restore test restores data and measures it (BR-13; P22 RR-14). |
PF-12 | Reporting a job success rate as a percentage. | Report counts and name every failure (BR-21). |
Worked example: the distributor's September 2026 baseline
EXAMPLE, not part of the procedure. The organisation used throughout the pack is a wholesale distributor with about 900 staff and three warehouses, an important entity under NIS2 in its Member State, and not a financial entity, so DORA's reporting duties do not apply. After its ransomware incident INC-2026-014 (P09) the Head of Risk coordinated the baseline, and the Head of IT owns the backups. The coverage matrix was first filled on 30 Sep 2026. Values are as at 30 Sep 2026.
A month of backup jobs
Four data sets run scheduled jobs. The ERP's backup is the provider's continuous one, reported monthly, and the card payment records are not backed up by the distributor. The jobs from 1 Sep 2026 to 30 Sep 2026:
Data set | Class | Jobs scheduled | Jobs failed |
|---|---|---|---|
DS-01 Orders and customer accounts | Critical | 30 | 1 |
DS-02 Stock and dispatch records | Critical | 30 | 1 |
DS-04 Email and office documents | Critical | 30 | 1 |
DS-06 Directory, network configuration, backup catalogue and build images | Critical | 30 | 0 |
All four | 120 | 3 |
The report says 3 of 120 jobs failed, and names each one. A single success rate would hide which data sets failed and what each failure cost (P22 RR-20). The failures (EXAMPLE):
Failure | Data set | Cause | Last good copy | Good copy again | Hours without a good copy |
|---|---|---|---|---|---|
FJ-2026-09-01 | DS-02 Stock and dispatch records | No space on the backup target | 7 Sep 2026, 01:40 | 8 Sep 2026, 15:20 | 37.7 |
FJ-2026-09-02 | DS-04 Email and office documents | The provider limited the export | 15 Sep 2026, 02:00 | 16 Sep 2026, 20:05 | 42.1 |
FJ-2026-09-03 | DS-01 Orders and customer accounts | A network interruption between the platform and the backup service | 28 Sep 2026, 02:30 | 29 Sep 2026, 14:10 | 35.7 |
What the review and the handling found, for each failure:
Failure | Recovery point of the service | Outside its recovery point? | Fixed within the time for its class? | Data owner told |
|---|---|---|---|---|
FJ-2026-09-01 | 4 hours (Warehouse dispatch) | Yes | Yes: 13.8 hours against [[24]] | 8 Sep 2026 |
FJ-2026-09-02 | 24 hours (Customer contact) | Yes | Yes: 18.3 hours against [[24]] | 16 Sep 2026 |
FJ-2026-09-03 | 24 hours (Online ordering) | Yes | Yes: 11.5 hours against [[24]] | 29 Sep 2026 |
Every failure was found the same morning and fixed the same day, well inside the [[24]] hours that BR-11 sets for a critical data set. All three data sets are Critical. Yet each failure took its data set outside the recovery point of the service that needs it, because the gap between the last good copy and the next was longer than that recovery point (BR-02). That is why the data owner is told the same day, and why "fixed within the time" is not the same as "no exposure". No data set failed twice in a row, so BR-11 raised no finding for a repeat.
Notice what the recovery point means for dispatch. The data set "Stock and dispatch records" is backed up every 24 hours, and the service's recovery point is 4 hours. A matrix check (BC-02) already fails for that data set, and any failed job widens the gap. The finding behind it is BF-02.
Restore tests so far
Six tests appear in the example's record. The first, RT-01, was the ERP provider's failover between its data centres. It restored no backup, so it counts for P22 and not for any restore check here. The other five restored data from a backup:
Test | Data set | Date | Type | Criteria met | Result |
|---|---|---|---|---|---|
RT-02 | DS-01 Orders and customer accounts | 20 May 2026 | TT-2 Full system restore | 5 of 6 Not met: TC-03 | Failed |
RT-03 | DS-03 Ledgers and payroll records | 15 Jul 2026 | TT-5 Cloud or software-as-a-service tenant restore | 4 of 4 | Passed |
RT-04 | DS-02 Stock and dispatch records | 27 Aug 2026 | TT-2 Full system restore | 5 of 6 Not met: TC-04 | Failed |
RT-05 | DS-04 Email and office documents | 10 Sep 2026 | TT-1 File, item or data set restore | 4 of 4 | Passed |
RT-06 | DS-01 Orders and customer accounts | 17 Sep 2026 | TT-1 File, item or data set restore | 4 of 4 | Passed |
Two times, side by side
The two failed tests were timed, and each service has a second time that no test has yet measured, its cyber recovery time from P22's matrix:
Service | Last test | Restore time achieved | Recovery time objective | Cyber recovery time | P22 status |
|---|---|---|---|---|---|
CS-01 Online ordering | 20 May 2026 | 96 hours | 24 hours | 108 hours | Not achievable |
CS-02 Warehouse dispatch | 27 Aug 2026 | 5 hours | 8 hours | 17 hours | Needs its workaround |
The ordering platform took 96 hours to restore in its 20 May 2026 test (RT-02), against an objective of 24. That is TC-03 not met, and it is finding BF-01, a High finding linked to P22 OG-01, P05 TA-01, P12 GAP-03. It keeps the date P05 gives its action.
Dispatch restored in 5 hours in its 27 Aug 2026 test (RT-04), within its 8-hour objective, so TC-03 was met. But the test lost 24 hours of data against a recovery point of 4 hours, so TC-04 was not met, and the test failed. A report that quoted only the 5 hours would have read as a pass. And the 5 hours is a restore onto trusted systems: the cyber recovery time is 17 hours (P22 MX-05). The finding is BF-02, a High finding linked to P22 OG-05.
What is due next
The restore check periods are measured from the last restore that was checked for integrity. A test of a higher type counts. As at 30 September 2026:
Data set | Class | Last restore checked | Next due |
|---|---|---|---|
DS-01 Orders and customer accounts | Critical | 17 Sep 2026 | 17 Dec 2026 |
DS-02 Stock and dispatch records | Critical | 27 Aug 2026 | 27 Nov 2026 |
DS-03 Ledgers and payroll records | Critical | 15 Jul 2026 | 15 Oct 2026 |
DS-04 Email and office documents | Critical | 10 Sep 2026 | 10 Dec 2026 |
DS-06 Directory, network configuration, backup catalogue and build images | Critical | Never | 30 Dec 2026 |
DS-05 Card payment records | Critical | Provider-held: no copy of ours | The provider's own recovery test (RV-2027-01) |
The data set "Directory, network configuration, backup catalogue and build images" has never been restored and checked. That is a Medium finding, BF-05, and the plan puts its first restore into an isolated environment on 18 Nov 2026, ahead of the date it is due. A rebuild test of the foundations (RV-2027-03, 17 Feb 2027) follows. Until the first restore is checked, that copy is unverified (BR-04).
The year's plan holds 10 tests from 13 Oct 2026 to 10 Mar 2027 (EXAMPLE). Of them, 5 are P22 recovery tests, scheduled by P22. 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.
One test in detail: RT-2026-09
12 Nov 2026: "The warehouse management system's database restored to a separate environment and checked." It is a file, item or data set restore (TT-1) of DS-02 Stock and dispatch records, and it falls in a freeze month, which does not stop it, because it touches no live service. The restore check of DS-02 is due on 27 Nov 2026. How each step runs:
- RS-1 to RS-3: the IT Operations Manager tells the Information Security Manager and the Head of Logistics, picks last night's daily backup from cloud object storage and records [[the copy identifier and the time taken]], and prepares a separate environment with no route to production.
- RS-4 and RS-5: the backup system verifies the copy ([[pass or fail]]). The clock starts at the decision to restore and stops when the data owner confirms. A TT-1 is not timed against the recovery time objective.
- RS-6: the Information Security Manager compares counts and a sample with the source and runs the database's consistency check. The Head of Logistics opens [[a day's stock and dispatch records]].
- RS-7: work out the time between the copy and the last point the data was known to be complete, and note it. TC-04 applies only to timed tests, so it does not decide this test. The backup runs every 24 hours against a recovery point of 4 hours (BC-02, BF-02).
- RS-8 and RS-9: fill in EV-1 to EV-7 and sign. Delete the restore. Raise a finding for each failed criterion, and send the record to the coordinator.
What the result will mean:
Result of the test | What follows |
|---|---|
Every criterion that applies is met | The restore check of the data set is up to date. Close any retest finding that depends on it. Issue the evidence report. |
The data lost is longer than the recovery point (noted, not a TC-04 result for an untimed test) | BF-02 already covers it. Its retest is RT-2026-11 on 17 Dec 2026, after the warehouse database moves to a 4-hourly backup. |
The integrity check on the copy fails | Record it. Try the previous copy, and raise a High finding if the data set has no copy that restores (BR-18). Tell the data owner the same day. |
Related documents
Document | Relationship |
|---|---|
Restore Testing Methodology | The rules BR-01 to BR-22, the test types and the pass criteria this procedure runs |
Backup Coverage & Retention Matrix | Every data set, its class and the checks BC-01 to BC-06 that find gaps |
Restore Test Workbook | Where each restore test is recorded against the pass criteria |
Immutable & Offline Backup Protection Checklist | The protection controls BP-01 to BP-15, including the review log (BP-13) |
Backup Failure & Restore Findings Tracker | Failed jobs and findings, tracked to closure |
Restore Test Evidence Report Template | The evidence report of a test or a period's tests |
Cyber Resilience & Recovery pack (P22) | The recovery objectives, the recovery test rule (RR-14), objective gaps (RR-15), the reporting rule (RR-20) and the clean room |
Security Incident Management pack (P09) | Stopping and protecting backups (C3, C4), the backup check (D3, IM-10), and every decision in an incident |
Cyber Incident Exercises & Tabletop Scenario Library pack (P10) | Exercises. Never counted as restore tests |
Adapting this template
Guidance — delete before approval
Small organisation: keep the daily review and one restore of each critical data set a quarter. Both need little more than a calendar, a spare machine and an hour. The review log can be a shared spreadsheet.
Managed service provider or backup supplier: much of the review and the restore work will be its own. Check the contract gives you same-day failure alerts, the restore times (BR-20) and a copy of its restore check results, and that its administrator accounts cannot delete or shorten your immutable copies.
Cloud and software as a service: the provider backs up the platform, not necessarily your deletions or an attacker's changes. Record what it leaves out and keep your own copy where that matters (BR-19).
Regulated entity (NIS2, DORA): an entity under the NIS2 Implementing Regulation keeps records of its tests as Annex point 4.2.6 asks, and a financial entity under DORA (other than those of Article 16(1)) checks its backup policies against Article 12(1) and its tests against Article 12(2), with [[legal or compliance]].
Delete this section before approval.
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 procedure: backup copies kept and tested to a topic-specific policy |
ISO/IEC 27001:2022 | Annex A 5.37 — Documented operating procedures | The whole procedure: documented operating procedures for backup operations |
NIST CSF 2.0 | PR.DS-11 — “Backups of data are created, protected, maintained, and tested” | Routines 1 to 5: backups created, protected, maintained and tested |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(c) — “business continuity, such as backup management and disaster recovery, and crisis management” | The whole procedure: backup management as part of business continuity |
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 | Who the Implementing Regulation binds; for other entities its Annex is a guide only |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.2.2 — based on the risk assessment (point 2.1) and the business continuity plan, backup plans that include: “recovery times”; “assurance that backup copies are complete and accurate, including configuration data and data stored in cloud computing service environment”; “storing backup copies (online or offline) in a safe location or locations, which are not in the same network as the system, and are at sufficient distance to escape any damage from a disaster at the main site”; “appropriate physical and logical access controls to backup copies, in accordance with the asset classification level”; “restoring data from backup copies”; and “retention periods based on business and regulatory requirements” | Routine 4 and the keys section: complete and accurate copies, restoring data, and access controls to the copies |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.2.3 — “The relevant entities shall perform regular integrity checks on the backup copies.” | Routine 4: integrity checks on the copy before a restore (BR-16) |
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.” | Routines 3 to 6: regular testing of recovery, documented results and corrective action |
DORA — Regulation (EU) 2022/2554 | Article 12(1) — “For the purpose of ensuring the restoration of ICT systems and data with minimum downtime, limited disruption and loss”, financial entities develop and document backup policies and procedures specifying “the scope of the data that is subject to the backup and the minimum frequency of the backup, based on the criticality of information or the confidentiality level of the data”, and restoration and recovery procedures and methods | Routines 1 and 3: documented backup and restoration procedures |
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.” | Routines 3 and 4: testing of backup procedures and restoration methods |
DORA — Regulation (EU) 2022/2554 | Article 12(3) — “When restoring backup data using own systems, financial entities shall use ICT systems that are physically and logically segregated from the source ICT system.” Those systems are securely protected from unauthorised access or ICT corruption and allow timely restoration | Routine 4: restoring into systems segregated from the source |
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 | Routine 4: checks and reconciliations of restored data |
DORA — Delegated Regulation (EU) 2024/1774 | Article 8(2)(b)(i) — the policies and procedures for ICT operations contain controls and monitoring of ICT systems, including “backup and restore requirements of ICT systems” | Routine 1: backup and restore requirements within ICT operations procedures, for the financial entities Title II covers |
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” | Routines 1 and 4: the ability to restore personal data in a timely manner |
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.” | Routine 3: periodic test restores that complete and meet the required timeframe |
NIST SP 800-209 (October 2020) | Section 4.8, RA-SS-R8 — periodically validate that the backup copies are in good health; “Frequency of validation should match sensitivity and value of protected data, but no less than once per year.” | Routine 4: backup copies validated as healthy, at least once a year |
NIST SP 800-209 (October 2020) | Section 4.7, IS-SS-R7 — “Cyber-attack recovery copies should not be mounted, exported, or mapped to a host or application, and they should be restored (pushed) onto an isolated staging (or air-gapped) environment rather than directly onto the target hosts or applications.” | Routine 4: restoring onto an isolated staging environment, not onto production |
NCSC (UK) guidance | Blog post “Offline backups in an online world” (13 August 2019) — the offline rule, “At any given time, are one or more backups offline?”, because “With at least one backup offline at any given time, an incident cannot affect all of your backups simultaneously”; the “3-2-1” rule, “at least 3 copies, on 2 devices, and 1 offsite”, which “does not require any backup location to be offline”; and the regular rule, that backups should be “regularly tested to check they work as expected” | Routine 3: alternating the online and offline copy, and regular testing |
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 procedure |
|---|---|
Backup job | One scheduled run that copies a data set. It ends in success or failure. Its result says nothing about whether the copy restores. |
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). |
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 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). |
Retention lock | A setting on a stored copy that stops anyone shortening its retention or deleting it. Removing it needs two named people and a recorded reason (BR-08). |
The 3-2-1-1-0 rule | The 3-2-1-1-0 rule of thumb: at least three copies of the data, on two kinds of storage, one copy offsite, one copy immutable or offline, and zero copies whose restore has not been checked. It is a practice used in industry, not a legal requirement. BR-03 and BR-04 set it. |
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). |