Backup Failure & Restore Findings Tracker

Tracks failed jobs and restore-test findings to resolution.

Available soon

Format: Excel
Size: 84 KB
Length: 11 sheets
Version: 1.0
Updated: 2 Oct 2026

Follow this documentFree account. We can email you when it changes.

What's inside

Instructions
Findings
Failed jobs
Counts
Raising findings
Lists
Definitions
Framework References

What changed

1.02 Oct 2026
Published.

Changes across this pack

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 tracker is. Every failed criterion, failed check, unmet protection control and repeated job failure is a finding with an owner, a severity and a due date. It also logs every failed backup job (BR-11). The resilience coordinator keeps it (BA-12). The Backup Coverage & Retention Matrix, Restore Test Workbook and Immutable & Offline Backup Protection Checklist raise findings; the Backup Assurance Dashboard reads the counts from this tracker.
2	Start on the Counts sheet. Set the as-at date, the period for counting jobs, the days to fix each severity and the hours allowed for each class. Enter each data set whose jobs you count, with the number of jobs that ran in the period.
3	Log each failed job on the Failed jobs sheet, one row for each failure. Give it a failure ID, the data set, its class and the recovery point of the service that needs it. Enter when the job failed, when it was found, the last good copy before it and, when it exists, the good copy after it. Leave "Good copy again" empty until a new complete copy exists.
4	A job stopped on the incident manager's instruction under P09 C3 is not a failure: do not log it here. P09's steps decide when it restarts (BR-11).
5	Read the calculated columns. A fix later than the hours allowed for the class is escalated to [[the backup owner]]. A failure that took the data set outside its recovery point needs the data owner told the same day (BR-11). 2 failures in a row on one data set are raised as a finding.
6	Raise a finding on the Findings sheet for every failed criterion, failed check, unmet or unchecked protection control and repeated job failure. The Raising findings sheet lists what raises one and the severity each protection control takes. Give it an ID (BF-nn), the date found, the owner, a severity from the list, the fix and a due date.
7	Agree the plan within 10 working days (BR-18). Enter the date you agreed it. The Plan check column turns to "Plan overdue (BR-18)" when the date passes with no plan.
8	Keep the due date within the days the severity allows: High 90, Medium 180, Low 365. A later date is accepted only when a linked plan sets it: a P22 objective gap (P22 OG-nn), a P19 action (P19 MP-nn) or a P05 treatment action (P05 TA-nn). Type its ID in "Linked plan, gap or action". A finding that is also an objective gap keeps the date P22 RR-15 sets.
9	Tell the owner of the risk it bears on about every High finding, so the risk is reassessed (P05 RM-10).
10	Mark a finding "Fixed, awaiting retest" when the owner says the fix is done. Close it only when a retest or new evidence shows the fix works, then enter the retest and the closing date (BR-18). A tabletop or a drill is not a restore test (P22 RR-14): never close a finding with one.
11	Read the Counts sheet for the counts: jobs that ran, failed and were fixed in time, and findings by severity, past due and awaiting retest. It names every open High finding and every past due finding. Report counts with every gap named, and no score or share (BR-21, P22 RR-20).
12	Chase due dates [[each week]], and review the whole tracker at least [[each month]]. To clear the EXAMPLE, delete the EXAMPLE rows once your own are entered. The formulas stay.

Legend

Yellow cells are inputs. Everything else is calculated or fixed — do not overwrite formulas.

EXAMPLE

Rows marked EXAMPLE in the first column show how a completed row looks. Delete them before approval.

Limitations: This document helps you set up backups, protect them and prove that they restore. It is not legal advice, and following it is not a statement that you comply with NIS2, DORA, the GDPR or any standard. Which backup and testing duties apply to you depends on your sector and your national law: confirm them with counsel or your supervisor.

Why a tracker: Backup success is not recovery success. A backup job that finished says only that the job wrote something. It says nothing about whether the data restores, whether it restores within the time the service can wait, or whether the copy is one an attacker holding your administrator credentials could not have reached and deleted first. Only a restore shows that the copy is complete, that it opens, that the keys to it still exist, and how long recovery takes. Attackers look for the backups first, so protecting the copies and proving the restore are one piece of work.

This tracker records and chases. It does not decide anything P09 decides: which backup to restore from (P09 D3), when a system is clean (P09 IM-10), and the stopping and protecting of backups in an incident (P09 C3, C4).

EXAMPLE: the distributor of the worked example, an important entity under NIS2 in its Member State and not a financial entity, so DORA's reporting duties do not apply. Its backup owner is its Head of IT. Its Head of Risk, who runs no system in scope, keeps the tracker. The baseline was taken on 30 Sep 2026 after INC-2026-014: 8 findings, and the three failed jobs of September 2026. As at 30 Sep 2026.

Adapting this template:

• Replace the [[placeholders]] with your own values, and delete the EXAMPLE rows once you have entered your own. The formulas stay.

• Change the days to fix, the hours allowed for each class and the number of repeat failures on the Counts sheet only if your backup standard sets different ones. Keep them at least as strict as your standard (BR-11, BR-18).

• Use your own finding numbers if your risk or audit tracker has a scheme. Keep one ID for each finding for its whole life.

• Add your own columns to the right of the calculated ones, so the layout stays the same as the Counts sheet expects.

• If one tracker already holds your audit findings, you may keep these findings there. Keep the columns this workbook calculates, so each finding still shows its plan date, its latest fix date and whether it is past due.

This workbook is your own record. Keep a copy that can be reached when the main systems are down (P22 RR-16, BR-22).

Findings

EXAMPLE: 8 findings as at 30 Sep 2026. Yellow columns are inputs; white columns calculate. One row for each finding (BR-18). Every failed criterion, failed check, unmet protection control and repeated job failure is a finding.

Example	Finding ID	Date found	What was found	Raised by (failed criterion, check or control)	Severity	Owner	The fix	Due date	Linked plan, gap or action (separated by commas)	Status	Retest planned or done	Plan due (BR-18, calc)	Latest fix date for its severity (calc)	Due date set by a linked plan (calc)	Plan check (calc)	Due date check (calc)	Severity limit check (calc)	Order among open High findings (calc)
EXAMPLE	BF-01	30 Sep 2026	The ordering platform took 4 days to restore in the May full restore test. Its recovery time objective is 24 hours.	RT-02 TC-03	High	Head of IT	Rebuild the platform's recovery (P05 TA-01), then retest end to end (RV-2027-04)	15 Dec 2026	P22 OG-01, P05 TA-01, P12 GAP-03	Open		14 Oct 2026	29 Dec 2026	Yes	Plan not yet due	Not yet due	Within its severity limit	1
EXAMPLE	BF-02	30 Sep 2026	The warehouse management system's August restore lost 24 hours of data. Dispatch can lose at most 4 hours.	RT-04 TC-04, DS-02 BC-02	High	Head of IT	Back up the warehouse database every 4 hours (P22 OG-05), then retest the recovery point (RT-2026-11)	15 Dec 2026	P22 OG-05	Open	RT-2026-11 (planned)	14 Oct 2026	29 Dec 2026	Yes	Plan not yet due	Not yet due	Within its severity limit	2
EXAMPLE	BF-03	30 Sep 2026	The backup console signs in through the production directory, so an attacker with directory administrator rights could reach it.	BP-01	Medium	Head of IT	Move backup administration to accounts held outside the production directory, with multi-factor authentication	29 Jan 2027	P19 MP-24	Open		14 Oct 2026	29 Mar 2027	Yes	Plan not yet due	Not yet due	Within its severity limit
EXAMPLE	BF-04	30 Sep 2026	The online backup copies carry no retention lock. The offline copy is the only copy that production credentials cannot delete.	BP-09	Medium	Head of IT	Turn on a retention lock for the full retention of each online copy	29 Jan 2027	P19 MP-24	Open		14 Oct 2026	29 Mar 2027	Yes	Plan not yet due	Not yet due	Within its severity limit
EXAMPLE	BF-05	30 Sep 2026	The backups of the directory, the network configuration and the backup catalogue have never been restored and checked.	DS-06 BC-05	Medium	Head of IT	Restore them into an isolated environment (RT-2026-10), then rebuild the foundations as a test (RV-2027-03)	30 Dec 2026	P22 RV-2027-03	Open		14 Oct 2026	29 Mar 2027	No	Plan not yet due	Not yet due	Within its severity limit
EXAMPLE	BF-06	30 Sep 2026	The distributor holds no copy of the card payment records, and the payment provider's contract gives no recovery time.	DS-05 BC-02, DS-05 BC-03, DS-05 BC-06, BP-15	Medium	Chief Financial Officer	Have the provider's recovery test checked against the objective, ask for a restore commitment in the contract, and record the Chief Financial Officer's decision on keeping a copy	13 Jan 2027	P22 OG-07, P06 SUP-003	Open		14 Oct 2026	29 Mar 2027	Yes	Plan not yet due	Not yet due	Within its severity limit
EXAMPLE	BF-07	30 Sep 2026	The backup service provider's contract gives no recovery time, and its console, approval rules and encryption have not been checked.	BP-03, BP-04, BP-10	Medium	Procurement Manager	Check the three controls and agree a restore time at the provider's assessment (P06 SUP-011)	3 Nov 2026	P22 OG-02, P06 SUP-011	Open		14 Oct 2026	29 Mar 2027	Yes	Plan not yet due	Not yet due	Within its severity limit
EXAMPLE	BF-08	30 Sep 2026	The email and office backup keeps 30 days. A copy from before an attacker's earliest sign may be older.	DS-04 BC-04	Medium	Head of IT	Raise the retention of the daily export to the longest need	13 Nov 2026		Open		14 Oct 2026	29 Mar 2027	No	Plan not yet due	Not yet due	Within its severity limit

Failed jobs

EXAMPLE: 3 failed backup jobs, 1 Sep 2026 to 30 Sep 2026. One row for each failure (BR-11). Dates and times are local. A job stopped under P09 C3 is not a failure.

Example	Failure ID	Data set ID	Data set	Class	Recovery point of its service (hours; empty for the foundations)	Failed	Failure found	Cause	Last good copy before it	Good copy again	Data owner told on	Failures in a row on this data set	Status	Hours from failure to a good copy (calc)	Hours allowed for its class (BR-11, calc)	Fixed in time check (calc)	Hours without a good copy (calc)	Recovery point check (BR-02, calc)	Data owner check (calc)
EXAMPLE	FJ-2026-09-01	DS-02	Stock and dispatch records	Critical	4	8 Sep 2026	8 Sep 2026	No space on the backup target	7 Sep 2026	8 Sep 2026	8 Sep 2026	1	Closed	13.83	24	Fixed in time	37.67	Outside the recovery point	Data owner told
EXAMPLE	FJ-2026-09-02	DS-04	Email and office documents	Critical	24	16 Sep 2026	16 Sep 2026	The provider limited the export	15 Sep 2026	16 Sep 2026	16 Sep 2026	1	Closed	18.25	24	Fixed in time	42.08	Outside the recovery point	Data owner told
EXAMPLE	FJ-2026-09-03	DS-01	Orders and customer accounts	Critical	24	29 Sep 2026	29 Sep 2026	A network interruption between the platform and the backup service	28 Sep 2026	29 Sep 2026	29 Sep 2026	1	Closed	11.5	24	Fixed in time	35.67	Outside the recovery point	Data owner told

Counts

Settings and counts

Set the yellow cells, then read the counts. Each count is a number with the others named: no score and no percentage (BR-21, P22 RR-20). The Backup Assurance Dashboard reads them.

Settings

As-at date	30 Sep 2026	Past due is worked out at this date. EXAMPLE: 30 Sep 2026. Type a date, never a formula.
Working days to agree the plan for a finding (BR-18)	10	Monday to Friday. Public holidays are yours to allow for.
Failures in a row on one data set that raise a finding (BR-11)	2
Counting period: from	1 Sep 2026	The period the job counts below cover, such as a month or a quarter.
Counting period: to	30 Sep 2026

Severity: days to fix (BR-18)

Severity	Days to fix	Meaning
High	90	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.
Medium	180	A weakness that other protection backs up.
Low	365	An improvement, tracked to the next review.

Class: hours from a failure to a good copy again (BR-11)

Class	Hours	Meaning
Critical	24	Loss would stop a critical service (P22 RR-01), or it is data the foundations need to be rebuilt (P22 RR-09).
Important	72	Loss would cause Major harm on the risk register's impact scale, and no critical service stops.
Other	168	Any other data set the organisation backs up.

Backup jobs in the period, by data set

Data set ID	Jobs that ran	Jobs that failed	Fixed in time
DS-01	30	1	1
DS-02	30	1	1
DS-04	30	1	1
DS-06	30	0	0

Enter the number of jobs that ran from the backup system's report. The ERP provider's continuous backup, which has no job count, is not listed. A data set with no failure shows 0.

Counts for the report (BR-21)

Measure	Count	What it counts
BAM-04: Jobs that ran in the period	120	The jobs entered above.
BAM-04: Jobs that failed	3	Failures logged with a failure date in the counting period.
BAM-04: Failed jobs fixed within their time	3	A good copy existed again within the hours allowed for the class (BR-11).
BAM-04: Failed jobs still open	0	Not yet marked Closed on the Failed jobs sheet.
BAM-04: Failed jobs that took a data set outside its recovery point	3	The data set went without a good copy for longer than its service's recovery point (BR-02).
BAM-04: Failed jobs with a repeat failure to raise as a finding	0	2 or more failures in a row on one data set (BR-11).
BAM-08: Findings not yet closed	8	Every finding whose status is not Closed.
BAM-08: of which High	2	Open findings of High severity.
BAM-08: of which Medium	6	Open findings of Medium severity.
BAM-08: of which Low	0	Open findings of Low severity.
BAM-08: Findings awaiting retest	0	The owner says the fix is done; the retest has not passed.
BAM-08: Findings past their due date	0	Open findings whose due date is before the as-at date.
BAM-08: Findings with no agreed plan past the plan date	0	No plan agreed, and the plan date has passed.
BAM-08: Findings due later than their severity allows	0	A due date later than the severity allows, with no linked plan to set it.
BAM-08: Findings closed	0	Closed with a retest or new evidence.

The jobs table above and the jobs counts here agree when every failed job's data set is listed in the table.

Findings to name in the report (BR-21)

Order	Open High finding	Due	Past due finding	Due
1	BF-01	15 Dec 2026
2	BF-02	15 Dec 2026

The first 6 of each. Name every one in the report if there are more (BR-21).

Raising findings

What raises a finding, and at what severity

Every failed criterion, failed check, unmet protection control and repeated job failure is a finding with an owner, a severity and a due date. A protection control that is "Not checked" is a finding too, because an unchecked protection is an unproven one. Severity for a failed criterion or check is the owner's choice, using the meanings on the Counts sheet. Each protection control carries the severity below.

ID	What failed	Rule	Severity	Comes from
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	Owner sets it	Coverage matrix
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	Owner sets it	Coverage matrix
BC-03	Copies meet the rule. At least the minimum copies, kinds of storage, offsite copies and immutable or offline copies.	BR-03	Owner sets it	Coverage matrix
BC-04	Retention meets the longest need. The retention set is at least the longest of the business, legal and recovery needs.	BR-05	Owner sets it	Coverage matrix
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	Owner sets it	Coverage matrix
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	Owner sets it	Coverage matrix
TC-01	Restore completed. Everything in scope was restored.	BR-14	Owner sets it	Test workbook
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).	BR-14	Owner sets it	Test workbook
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).	BR-14	Owner sets it	Test workbook
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).	BR-14	Owner sets it	Test workbook
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).	BR-14	Owner sets it	Test workbook
TC-06	Evidence recorded. The record holds the copy used, start and end times, the checks made and who made them (BR-17).	BR-14	Owner sets it	Test workbook
BP-01	Backup administrator accounts are not in the production sign-in directory.	BR-06	Medium	Protection checklist
BP-02	Backup administrator accounts are named, used only for backup administration, and reviewed at planned intervals.	BR-06	Medium	Protection checklist
BP-03	The backup system and its storage consoles require multi-factor authentication.	BR-06	High	Protection checklist
BP-04	Shortening or removing a retention lock, or deleting a backup set, needs two named people.	BR-08	High	Protection checklist
BP-05	The backup storage and the systems that manage it cannot be reached from user or server networks with ordinary or production credentials.	BR-07	High	Protection checklist
BP-06	The offline copy is connected only while it is written or restored, and each connection is recorded.	BR-07	High	Protection checklist
BP-07	No backup storage is mounted or mapped on a production system.	BR-07	Medium	Protection checklist
BP-08	At least one copy of each critical data set is immutable or offline.	BR-03	High	Protection checklist
BP-09	Each online copy that counts as immutable carries a retention lock for its full retention period.	BR-08	Medium	Protection checklist
BP-10	Backups are encrypted wherever they leave the organisation's control.	BR-09	Medium	Protection checklist
BP-11	The keys and recovery credentials for the backup system are kept outside the backed-up estate, with at least two named people able to reach them when production is down.	BR-09	High	Protection checklist
BP-12	Deleting a backup set, changing retention or changing the backup administrators raises an alert to someone outside backup administration.	BR-06	Medium	Protection checklist
BP-13	Every backup job reports to a named person, and the results are reviewed each working day.	BR-11	Medium	Protection checklist
BP-14	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.	BR-22	Medium	Protection checklist
BP-15	For each cloud or software-as-a-service system holding a critical data set, what the provider backs up and for how long is recorded, with the organisation's own copy where that falls short.	BR-19	Medium	Protection checklist
Jobs	2 failures in a row on one data set. A failed job not fixed in the hours its class allows is escalated, not raised as a finding (BR-11).	BR-11	Owner sets it	Failed jobs sheet

Statuses of a finding

Status	Meaning
Open	Raised. The plan is not yet agreed, or the fix is in progress.
Fixed, awaiting retest	The owner says the fix is done. The retest has not passed.
Closed	A retest or new evidence shows the fix works (BR-18).

EXAMPLE: the baseline raised 8 findings from 6 data sets, six restore tests and 15 protection controls.

Logging a failed job

	Column	What to enter
1	Failed	The date and time the job failed, from the backup system's log.
2	Failure found	When someone saw the failure. The gap between the two shows how long a failure goes unseen.
3	Last good copy before it	The date and time of the last copy that completed. The recovery point is measured from here.
4	Good copy again	The date and time a new complete copy existed. Leave it empty until then.
5	Class and recovery point	The data set's class sets the hours allowed. The recovery point of the service that needs the data set decides whether the failure took it outside its recovery point. Leave the recovery point empty for the foundations, which serve every rebuild.
6	Failures in a row	How many jobs in a row failed on this data set, counting this one. A repeat is a finding.

Lists

Severity	FindingStatus	Class	JobState
High	Open	Critical	Open
Medium	Fixed, awaiting retest	Important	Closed
Low	Closed	Other

Definitions

Definitions

Term	Meaning in this workbook
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).
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.
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).
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).
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).
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).
Failure ID	One failed backup job. A job that was stopped on the incident manager's instruction under P09 C3 is not a failure.
Good copy again	The time a new complete copy of the data set existed after a failure. Until then the data set has no current backup.
Hours without a good copy	The hours from the last good copy before the failure to the good copy after it. If this is longer than the recovery point of the service that needs the data set, the failure took it outside its recovery point (BR-02).
Plan due	The date 10 working days after the finding was raised, counting Monday to Friday. The owner agrees the plan by then (BR-18).
Latest fix date	The date found plus the days the severity allows. A finding linked to a plan with its own date may be later.
Past due	Not closed, and the due date is before the as-at date.
Awaiting retest	The owner says the fix is done. A retest or new evidence must still show it works before the finding closes.
Objective gap	A critical service whose recovery objective cannot be met. P22 RR-15 records it and sets its date. A finding that is also an objective gap is linked to it.
As-at date	The date past due is worked out at.
(calc)	A column or cell the workbook calculates. Do not type or paste over it.
BF-nn, FJ-nn, BR-nn	Findings and failed jobs in this tracker, and the rules of the Restore Testing Methodology. BC- is a check of the Backup Coverage & Retention Matrix, TC- a pass criterion of the Restore Test Workbook, BP- a control of the Immutable & Offline Backup Protection Checklist.
EXAMPLE	A worked example: the distributor's findings and failed jobs as at 30 Sep 2026. Delete before use.

Framework References

Framework references

These references indicate relevance only and do not reproduce the text of any standard.

Framework	Reference	Supported by
ISO/IEC 27001:2022	Annex A 8.13 — Information backup	Findings and Failed jobs sheets: failed backup jobs and restore findings followed to a fix, and counted
NIST CSF 2.0	PR.DS-11 — “Backups of data are created, protected, maintained, and tested”	Findings, Failed jobs and Counts sheets: backups that are maintained and tested, with each fault found followed to closure
NIS2 — Directive (EU) 2022/2555	Article 21(2)(c) — “business continuity, such as backup management and disaster recovery, and crisis management”	Findings and Failed jobs sheets: failed backup jobs and restore findings tracked to closure, as part of backup management
NIS2 — Implementing Regulation (EU) 2024/2690	Article 1 — lays down the technical and methodological requirements of the Article 21(2) measures, and further specifies when an incident is significant, for DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers	Applies only to the providers its Article 1 names. For them, the Annex point below; others may use it as good practice
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.”	Findings sheet: where a recovery test finds a fault, the corrective action, its owner and its date. The Restore Test Workbook documents the results. For the providers Article 1 names (NIS2 IR 1)
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.”	Findings sheet, for financial entities: faults found when testing backup and restoration procedures, kept until fixed
DORA — Delegated Regulation (EU) 2024/1774	Article 40(3) — the results of the testing are documented, and identified deficiencies “shall be analysed, addressed, and reported to the management body”	Findings and Counts sheets, for financial entities: deficiencies found in testing, each with an owner and a due date, counted for reporting to the management body
GDPR — Regulation (EU) 2016/679	Article 32(1)(d) — the security measures include, as appropriate, “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing”	Findings sheet: findings from regular tests of the backup measures, each followed to a fix and a retest
NIST SP 800-209 (October 2020)	Section 4.8, RA-SS-R12 — the recommendations are reviewed in a periodic audit; “Gaps should be identified, tracked, and remediated.” The frequency “should match sensitivity and value of protected data, but no less than once per year”, and audit results should be documented	Findings sheet: gaps identified, tracked and remediated, with the results documented. Guidance only

Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2022/2554 (DORA) and Delegated Regulation (EU) 2024/1774; Regulation (EU) 2016/679 (GDPR); NIST SP 800-209 (October 2020); NCSC (UK) blog post "Offline backups in an online world" (2019)

ISO/IEC 27001 references name the clause or control this document relates to, by number and title only. They do not say that meeting one meets any other framework's requirement.

These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard.

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.

NIST SP 800-209 and the NCSC post are guidance. They bind nobody, and an organisation may weigh each recommendation against its own risks.