Batch Register

Backup restore test

The shortest fixed clock in the held texts is 8,760 hours (yearly), set by DORA Art. 25. Paste one job that feeds this consumer, for example backup_restore_test, weekly, and the register reads its period against the clocks below, names the gap in hours, and carries the question for its owner.

Matched on the job name or the consumer column by these words: restore test, recovery test, restore drill, backup test, dr test, recovery drill, restore verif, restoration test, restore test, DR test.

The clock each rule sets

RegimeClockClause
ISO 27001no clockISO 27001 8.13 Information backupregularly test
SP 800-53no clockSP 800-53 CP-4 Contingency plan testinga defined frequency
HIPAAno clockHIPAA 164.308(a)(7)(ii)(D) Testing and Revision Procedures (Addressable)periodic
DORA8,760hDORA Art. 25 Testing of ICT tools and systemscritical ICT systems tested at least yearly
no clockDORA Art. 11 Response and recoveryregular testing
ISO 22301no clockISO 22301 8.5 Exercise programmeplanned intervals
NIS2no clockNIS2 Art.21.2.c Business continuity, backup management, disaster recovery and crisis management

Questions this page answers

How often does ISO/IEC 27001:2022 require backup restore test?

The held text of ISO 27001 8.13 (Information backup) sets no fixed period: regularly test. Maintain and regularly test backups of information, software and systems per the backup policy.

How often does NIST SP 800-53 Rev 5 require backup restore test?

The held text of SP 800-53 CP-4 (Contingency plan testing) sets no fixed period: a defined frequency. Requires the contingency plan to be tested at a defined frequency using defined test types to establish that the plan works and that people are ready to execute it, the test results to be reviewed, and corrective action to be initiated where the test shows it is needed.

How often does HIPAA Security Rule require backup restore test?

The held text of HIPAA 164.308(a)(7)(ii)(D) (Testing and Revision Procedures (Addressable)) sets no fixed period: periodic. Implement procedures for periodic testing and revision of contingency plans. NIST recommends annual tabletop, biennial functional, and post-incident lessons-learned updates.

How often does DORA (Regulation (EU) 2022/2554) require backup restore test?

Yearly (8,760 hours): DORA Art. 25, Testing of ICT tools and systems. The held text of DORA Art. 11 (Response and recovery) sets no fixed period: regular testing. The testing programme shall include a range of assessments and tests (e.g. vulnerability assessments and scans, open-source analyses, network security assessments, gap analyses, physical security reviews, questionnaires, source-code reviews, scenario-based tests, compatibility/performance tests, end-to-end and penetration testing), with critical ICT systems tested at least yearly. Financial entities shall put in place an ICT business continuity policy and ICT response and recovery plans (including measures, procedures and arrangements) to ensure continuity of critical or important functions, quickly contain damage, resume activities and recover, subject to regular testing.

How often does ISO 22301:2019 require backup restore test?

The held text of ISO 22301 8.5 (Exercise programme) sets no fixed period: planned intervals. Implement and maintain a programme of exercising and testing that validates the effectiveness of the continuity strategies and solutions over time, running exercises and tests consistent with the continuity objectives, based on well planned scenarios with clearly defined aims, that build teamwork, competence, confidence and knowledge in those with response roles, that taken together over time validate the strategies and solutions, that produce formal post exercise reports with outcomes, recommendations and improvement actions, that are reviewed in the context of continual improvement, and that are held at planned intervals and when significant change occurs; act on the results to implement changes and improvements.

How often does NIS2 Directive require backup restore test?

The held text of NIS2 Art.21.2.c (Business continuity, backup management, disaster recovery and crisis management) sets no fixed period: no period set by the text. This category asks the entity to be able to keep providing its services, or to restore them, when systems fail or are attacked. Backup management means backups that are taken, protected against the same event that takes out production, and demonstrably restorable, which is why restore testing rather than backup success rate is the evidence that counts. Disaster recovery means recovery objectives that were derived from what the service can actually tolerate, and infrastructure and procedure capable of meeting them. Crisis management is the decision-making layer above both: who declares a crisis, who can commit the organisation, how the entity communicates while under pressure. Because NIS2 is concerned with continuity of service to recipients, recovery objectives set purely from internal convenience are the usual weak point.

What does the register ask the owner of a backup restore test job?

When did the last restore read back the whole set, and was the time to restore recorded?

The clauses in full

ISO 27001 8.13 Information backupthe standard's page

Maintain and regularly test backups of information, software and systems per the backup policy.

Guidance beside it, ISO 27002 8.13: Requires backup copies of information, software and systems to be maintained and regularly tested, in line with the agreed topic specific policy on backup. Supporting SME guidance treats regular creation of backups together with tested recovery as the substance of the control, not the copy on its own.

What an assessor asks to see: backup_policy; backup_schedule; backup_test_reports; retention_records. Where it usually falls short: infrequent restore testing

SP 800-53 CP-4 Contingency plan testingthe standard's page

Requires the contingency plan to be tested at a defined frequency using defined test types to establish that the plan works and that people are ready to execute it, the test results to be reviewed, and corrective action to be initiated where the test shows it is needed.

What an assessor asks to see: Test plan and scenario documentation for each exercise; Test report with results, observations and participants; Defined test types and frequency, and evidence they were met; Corrective actions raised, tracked and closed following the test. Where it usually falls short: Tabletop exercise substituted for the technical failover test the plan requires

HIPAA 164.308(a)(7)(ii)(D) Testing and Revision Procedures (Addressable)the standard's page

Implement procedures for periodic testing and revision of contingency plans. NIST recommends annual tabletop, biennial functional, and post-incident lessons-learned updates.

What an assessor asks to see: Test schedule; Test reports; After-action reports; Plan revision history. Where it usually falls short: Plans untested for years

DORA Art. 25 Testing of ICT tools and systemsthe standard's page

The testing programme shall include a range of assessments and tests (e.g. vulnerability assessments and scans, open-source analyses, network security assessments, gap analyses, physical security reviews, questionnaires, source-code reviews, scenario-based tests, compatibility/performance tests, end-to-end and penetration testing), with critical ICT systems tested at least yearly.

What an assessor asks to see: Test plans and results across the required assessment types; At least-yearly testing of critical ICT systems. Where it usually falls short: Critical systems not tested annually

DORA Art. 11 Response and recoverythe standard's page

Financial entities shall put in place an ICT business continuity policy and ICT response and recovery plans (including measures, procedures and arrangements) to ensure continuity of critical or important functions, quickly contain damage, resume activities and recover, subject to regular testing.

What an assessor asks to see: ICT business continuity policy + response/recovery plans; Records of plan testing. Where it usually falls short: No ICT continuity/response/recovery plans

ISO 22301 8.5 Exercise programmethe standard's page

Implement and maintain a programme of exercising and testing that validates the effectiveness of the continuity strategies and solutions over time, running exercises and tests consistent with the continuity objectives, based on well planned scenarios with clearly defined aims, that build teamwork, competence, confidence and knowledge in those with response roles, that taken together over time validate the strategies and solutions, that produce formal post exercise reports with outcomes, recommendations and improvement actions, that are reviewed in the context of continual improvement, and that are held at planned intervals and when significant change occurs; act on the results to implement changes and improvements.

What an assessor asks to see: Exercise programme showing scope, scenario and interval coverage over time; Exercise aims and objectives defined before each exercise; Formal post exercise reports with outcomes, recommendations and actions; Action tracking to closure with evidence of the resulting change. Where it usually falls short: The same comfortable scenario rehearsed annually, so rare failure modes are never stressed

NIS2 Art.21.2.c Business continuity, backup management, disaster recovery and crisis managementthe standard's page

This category asks the entity to be able to keep providing its services, or to restore them, when systems fail or are attacked. Backup management means backups that are taken, protected against the same event that takes out production, and demonstrably restorable, which is why restore testing rather than backup success rate is the evidence that counts. Disaster recovery means recovery objectives that were derived from what the service can actually tolerate, and infrastructure and procedure capable of meeting them. Crisis management is the decision-making layer above both: who declares a crisis, who can commit the organisation, how the entity communicates while under pressure. Because NIS2 is concerned with continuity of service to recipients, recovery objectives set purely from internal convenience are the usual weak point.

What an assessor asks to see: Business impact analysis deriving recovery time and recovery point objectives from service tolerance; Backup configuration showing isolation or immutability against destructive attack; Restore test results, dated, covering the systems that carry the essential service; The crisis management plan naming decision authority, activation criteria and communications routes. Where it usually falls short: Backups verified as completed but never restored end to end

Requirement text quoted from the standards themselves, published at compliance.theartofservice.com, the same publisher as this register, read against the held text of each standard: our statement of each clause, not the instrument verbatim. Run this job through the register