Backup and Restore Test Log Template (ISO/IEC 27001 A.8.13)

Restore test plan and log: measurement rules, planned tests per tier, executed restores, RPO and RTO achieved versus target, issues and retests

ISMS und ISO/IEC 27001StandardISO/IEC 27001:2022 + Amd 1:2024 A.8.13 (cited only); ISO/IEC 27002:2022backup restore test logAktualisiert 01.11.2026

Im Editor öffnen.md herunterladen

Anleitung: Use it from the day the backup policy is approved to log planned restore tests and every real restore. Fill the annual test plan first, one line per tier and platform, then add a log row with measured times and owner sign-off for each test. The main pitfall is logging 'restore OK' with no measured RPO, RTO or evidence.

Vorschau

Backup and Restore Test Log: [Organization name]

Annual plan and running log of backup restore tests and real restores: what was restored, from which copy, how long it took, how much data would have been lost, whether the recovery point objective (RPO) and recovery time objective (RTO) were met, and which issues and actions followed. It is the main evidence record for ISO/IEC 27001:2022 + Amd 1:2024 Annex A control A.8.13 (information backup) under the Backup Policy ([DOC-ISMS-061]). Replace every [bracketed] value and every row marked Example.

Document control

Field	Value
Document ID	[DOC-ISMS-071]
Version	[2027.1]
Status	[Open log / Closed for year YYYY]
Owner	[@head-of-it-operations]
Approvers/reviewers	[@isms-manager], [@data-owners]
Last updated	YYYY-MM-DD
Classification	[Internal]
Standard and edition	ISO/IEC 27001:2022 + Amd 1:2024 (A.8.13); ISO/IEC 27002:2022
Governing policy	[Backup policy DOC-ISMS-061]
Log period	[2027-01-01 to 2027-12-31]
Next scheduled review	YYYY-MM-DD

Approvals

Role	Name	Decision	Date
Log owner	[@head-of-it-operations]	[Plan prepared]	YYYY-MM-DD
ISMS manager	[@isms-manager]	[Plan approved / Year closed]	YYYY-MM-DD

Revision history

Version	Date	Author	Change
2027.1	YYYY-MM-DD	[@owner]	Test plan for 2027 issued
[x.y]	YYYY-MM-DD	[@author]	[Change summary]

1. How the log works

Measurement rules used in every entry:

Achieved RTO runs from the declared start of the test (or the restore request in a real event) to the moment the data owner confirms the data is usable. Time spent waiting for approvals counts.
Achieved RPO is the age of the restore point used: the time between the newest recoverable data in the copy and the simulated failure time.
Result is Pass when both targets are met and integrity checks succeed; Partial when data is restored but a target is missed; Fail when data cannot be restored or is incomplete.
Every Partial or Fail result opens an issue in section 5 and, if the cause is a process or control gap, a corrective action in compliance/capa-nonconformity.

2. Test plan

Plan ID	Data set or system	Tier	Copy restored	Test type	Planned month	Owner
RST-PLN-001 (Example)	Production customer database	T1	Second-region copy	Full restore to isolated environment	2027-03	[@platform-lead]
RST-PLN-002 (Example)	Production customer database	T1	Immutable copy	Full restore	2027-06	[@platform-lead]
RST-PLN-003 (Example)	Production customer database	T1	Second-region copy	DR exercise with region failover	2027-09	[@platform-lead]
RST-PLN-004 (Example)	Production customer database	T1	Point-in-time	Point-in-time restore	2027-12	[@platform-lead]
RST-PLN-005 (Example)	SaaS mail and files	T2	SaaS backup service	Sample of 5 mailboxes and 2 shared drives	2027-04	[@it-lead]
RST-PLN-006 (Example)	Source code repositories	T2	Mirror account	One repository with issues and settings	2027-05	[@eng-lead]
RST-PLN-007 (Example)	Internal wiki	T3	Daily copy	Sample page set	2027-08	[@it-lead]
RST-PLN-008 (Example)	Infrastructure-as-code rebuild	T4	Repository	Rebuild staging network from code	2027-10	[@platform-lead]
RST-PLN-009 (Example)	Object storage with customer files	T2	Immutable copy	Restore of one bucket prefix from the locked copy	2027-02	[@platform-lead]
RST-PLN-010 (Example)	Object storage with customer files	T2	Second-region copy	Restore of one bucket prefix	2027-08	[@platform-lead]
RST-PLN-011 (Example)	SaaS mail and files	T2	Immutable copy of the SaaS backup	Sample of 5 mailboxes from the locked copy	2027-10	[@it-lead]
RST-PLN-012 (Example)	Source code repositories	T2	Mirror account	One repository with issues and settings (retest of the export)	2027-11	[@eng-lead]

The example plan follows isms/backup-policy section 8: four T1 tests (one of them the DR exercise), two tests a year for each T2 platform, one T3 and one T4 test, and one restore from the immutable copy for each platform that has one. Add a line for every other data set in the tier table, for example identity provider configuration (T1).

3. Test log

Log ID	Plan ID	Date	Data set	Restore point used	Start	Owner confirmed	Integrity check	Result	Evidence
RST-LOG-001 (Example)	RST-PLN-001	2027-03-10	Customer database	2027-03-10 08:45	09:00	11:40	Row counts and checksums match source	Pass	Ticket OPS-412, screenshots
RST-LOG-002 (Example)	RST-PLN-005	2027-04-14	5 mailboxes, 2 drives	2027-04-13 23:00	10:00	14:30	All items opened by owners	Pass	Ticket OPS-430
RST-LOG-003 (Example)	RST-PLN-006	2027-05-12	Repository "billing-api"	2027-05-11 23:30	13:00	15:00	Build passes from restored repository	Partial	Ticket OPS-455; issues not restored, see RST-ISS-001
RST-LOG-004 (Example)	RST-PLN-002	2027-06-09	Customer database	2027-06-09 01:00	09:00	14:15	Checksums match	Partial	Ticket OPS-470; RTO missed, see RST-ISS-002
RST-LOG-005 (Example)	Real restore	2027-07-02	Deleted shared drive folder	2027-07-01 23:00	16:10	17:00	Owner confirmed all files present	Pass	Ticket SD-2291

4. RTO and RPO achieved versus target

Log ID	Tier	RPO target	RPO achieved	RTO target	RTO achieved	Met?
RST-LOG-001 (Example)	T1	15 min	15 min	4 h	2 h 40 min	Yes
RST-LOG-002 (Example)	T2	24 h	11 h	24 h	4 h 30 min	Yes
RST-LOG-003 (Example)	T2	24 h	13 h 30 min	24 h	2 h	RPO and RTO yes; content incomplete
RST-LOG-004 (Example)	T1	15 min (24 h for the daily immutable copy)	8 h	4 h	5 h 15 min	No: RTO missed; RPO within the 24 h expected for the immutable copy
RST-LOG-005 (Example)	T2	24 h	17 h 10 min	24 h	50 min	Yes

Summary (Example): 5 restores logged, 3 Pass, 2 Partial, 0 Fail (pass rate 60%). RST-LOG-004 shows that the immutable copy alone cannot meet the T1 RPO of 15 minutes, because it is written once a day. The backup policy pass criterion for an immutable copy test is a successful restore without production credentials, so the 8 h data age is expected; the real finding is the missed RTO. Record the 24 h data-loss exposure when only the immutable copy survives (for example after ransomware that also reaches the second region) in the risk register and the business impact analysis, so management accepts it knowingly.

5. Issues and actions

Issue ID	From log	Issue	Action	Owner	Due	Retest log ID	Status
RST-ISS-001 (Example)	RST-LOG-003	Repository mirror holds code only; issues and pull request history not backed up	Add API export of issues and settings to the T2 job	[@eng-lead]	2027-06-30	[RST-LOG-00x]	Open
RST-ISS-002 (Example)	RST-LOG-004	Restore from immutable storage took 5 h 15 min against a 4 h RTO, mostly data transfer time	Pre-provision recovery compute in the backup account and document parallel restore; record residual risk RISK-031	[@platform-lead]	2027-08-31	[RST-LOG-00x]	Open, CAPA-017

6. Size tiers

Aspect	Small: Quillmere Analytics Ltd (46 staff)	Medium: Quillmere Health Systems (320 staff)	Large: Quillmere Group (2,400 staff, 6 sites)
Log format	This table in the ISMS document store	Table plus tickets in the IT service tool	One log per site and region, consolidated quarterly by the CISO office
Tests per year (Example)	12, as in section 2, with the DR region failover test as one of them	About 20, including hospital-facing clinical scheduling data	Over 60, including OT controller program restores at each of the 3 plants
Sign-off	Head of Engineering Operations (0.5 FTE ISMS manager) and product owner	Data owners plus the security team	Site leads, with sampling by group internal audit

7. Records and evidence

Record	Owner	Location (Example)	Retention (Example)
This log (closed yearly versions)	Log owner	ISMS document store	Certification cycle plus 1 year (at least 4 years)
Evidence attachments (screenshots, checksums, owner confirmations)	Backup operator	Ticketing system linked by ID	Same as the log
Corrective actions	ISMS manager	`compliance/capa-nonconformity` records	3 years after closure
Summary for management review	ISMS manager	`compliance/management-review` input	With the review minutes

8. References

ISO/IEC 27001:2022 + Amd 1:2024, Annex A control A.8.13: https://www.iso.org/standard/82875.html and https://www.iso.org/standard/88435.html
ISO/IEC 27002:2022: https://www.iso.org/standard/75652.html
NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems (May 2010, updated November 2010)
Related templates: isms/backup-policy (DOC-ISMS-061), ops/backup-restore-procedure, ops/dr-test-report, compliance/capa-nonconformity, isms/control-evidence-matrix (DOC-ISMS-033)

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (Annex A control A.8.13) and ISO/IEC 27002:2022. Control numbers are cited only; no ISO or IEC text is reproduced, and you need the official standards to implement and audit the control. NIST SP 800-34 Rev. 1 is a US government work. The text, measurement rules and examples are original. Check the current editions before use.

Template licence: MIT.