# 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*.

<!--
Guidance: How to use this template
- Use it from the first day the backup policy is approved. Log planned
  tests and every real restore (a real restore is a test you did not
  plan, and auditors value it as evidence).
- Fill first: the test plan in section 2 (one line per tier and
  platform, taken from section 8 of `isms/backup-policy`), then add log
  entries in section 3 as tests run.
- Main pitfall: logging "restore OK" with no measured times and no
  sign-off. Record start and end times, the restore point used, and the
  data owner's confirmation that the data is complete and usable.
- Related templates: `isms/backup-policy`, `ops/backup-restore-procedure`,
  `ops/dr-test-report`, `compliance/capa-nonconformity`,
  `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: The log is a record, not a policy: it grows during the year. Freeze and archive it at year end as a new version. -->

| 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

<!-- Guidance: Explain the measurement rules once so every tester records the same way. Pitfall: RTO measured from when the engineer started typing, not from when the outage or request began. -->

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

<!-- Guidance: One row per planned test. Cover every tier, every backup platform, and at least one restore from the immutable copy per platform per year. Auditors check that the plan was followed and that slipped tests were rescheduled. -->

| 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).

```mermaid
gantt
  title Restore test plan 2027 (Example)
  dateFormat YYYY-MM-DD
  section T1
  RST001_second_region :t1, 2027-03-10, 2d
  RST002_immutable :t2, 2027-06-09, 2d
  RST003_dr_exercise :t3, 2027-09-15, 3d
  RST004_point_in_time :t4, 2027-12-01, 1d
  section T2 to T4
  RST005_saas_sample :t5, 2027-04-14, 1d
  RST006_repo_mirror :t6, 2027-05-12, 1d
  RST007_wiki_sample :t7, 2027-08-18, 1d
  RST008_iac_rebuild :t8, 2027-10-13, 2d
  RST009_storage_immutable :t9, 2027-02-17, 1d
  RST010_storage_region :t10, 2027-08-11, 1d
  RST011_saas_immutable :t11, 2027-10-20, 1d
  RST012_repo_retest :t12, 2027-11-10, 1d
```

## 3. Test log

<!-- Guidance: Add one row per executed test or real restore. Attach evidence (screenshots, checksums, row counts, owner e-mail) in the evidence column. Pitfall: editing past rows. Correct with a new row that references the old one. -->

| 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

<!-- Guidance: Compute achieved values from section 3 with the rules in section 1. Recompute totals before management review. Auditors compare these numbers with the tier targets in the backup policy. -->

| 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

<!-- Guidance: Each issue gets an owner, a due date and a retest. Close an issue only after a passing retest is logged. Pitfall: issues closed by changing the target instead of fixing the cause. -->

| 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

<!-- Guidance: Keep the log proportionate. A small company needs a dozen rows a year; a group needs one log per site rolled up centrally. -->

| 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

<!-- Guidance: State where the log and its attachments live and how long they are kept, and list the log in `isms/control-evidence-matrix` against A.8.13. -->

| 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

<!-- Guidance: Keep the governing documents current. -->

- 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.