Restore Test: Log Template for Backups and Systems

Backing up data regularly does not automatically ensure that it can be restored without problems (BSI IT-Grundschutz, module CON.3, threat 2.2). The module therefore requires, as a basic requirement, regular tests of whether backed-up data can be restored flawlessly and within a reasonable time (CON.3.A15). For Austrian companies, IT-Grundschutz is a recognized recommendation, not an obligation. The numbers refer to the Kompendium Edition 2023. According to the BSI, its successor Grundschutz++ can be certified from January 1, 2027, and IT-Grundschutz until November 30, 2031; its user catalog lists the restore test as NOT.4.16.1 (SHOULD, based on representative samples). Binding requirements arise from the NISG 2026 and, for personal data, from the GDPR:

1. 1

   Define the test plan

   In the test plan (Section 04), enter for at least twelve months which system is tested when and with which test type; management approves it (BSI Standard 200-4, ch. 13.3).

2. 2

   Fill out one copy per test

   Part A before the test, Part B during it, Parts C and D afterward. Track findings until a successful retest.

The structure and fields are a TOMORIS recommendation. BSI Standard 200-4 provides for an exercise concept, an exercise log and an exercise report for each exercise and allows them to be combined in one document (ch. 13.2). Replace placeholders such as [System], [Name, role] and [MM/DD/YYYY] and fill in the “__________” fields. The GDPR does not mention the test explicitly; in TOMORIS’s view, it is an obvious way to verify the ability under lit. c.

It is often sufficient to test the time-critical parts in incremental stages (BSI Standard 200-4, ch. 13.9); deputies should practice too (ch. 13.2). Check for the offline copy: a (domain) administrator tries to access the separated copies; this should fail (ransomware catalog of measures, ch. 2). TOMORIS recommendation: test deletion locks only on a test backup created specifically for this purpose. Under point 4.2.6 of the Implementing Regulation Annex, NIS2 entities also test redundancies, for example failover between redundantly designed systems (BSI Standard 200-4, Table 34); you can use Parts B to D accordingly for this.

Annual exercise planning should cover at least twelve months and record for each exercise the period, type, objective and scope, responsible persons, participants, resources and the expected impact on normal operations (BSI Standard 200-4, ch. 13.3). For NIS2 entities, the tests must ensure that backup copies and redundancies are reliable in an emergency and cover all copies, procedures and knowledge required for effective recovery; the Implementing Regulation Annex does not specify a frequency, only “regularly” (point 4.2.6). The sample policy in NIST SP 800-34 provides for annual tests of recovery capability (Section 3.1). The BSI frequencies below are an example, not a requirement.

For NIS2 entities: the ENISA implementation guidance on the Implementing Regulation (Technical Implementation Guidance, June 2025, not legally binding) gives as an example for point 4.2.6 weekly checks for highly critical data, monthly checks for medium and low criticality, and a check immediately after significant changes. For point 4.1.4, it recommends testing contingency and recovery plans at least annually, including as a tabletop review, and including full restoration to a known state in the recovery plan tests.

• Risk assessment, risk-reducing measures and abort criteria defined, the way back to the initial state prepared; management approval if the test may affect operations (BSI Standard 200-4, ch. 13.9.1).
• Test environment realistic but isolated from production; setup and teardown planned (ch. 13.9.1).
• The restore instructions are also available outside the backup system, for example on paper, and are used in the test (CON.3.A6, threat 2.4).
• Keys for encrypted backups are available from separate storage (CON.3.A13, elevated protection needs); replacement or test hardware is ready (NIST SP 800-34, 3.5.1); with online storage, the backup system and network connection achieve the permissible recovery time (CON.3.A9).
• Procedure coordinated with service providers that operate backup or recovery, tested jointly where appropriate (DER.4.A16, elevated protection needs); for NIS2 entities, the ENISA implementation guidance on point 4.2.6 also recommends involving suppliers in tests.
• Deputies practice too (BSI Standard 200-4, ch. 13.2, there for the roles of the emergency organization). TOMORIS recommendation: where possible, the deputy performs the restore following the documented instructions.

The log should be concise and understandable to expert third parties (BSI Standard 200-4, ch. 13.2). TOMORIS recommendation: take all timestamps from the same clock and define T0 in advance.

In case of unintended impact on operations, abort according to the defined criteria and restore the initial state as quickly as possible (ch. 13.9.1); the exercise lead checks the abort criteria continuously (Table 36). Everything created specifically for the test is reversed afterward (ch. 13.9.1).

How to calculate (TOMORIS recommendation, derived from the terms in BSI Standard 200-4, ch. 7 and 8): in the test, T0 stands for the declaration of the emergency, i.e. the start of recovery; detection and alerting (BAO response time) are not included. The achieved recovery time (RTA) runs from T0 to handover T1 to the business unit. For data loss, T0 also counts as the assumed time of the outage: the RPA is the interval between the timestamp of the most recent fully restored data state and T0.

• Before restoring, checked whether the backup might already contain malware; worked with a copy of the backup or with write protection (BSI ransomware catalog of measures, ch. 2).
• Data fully restored and at the state of the last available backup (NIST SP 800-34, 4.4); verification method, e.g. count, size, checksums: __________
• Configuration data and data stored in cloud services restored (Implementing Regulation Annex point 4.2.2(b)); encrypted backup decrypted with the key from separate storage (CON.3.A13, elevated protection needs).
• All functions checked, ready for normal operations (NIST SP 800-34, 4.4); confirmed by [Name, role] from the business unit.
• Offline copy: access attempt with (domain) administrator rights failed (ransomware catalog of measures, ch. 2). Immutable copy: deletion or overwriting of a test backup rejected (overwriting: CON.3.A14; deletion: TOMORIS recommendation).
• The instructions were understandable, complete and technically correct; deviations are recorded in Part D (BSI Standard 200-4, ch. 13.9).

Per tested resource: successful, partially successful or not successful (BSI Standard 200-4, ch. 13.9.2, Table 40). Overall result: passed / failed, because under ISO 22398 a test is an exercise with an objectively measured result (ch. 13). An error-free exercise is not a success criterion; an exercise is also successful if a need for correction is identified and used for improvement (ch. 13.10).

NIS2 entities document test results and take corrective action where necessary (Implementing Regulation Annex point 4.2.6); lessons learned from tests are incorporated into the plans (point 4.1.4). The BSI recommends identifying causes, monitoring improvements and reporting delays to management (DER.4.A14, elevated protection needs). TOMORIS recommendation: close a finding only after a successful retest. If the Annex applies to you via § 2 NISV 2026 and you cannot meet point 4.2.6 temporarily or because of your size, § 4 NISV 2026 requires compensating measures, documented with reasons and reviewed for effectiveness at least annually.

• The status “Backup successful” does not replace a restore test (CON.3, threat 2.2).
• Instructions and keys are not stored separately and fail along with everything else (threats 2.4 and 2.8).
• The configuration is missing from the backup; only content data is backed up (Implementing Regulation Annex point 4.2.2(b)).
• Always using the same exercise scenario increases the risk of operational blindness (BSI Standard 200-4, ch. 13.2).