Backup Coverage & Retention Matrix
Maps systems and data sets to backup method, frequency, retention, copies and immutability.
Available soon
- Format
- Excel
- Size
- 84 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. One row per data set (BR-01), on five linked sheets. Data Sets records each data set, how it is backed up and how long it is kept. Copies lists each copy. Restore Tests lists the restore tests held. Checks runs six checks on every data set. Settings holds the values the checks read and counts the results. The rules are those of the Restore Testing Methodology (BR-01 to BR-22). A data set that is not listed is treated as not backed up. |
| 2 | Start on the Settings sheet. Enter the as-at date: the day you read the matrix. Every restore check period counts back from it. Then check the yellow values against your backup standard: the copies rule (BR-03), the days of retention that the recovery need asks for (BR-05), the months to a first test, and the months between tests of each type and class (BR-13). |
| 3 | List every data set that a critical service needs, and the data the foundations need to rebuild, on the Data Sets sheet (BR-01). Use an ID such as DS-01. Give each an owner, a class (Critical, Important or Other, BR-13) and a kind. For a critical service's data, the owner is the service's business owner (P22 RR-02). |
| 4 | For a data set that serves a critical service, enter the service ID and that service's recovery point objective in hours, copied from the objectives your business owners agreed (P22 RR-04). Leave both blank for the foundations: their backups serve every rebuild. Enter how often the data set is backed up, in hours, and leave it blank where you hold no backup of your own. |
| 5 | Record retention (BR-05). Enter the days kept, then the days the business may need to go back and the days any law or contract asks for. The recovery need calculates from the Settings sheet. Retention must be at least the longest of the three. Record each need and its source in the owner's notes: nothing is kept longer than the longest need without a recorded reason. |
| 6 | List every copy on the Copies sheet: the live data counts as one copy. For each, enter the kind of storage, whether it is offsite and whether it is immutable or offline (BR-03, BR-07, BR-08). A second copy in the same cloud account, reachable with the same credentials, is not offsite and not immutable. A lock that administrator credentials alone can remove does not make a copy immutable (BR-08). |
| 7 | Record each restore test on the Restore Tests sheet. Enter the type (TT-1 to TT-5, BR-12), the date, whether it restored a backup and whether the copy passed its integrity check before the restore (BR-16). Only a test that restored data counts. A tabletop, a drill or any other exercise is not a restore test (P22 RR-14), so never enter one here. |
| 8 | Read the Checks sheet. Each check gives Pass, Fail or Not applicable, with a note that shows the numbers. BC-05 reads the last restore that passed its integrity check. The sheet also gives the next test due of each type the data set needs. A first test is due within the period on the Settings sheet of the day the data set was first listed (BR-13). |
| 9 | Read the counts at the foot of the Settings sheet. They are written "3 of 5" with the others named. Report them that way, each quarter, with every gap named (BR-21). Report counts only: no score and no share, and no colour for the whole matrix (P22 RR-20). |
| 10 | Raise every failed check as a finding with an owner, a severity and a due date (BR-18), in the Backup Failure & Restore Findings Tracker. Enter its ID in the last input column of Data Sets. Where a failure also means a service cannot meet its objectives, link the finding to the objective gap (P22 RR-15). Tell the owner of the risk it bears on (P05 RM-10). |
| 11 | Keep the matrix current. Add a new or changed system, and every new data set, before it goes live. Keep a retired system's backups for their retention, then delete them with a record (BR-22). Keep a copy of the matrix, the suppliers' contacts and the instructions to recover the keys where they can be reached when the main systems are down (BR-22, P22 RR-16). |
| 12 | Delete the EXAMPLE rows before the workbook is approved. This workbook is your own record: keep it with your backup standard. It is a file you keep, not a place to record anything on a website. |
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 a matrix is not enough. Backup success is not recovery success. So this workbook never counts a backup job. It counts copies, and a copy counts as proved only when a restore passed its integrity check inside the period for its class (BC-05).
What this workbook does not decide. Stopping backup jobs and protecting the backups during an incident are P09 C3 and C4, under the incident manager. The backup check before a restore is P09 D3. Recovery objectives, and the recovery test of each critical service, are P22's (RR-04, RR-14). This matrix reads the recovery point from P22 and never sets one. Whether the copies are protected as BR-06 to BR-09 ask is the question of the Immutable & Offline Backup Protection Checklist.
Who the law binds. Implementing Regulation (EU) 2024/2690 binds only the providers its Article 1 names: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online market places, of online search engines and of social networking services platforms, and trust service providers. Other organisations may use its Annex as good practice. Regulation (EU) 2022/2554 binds financial entities. Articles 5 to 15, including 11 and 12, do not apply to the entities of its Article 16(1), which follow Article 16(1)(f) and Articles 39 and 40 of Delegated Regulation (EU) 2024/1774. Articles 7 and 8 of the Delegated Regulation are in its Title II, for the other financial entities.
EXAMPLE: 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 incident INC-2026-014, its Head of IT filled the matrix on 30 Sep 2026, with the Head of Risk coordinating. Of its 6 data sets, 4 fail at least one check: DS-02, DS-04, DS-05, DS-06.
Adapting this template
Settings: set the yellow values to your backup standard's. The copies rule is the 3-2-1-1-0 rule of thumb (BR-03): three copies, two kinds of storage, one copy offsite, one immutable or offline, none unverified. It is a practice used in industry, not a legal requirement. The recovery need of 35 days is the EXAMPLE's: P22 gives no figure, so set yours to reach a copy taken before an attacker's earliest sign (P22 RR-12).
Small organisation: six to ten data sets is usual. Start with the data each critical service needs, then the foundations: the sign-in directory, the network configuration, the backup catalogue and the build images. Keep every check: a small team is more likely to depend on one provider and one set of keys.
IT run by a service provider: enter the provider's backups as rows with the provider in the supplier column, and the interval the provider reports (BR-02). The restore time the provider commits to is a contract matter (BR-20), not a column here. Ask the provider for the results of its own restore checks.
Cloud and software-as-a-service data: where a provider runs the platform, its backup may not cover deleted items, changes made by an attacker or administrator errors (BR-19). Say Yes in Data Sets only where you keep your own copy outside the provider's account, or where the provider's commitment covers your recovery point and your retention.
Personal data: keeping backups longer than the longest need is a data protection risk as well as a cost. Set each retention from the three needs and record why (BR-05).
Financial entity: your own backup policy must set the scope and the minimum frequency of backup by the criticality of the data (DORA Article 12(1)). Confirm with counsel which DORA articles apply to you.
Settings
Settings
The values the checks read, and the counts they give. Yellow cells are yours to set from your backup standard; grey values are fixed by the rule named.
Settings the checks read
| Value | Setting | Rule |
|---|---|---|
| 30 Sep 2026 | As-at date: the day you read the matrix. Every restore check period counts back from it. EXAMPLE: 30 Sep 2026. | BR-04, BR-13 |
| 3 | At least this many copies of each data set, counting the live data. | BR-03 |
| 2 | At least this many kinds of storage or media. | BR-03 |
| 1 | At least this many copies offsite. | BR-03 |
| 1 | At least this many copies immutable or offline. | BR-03 |
| 35 | Days of retention the recovery need asks for: long enough to reach a copy taken before an attacker's earliest sign. P22 gives no figure; this is yours. | BR-05, P22 RR-12 |
| 6 | Months from a data set's first listing to its first test of a type other than TT-1. | BR-13 |
| 0 | Unverified copies of a critical data set allowed. A copy is verified when a restore of the data set passed its integrity check inside the period for its class. Check BC-05 fails otherwise. | BR-04 |
Restore test types, and the months between tests of each by class (BR-12, BR-13)
| Test type | Name | Counts as a test of | 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. | TT-1 | 3 | 6 | 12 |
| TT-2 | Full system restore. The system comes back from backup, and how long that takes, against the service's recovery time objective. | TT-1 TT-2 | 12 | 24 | |
| TT-3 | Full service end to end. The service works, within its objectives, with its dependencies in place. | TT-1 TT-2 TT-3 | 12 | ||
| 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. | TT-1 TT-2 TT-4 | 12 | ||
| 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. | TT-1 TT-5 | 12 | 24 |
A test of a higher type counts for the lower types it includes. Leave a cell blank where the class does not need the type. For a critical service, TT-2 to TT-5 are never less frequent than P22 RR-14 (BR-13).
Kinds of data set and the restore test types each needs (BR-12)
| Kind of data set | What it is | First type | Second type |
|---|---|---|---|
| System | A system you run or restore: a server, a platform or a database. | TT-1 | TT-2 |
| SaaS | A cloud or software-as-a-service tenant where you hold your own copy of the data. | TT-1 | TT-5 |
| Foundations | The directory, network configuration, backup catalogue and build images that every rebuild needs. | TT-1 | TT-4 |
| Provider-held | Data a provider holds with no copy of ours. Its recovery is tested through the provider's own recovery test (P22 RR-14). |
Classes (BR-13)
| Class | What it means |
|---|---|
| Critical | Loss would stop a critical service (P22 RR-01), or it is data the foundations need to be rebuilt (P22 RR-09). |
| Important | Loss would cause Major harm on the risk register's impact scale, and no critical service stops. |
| Other | Any other data set the organisation backs up. |
What the checks show, as at the as-at date (calculated)
| Check | What it tests | Pass | Fail | Not applicable | Data sets that fail |
|---|---|---|---|---|---|
| BC-01 | Listed and owned (BR-01) | 6 | 0 | 0 | None |
| BC-02 | Backed up as often as the recovery point (BR-02) | 3 | 2 | 1 | DS-02 DS-05 |
| BC-03 | Copies meet the rule (BR-03) | 5 | 1 | 0 | DS-05 |
| BC-04 | Retention meets the longest need (BR-05) | 4 | 1 | 1 | DS-04 |
| BC-05 | Restored and checked in time (BR-04) | 4 | 1 | 1 | DS-06 |
| BC-06 | Cloud and provider-held data covered (BR-19) | 2 | 1 | 3 | DS-05 |
Counts for the quarterly report: critical data sets only (BR-21)
| Measure | What it counts | Count | The others, named |
|---|---|---|---|
| BAM-01 | Backed up as often as the recovery point (BC-02), out of those with a recovery point | 3 of 5 | DS-02 DS-05 |
| BAM-02 | Copies rule met (BC-03) and no unverified copy (BC-05), out of all critical data sets | 4 of 6 | DS-05 DS-06 |
| BAM-05 | Restored and checked in time (BC-05), out of those with a copy of our own | 4 of 5 | DS-06 |
Counts only: no score, no share and no colour for the whole matrix (BR-21, P22 RR-20). Name every gap.
Data Sets
One row per data set (BR-01). A data set that is not listed is treated as not backed up.
Leave the interval blank where you hold no backup of your own. Leave the service and its recovery point blank for the foundations. Answer the last three questions only for cloud or provider-held data.
| Row | Data set ID | Data set | Class | Kind | Critical service it serves (ID) | That service's recovery point objective, hours | Data owner | Where it is held | How it is backed up | Supplier or administrator who runs the backup | Backed up every, hours | Kept for, days | Business need, days | Legal or contract need, days | Recovery need, days (calc) | First listed on | Cloud or provider-held: our own copy outside the provider's account? | Cloud or provider-held: provider's commitment covers the recovery point and retention? | Findings raised (IDs) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | DS-01 | Orders and customer accounts | Critical | System | CS-01 | 24 | Chief Operating Officer | Ordering platform database, hosted (P06 SUP-002) | Nightly backup to the backup service provider's platform, and an offline copy | Backup service provider (P06 SUP-011), with the IT Operations Manager | 24 | 35 | 30 | 35 | 30 Sep 2026 | BF-01 | |||
| EXAMPLE | DS-02 | Stock and dispatch records | Critical | System | CS-02 | 4 | Head of Logistics | Warehouse management system database (P07 SYS-02) | Daily backup to cloud object storage, and an offline copy | In-house, the IT Operations Manager | 24 | 35 | 14 | 35 | 30 Sep 2026 | BF-02 | |||
| EXAMPLE | DS-03 | Ledgers and payroll records | Critical | SaaS | CS-04 | 1 | Chief Financial Officer | ERP, hosted by the provider (P07 SYS-01, P06 SUP-004) | The provider's continuous backup, and a nightly export held offline | ERP software provider (P06 SUP-004), with the IT Operations Manager | 0.25 | 90 | 90 | 35 | 30 Sep 2026 | Yes | No | ||
| EXAMPLE | DS-04 | Email and office documents | Critical | SaaS | CS-05 | 24 | Sales Director | Email and office tenant (P06 SUP-005) | Daily export of the tenant to our backup storage, and a weekly offline copy | In-house, the IT Operations Manager | 24 | 30 | 30 | 35 | 30 Sep 2026 | Yes | No | BF-08 | |
| EXAMPLE | DS-05 | Card payment records | Critical | Provider-held | CS-03 | 0 | Chief Financial Officer | The payment service provider's platform (P06 SUP-003) | None of our own: the provider holds the data and the distributor holds no backup of it | Payment service provider (P06 SUP-003) | 30 Sep 2026 | No | No | BF-06 | |||||
| EXAMPLE | DS-06 | Directory, network configuration, backup catalogue and build images | Critical | Foundations | Head of IT | Sign-in directory, core network and firewalls, backup platform (P22 foundations) | Nightly backup of the directory, configuration and catalogue, and offline golden images and baselines | Managed IT service provider (P06 SUP-001) and the backup service provider (P06 SUP-011) | 24 | 90 | 90 | 35 | 30 Sep 2026 | BF-05 |
Copies
One row per copy of each data set, the live data included (BR-03). Copies of one data set that sit on the same kind of storage count once for the kinds rule.
An immutable copy cannot be changed or deleted with administrator credentials until its retention lock expires. An offline copy is disconnected except while it is written or restored (BR-07, BR-08).
| Row | Data set ID | Copy | Kind of storage or media | Offsite? | Immutable or offline? | First of its kind for the data set (calc) |
|---|---|---|---|---|---|---|
| EXAMPLE | DS-01 | Live data | Hosted disk | No | No | 1 |
| EXAMPLE | DS-01 | Nightly backup | Provider backup storage | Yes | No | 1 |
| EXAMPLE | DS-01 | Offline copy | Offline media | Yes | Yes | 1 |
| EXAMPLE | DS-02 | Live data | Server disk | No | No | 1 |
| EXAMPLE | DS-02 | Daily backup | Cloud object storage | Yes | No | 1 |
| EXAMPLE | DS-02 | Offline copy | Offline media | Yes | Yes | 1 |
| EXAMPLE | DS-03 | Live data | Provider primary storage | No | No | 1 |
| EXAMPLE | DS-03 | Provider's continuous backup | Provider backup storage | Yes | No | 1 |
| EXAMPLE | DS-03 | Nightly export | Offline media | Yes | Yes | 1 |
| EXAMPLE | DS-04 | Live tenant | Provider primary storage | No | No | 1 |
| EXAMPLE | DS-04 | Daily export | Cloud object storage | Yes | No | 1 |
| EXAMPLE | DS-04 | Weekly offline copy | Offline media | Yes | Yes | 1 |
| EXAMPLE | DS-05 | Provider's live data | Provider primary storage | No | No | 1 |
| EXAMPLE | DS-06 | Live configuration | Server disk | No | No | 1 |
| EXAMPLE | DS-06 | Nightly backup | Provider backup storage | Yes | No | 1 |
| EXAMPLE | DS-06 | Offline golden images and baselines | Offline media | Yes | Yes | 1 |
Restore Tests
Restore tests held, newest or oldest first. Only a test that restored data counts. A tabletop, a drill or any other exercise is not a restore test (P22 RR-14).
A restore from a hosted or provider-run service counts when the copy was checked for integrity first. P09 IM-10 asks for that check before any restore in an incident.
| Row | Test ID | Data set ID | Test type | Test date | Restored a backup? | Copy passed its integrity check before the restore? | What was restored | Also P22's recovery test (ID) | Counts as a test of (calc) |
|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | RT-01 | DS-03 | TT-5 | 20 Jan 2026 | No | Not applicable | The ERP provider's failover between its data centres, with results shared (P06 CON-05). It restores no backup. | RV-2026-01 | TT-1 TT-5 |
| EXAMPLE | RT-02 | DS-01 | TT-2 | 20 May 2026 | Yes | Pass | The ordering platform restored from its nightly backup into the hosting provider's spare environment | RV-2026-02 | TT-1 TT-2 |
| EXAMPLE | RT-03 | DS-03 | TT-5 | 15 Jul 2026 | Yes | Pass | A copy of the ledgers restored by the ERP provider into a test instance, and checked for integrity (P11 MC-35) | TT-1 TT-5 | |
| EXAMPLE | RT-04 | DS-02 | TT-2 | 27 Aug 2026 | Yes | Pass | The warehouse management system restored from backup and checked by the warehouse team | RV-2026-03 | TT-1 TT-2 |
| EXAMPLE | RT-05 | DS-04 | TT-1 | 10 Sep 2026 | Yes | Pass | A sample of mailboxes restored from the daily export and opened (P11 MC-35) | TT-1 | |
| EXAMPLE | RT-06 | DS-01 | TT-1 | 17 Sep 2026 | Yes | Pass | 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 | TT-1 |
Checks
Calculated for each data set on the Data Sets sheet, as at the Settings sheet's date. Nothing here is typed: change the inputs on the other sheets. A failed check is a finding (BR-18).
Not applicable means the check does not apply to the data set. The next test of each type is due by the date shown: a test of a higher type counts for the lower types it includes (BR-12).
| Row | Data set ID | Data set | Class | Kind | BC-01: Listed and owned | BC-01 note | BC-02: Backed up as often as the recovery point | BC-02 note | BC-03: Copies meet the rule | BC-03 note | BC-04: Retention meets the longest need | BC-04 note | BC-05: Restored and checked in time | BC-05 note | BC-06: Cloud and provider-held data covered | BC-06 note | Last restore checked | Next restore check (TT-1) due | Other test type needed | Next test of that type due | Failed checks |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | DS-01 | Orders and customer accounts | Critical | System | Pass | Listed with owner, class, location, method and supplier | Pass | Every 24 h, against a recovery point of 24 h | Pass | 3 copies, 3 kinds, 2 offsite, 1 immutable or offline | Pass | 35 days kept, the longest need is 35 days | Pass | Last restore checked 17 Sep 2026 | Not applicable | Not provider-held | 17 Sep 2026 | 17 Dec 2026 | TT-2 | 20 May 2027 | None |
| EXAMPLE | DS-02 | Stock and dispatch records | Critical | System | Pass | Listed with owner, class, location, method and supplier | Fail | Every 24 h, against a recovery point of 4 h | Pass | 3 copies, 3 kinds, 2 offsite, 1 immutable or offline | Pass | 35 days kept, the longest need is 35 days | Pass | Last restore checked 27 Aug 2026 | Not applicable | Not provider-held | 27 Aug 2026 | 27 Nov 2026 | TT-2 | 27 Aug 2027 | BC-02 |
| EXAMPLE | DS-03 | Ledgers and payroll records | Critical | SaaS | Pass | Listed with owner, class, location, method and supplier | Pass | Every 0.25 h, against a recovery point of 1 h | Pass | 3 copies, 3 kinds, 2 offsite, 1 immutable or offline | Pass | 90 days kept, the longest need is 90 days | Pass | Last restore checked 15 Jul 2026 | Pass | A copy of our own outside the provider's account | 15 Jul 2026 | 15 Oct 2026 | TT-5 | 15 Jul 2027 | None |
| EXAMPLE | DS-04 | Email and office documents | Critical | SaaS | Pass | Listed with owner, class, location, method and supplier | Pass | Every 24 h, against a recovery point of 24 h | Pass | 3 copies, 3 kinds, 2 offsite, 1 immutable or offline | Fail | 30 days kept, the longest need is 35 days | Pass | Last restore checked 10 Sep 2026 | Pass | A copy of our own outside the provider's account | 10 Sep 2026 | 10 Dec 2026 | TT-5 | 30 Mar 2027 | BC-04 |
| EXAMPLE | DS-05 | Card payment records | Critical | Provider-held | Pass | Listed with owner, class, location, method and supplier | Fail | No backup of our own, against a recovery point of 0 h | Fail | 1 of 3 copies; 1 of 2 kinds of storage; 0 of 1 offsite; 0 of 1 immutable or offline | Not applicable | No backup of our own, so no retention to check | Not applicable | The provider holds the data; there is no copy of ours to restore | Fail | No copy of our own, and the provider's commitment does not cover the need | Not applicable | Not applicable | None required | Not applicable | BC-02 BC-03 BC-06 |
| EXAMPLE | DS-06 | Directory, network configuration, backup catalogue and build images | Critical | Foundations | Pass | Listed with owner, class, location, method and supplier | Not applicable | No service recovery point: the foundations' backups serve every rebuild | Pass | 3 copies, 3 kinds, 2 offsite, 1 immutable or offline | Pass | 90 days kept, the longest need is 90 days | Fail | Never restored and checked | Not applicable | Not provider-held | Never | 30 Dec 2026 | TT-4 | 30 Mar 2027 | BC-05 |
Lists
| Class | Kind | YesNo | TestType | Integrity |
|---|---|---|---|---|
| Critical | System | Yes | TT-1 | Pass |
| Important | SaaS | No | TT-2 | Fail |
| Other | Foundations | TT-3 | Not applicable | |
| Provider-held | TT-4 |
TT-5
Definitions
Definitions
| Term | Meaning in this workbook |
|---|---|
| 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). |
| Data owner | The manager accountable for a data set. For the data a critical service needs, this is the service's business owner (P22 RR-02). |
| 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). |
| 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. |
| Copy | One stored version of a data set. The live data counts as one copy. |
| Immutable copy | A copy that nobody can change or delete, with administrator credentials or otherwise, until its retention lock expires (BR-08). |
| Offline copy | A copy that is disconnected from every network except while it is written or restored (BR-07). |
| 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). |
| 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). |
| 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). |
| 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). |
| Cloud and software-as-a-service data | Data the organisation holds in a cloud or software-as-a-service system, where the provider runs the platform. The provider's backup may not cover deleted items, changes made by an attacker or administrator errors (BR-19). |
| Foundations | What every other recovery needs first: the sign-in directory, the core network and firewalls, the backup platform, endpoint protection and monitoring, and the emergency administrator accounts. |
| BC-01 Listed and owned | The data set has an owner, a class, a location, a backup method, an interval and a supplier or administrator (BR-01). |
| BC-02 Backed up as often as the recovery point | The backup interval is no longer than the recovery point of the service that needs the data set (BR-02). |
| BC-03 Copies meet the rule | At least the minimum copies, kinds of storage, offsite copies and immutable or offline copies (BR-03). |
| BC-04 Retention meets the longest need | The retention set is at least the longest of the business, legal and recovery needs (BR-05). |
| BC-05 Restored and checked in time | A restore of the data set was checked for integrity within the restore check period for its class, so no copy is unverified (BR-04). |
| BC-06 Cloud and provider-held data covered | Where a provider holds the data, the organisation keeps its own copy outside the provider's account, or the provider's commitment covers the recovery point and the retention (BR-19). |
| TT-1 to TT-5 | The restore test types, with what each proves, on the Settings sheet (BR-12). |
| As-at date | The day the matrix is read, on the Settings sheet. Every restore check period counts back from it. |
| DS-nn, RT-nn, BF-nn | The IDs of a data set, a restore test and a finding. Keep them stable: the Restore Test Workbook, the Backup Failure & Restore Findings Tracker and the Backup Assurance Dashboard use the same IDs. |
| BR-nn, BP-nn, TT-n | The rules of the Restore Testing Methodology, BR-01 to BR-22; the controls of the Immutable & Offline Backup Protection Checklist; and the restore test types. |
| P22 RR-nn | The rules of P22: recovery objectives, the recovery test of each critical service (RR-14) and the reporting rule (RR-20). P22 owns them. |
| P09 C3, C4, D3 | Steps of P09's Ransomware Response Playbook: stop backup jobs, protect the backups, and check that the backups are intact. P09 owns incident response. |
| (calc) | A column or cell the workbook calculates. Do not type or paste over it. |
| 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 approval. |
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 whole workbook: a backup of each data set, with the checks that find the gaps |
| NIST CSF 2.0 | PR.DS-11 — “Backups of data are created, protected, maintained, and tested” | Data Sets, Copies and Checks sheets: 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 workbook: which data sets are backed up, how, and whether a restore has proved the copy |
| 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 | The Implementing Regulation applies only to the providers its Article 1 names. For them, the Annex points below; other entities may use them as good practice |
| NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.2.1 — “The relevant entities shall maintain backup copies of data and provide sufficient available resources, including facilities, network and information systems and staff, to ensure an appropriate level of redundancy.” | Data Sets and Copies sheets: a backup copy of each data set, and the redundancy that check BC-03 reads |
| 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” | Checks BC-02 to BC-06: recovery times, copies kept online or offline, retention periods, complete and accurate copies, and data in cloud environments |
| NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 4.2.4 — based on the risk assessment (point 2.1) and the business continuity plan, “sufficient availability of resources by at least partial redundancy” of network and information systems; assets, including facilities, equipment and supplies; personnel with the necessary responsibility, authority and competence; and appropriate communication channels | Copies sheet and check BC-03: the redundancy the copies give, on more than one kind of storage and offsite |
| 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 | Data Sets sheet, for financial entities: the scope of each backup and its minimum frequency, set by the criticality of the data |
| DORA — Regulation (EU) 2022/2554 | Article 12(4) — “Financial entities, other than microenterprises, shall maintain redundant ICT capacities equipped with resources, capabilities and functions that are adequate to ensure business needs.” Microenterprises assess the need for such capacities on their risk profile | Copies sheet, for financial entities: the redundancy the copies give. Microenterprises assess the need on their risk profile |
| 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.” | Data Sets sheet and check BC-02, for financial entities: each backup interval read against the recovery point of the service that needs the data |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 39(2)(g) — for the entities of DORA Article 16(1), the ICT business continuity plans “identify backup procedures and measures that specify the scope of the data that are subject to the backup, and the minimum frequency of the backup, based on the criticality of the function using those data” | Data Sets sheet, for the entities of DORA Article 16(1): the scope of each backup and its minimum frequency, based on the criticality of the function that uses the data |
| GDPR — Regulation (EU) 2016/679 | Article 5(1)(e) — personal data are “kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed”, with longer storage allowed only for archiving, research or statistical purposes under the conditions of Article 89(1) | Data Sets sheet and check BC-04: retention is set from the need, and nothing is kept longer without a recorded reason (BR-05) |
| 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” | Check BC-05 and Restore Tests sheet: whether personal data can be restored in a timely manner |
| 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” | Copies sheet and check BC-03: the offline question and the 3-2-1 rule, which are separate tests |
| NIST SP 800-209 (October 2020) | Section 4.2.1, DP-SS-R1 — a data protection plan or policy that includes, at the minimum, “Tiering, frequency, and number of copies specification, to meet organization recovery goals”, the types of media, encryption requirements including “Encryption key retention and key rotation”, “immutability and locking, minimum number of copies per backup set”, lifecycle management including “affirmative deletion of no longer needed ones”, and restore procedures | Data Sets and Copies sheets: frequency, number of copies, retention and immutability recorded for each data set |
| NIST SP 800-209 (October 2020) | Section 4.8, RA-SS-R1 — “All storage elements that contain components of critical data assets should be protected and backed up”, including storage volumes, critical file systems, databases, software images, certificates, encryption keys, startup files, catalog info, ACLs, virtualization settings and configuration files | Data Sets sheet: the foundations row lists the directory, configuration and catalogue that a restore needs (BR-10) |
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.
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 NIS2 Implementing Regulation binds only the providers its Article 1 names. DORA binds financial entities only; the entities of its Article 16(1) follow Article 16(1)(f) and Delegated Regulation Articles 39 and 40 instead of Articles 11 and 12.