# Backup Policy: [Organisation name]

> Organisation-wide policy for backing up data and systems: scope, roles,
> data classes and backup tiers, numbered policy statements, the
> 3-2-1-1-0 copy convention, immutable and offline copies, retention,
> encryption and key escrow, ransomware isolation, restore testing,
> software as a service (SaaS) data, exceptions, compliance measurement
> and review. Control references follow NIST SP 800-53 Rev. 5 (release
> 5.2.0) controls CP-6, CP-9 and CP-10 and NIST Cybersecurity Framework
> (CSF) 2.0 subcategories PR.DS-11 and RC.RP-03; recovery-copy practice
> draws on NIST SP 800-34 Rev. 1 and NIST SP 800-209. Per-system job
> settings and restore steps belong in the Backup and Restore Procedure
> (`ops/backup-restore-procedure`), not here. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- This is a policy: it says what MUST happen and who is accountable.
  Each system then proves compliance in its own Backup and Restore
  Procedure (`ops/backup-restore-procedure`), and each DR test proves
  recovery in a DR Test Report (`ops/dr-test-report`).
- Start with section 4: agree the data classes and backup tiers with
  the business, using recovery objectives from the business impact
  analysis and the tiers in Resilience Tiering, HA and DR Design
  (`architecture/resilience-tiering-ha-dr-design`).
- Write policy statements in section 5 so they can be audited: one
  requirement per statement, MUST for mandatory, SHOULD for expected
  unless an exception is approved, MAY for optional.
- 3-2-1-1-0 is an industry convention, not a standard. Adopt it because
  it is a useful test of resilience, and say so; do not cite it as a
  regulatory requirement.
- Worked example: Corvid Commerce, a fictional SaaS company. Rows marked
  *Example* belong to that organisation and must be replaced.
-->

## Document control

<!-- Guidance: A policy needs a named owner at management level and a fixed review date. Record which version is in force; procedures cite it by ID and version. -->

| Field | Value |
|---|---|
| Document ID | [POL-BKP-001] |
| Version | [1.0] |
| Status | [Draft / Approved / In force / Retired] |
| Owner | [@head-of-infrastructure] |
| Approvers/reviewers | [@cio], [@ciso], [@data-protection-officer], [@head-of-legal] |
| Effective date | YYYY-MM-DD |
| Last updated | YYYY-MM-DD |
| Next review | YYYY-MM-DD (at least every 12 months) |
| Classification | [Internal] |
| Applies to | [All business units, subsidiaries and environments listed in section 2] |
| Parent policies | [Information security policy], [Business continuity policy], [Records retention policy] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Policy owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Decision] | YYYY-MM-DD |
| Data protection officer | [@name] | [Decision] | YYYY-MM-DD |
| Head of legal | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; replaces the 2023 backup standard |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added SaaS data section after the annual review |
| 1.2 | YYYY-MM-DD | [@name] | *Example:* Restore-test column in 4.2 aligned with section 8; backup RPO separated from resilience RPO; tier assignment (4.3) aligned with the IT Disaster Recovery Plan system inventory |

## Contents

<!-- Guidance: Keep this list aligned with the headings below. -->

1. [Purpose](#1-purpose)
2. [Scope](#2-scope)
3. [Roles and responsibilities](#3-roles-and-responsibilities)
4. [Data classes and backup tiers](#4-data-classes-and-backup-tiers)
5. [Policy statements](#5-policy-statements)
6. [Retention schedule](#6-retention-schedule)
7. [Ransomware isolation architecture](#7-ransomware-isolation-architecture)
8. [Restore testing](#8-restore-testing)
9. [SaaS and third-party data](#9-saas-and-third-party-data)
10. [Exceptions and risk acceptance](#10-exceptions-and-risk-acceptance)
11. [Compliance measurement](#11-compliance-measurement)
12. [Control mapping](#12-control-mapping)
13. [Review and related documents](#13-review-and-related-documents)
14. [Glossary and references](#14-glossary-and-references)

## 1. Purpose

<!-- Guidance: Say why the policy exists in business terms. Questions: which losses is it meant to prevent (deletion, corruption, ransomware, site loss, supplier failure)? Pitfall: a purpose that only says "to comply with ISO 27001", which gives no basis for decisions. -->

This policy makes sure that [Organisation name] can recover the data
and systems it depends on after accidental deletion, corruption,
malicious encryption or destruction, loss of a site or cloud region,
or failure of a supplier, within recovery objectives agreed with the
business. It sets the minimum requirements every system owner must
meet, the copies and protections every backup must have, how long
backups are kept, and how the organisation proves that backups can be
restored.

A backup that has never been restored is an assumption. This policy
therefore treats restore testing as part of the backup, not as a
separate activity.

## 2. Scope

<!-- Guidance: Be explicit about what is covered, including environments and data held by suppliers. Questions: are laptops, source code, infrastructure configuration, secrets and SaaS data in scope? Pitfall: a scope limited to "servers", which leaves identity, configuration and SaaS data unprotected. -->

### 2.1 In scope

- All production systems and the data they store, in every data centre,
  cloud account and region operated by or for [Organisation name].
- Configuration needed to rebuild systems: infrastructure as code,
  deployment configuration, network and firewall rules, identity
  provider configuration, and DNS zones.
- Secrets and encryption keys needed to use the backups (protected under
  statement BKP-PS-21 to BKP-PS-24).
- Source code repositories and build artefacts needed to rebuild
  services.
- Business data held in SaaS applications (section 9).
- Non-production environments that hold production data or that cannot
  be rebuilt from code within their agreed recovery time.

### 2.2 Out of scope

| Item | Reason | Where it is handled |
|---|---|---|
| End-user device local storage *(Example)* | Documents are synchronised to managed cloud storage, which is in scope | [Endpoint management standard] |
| Caches and derived indexes that can be rebuilt from in-scope data *(Example)* | Rebuild time is inside the system RTO | System's Backup and Restore Procedure |
| Ephemeral test environments built from code *(Example)* | Rebuilt from the pipeline | [CI/CD pipeline design] |
| [Item] | [Reason] | [Document] |

Every exclusion of production data must be recorded in the system's
Backup and Restore Procedure with its reason.

## 3. Roles and responsibilities

<!-- Guidance: Name roles, not people, and keep accountability with one role per activity. Questions: who decides retention, who runs the jobs, who checks restores, who can delete a backup? Pitfall: the backup administrators can both change retention and delete immutable copies, which defeats ransomware protection. -->

| Role | Responsibilities |
|---|---|
| Policy owner | Maintains this policy, reports compliance to the risk committee, approves exceptions up to the limits in section 10 |
| Data owner | Classifies data, agrees recovery objectives and retention with the business and legal, accepts residual risk |
| System owner | Implements the policy for the system, keeps the Backup and Restore Procedure current, schedules restore tests, fixes failures |
| Backup operations | Runs and monitors the backup platform, raises failures, performs restores on request |
| Security operations | Monitors for tampering with backups, manages the isolated backup account, investigates alerts |
| Key custodians | Hold escrowed key material and recovery credentials under dual control |
| Legal and records management | Sets retention and legal holds, approves early deletion |
| Internal audit | Tests compliance independently at least once a year |

### 3.1 RACI

| Activity | Policy owner | Data owner | System owner | Backup operations | Security operations | Legal |
|---|---|---|---|---|---|---|
| Classify data and set backup tier | C | A | R | I | C | C |
| Configure backup jobs | I | I | A | R | C | I |
| Monitor jobs and fix failures | I | I | A | R | I | I |
| Run restore tests | I | C | A | R | I | I |
| Change retention | C | A | R | R | I | C |
| Delete or shorten an immutable copy | A | C | C | R | R | C |
| Approve exceptions | A | R | R | C | C | C |

R = responsible, A = accountable, C = consulted, I = informed.

## 4. Data classes and backup tiers

<!-- Guidance: Link each data class to a backup tier and each tier to measurable objectives. Questions: which tier does each system's resilience tier imply? Is the RPO achievable with the stated frequency? Pitfall: one tier for everything, which either overspends on low-value data or under-protects critical data. -->

### 4.1 Data classes

| Data class | Description | Examples *(Example)* |
|---|---|---|
| Critical transactional | Data the business cannot recreate; loss stops revenue or breaches obligations | Orders, payments ledger, customer accounts |
| Business records | Data kept for legal, financial or contractual reasons | Invoices, contracts, audit logs |
| Operational configuration | Data needed to rebuild or run systems | Infrastructure as code, DNS, identity configuration, secrets |
| Derived or rebuildable | Data that can be recreated from other in-scope data | Search indexes, caches, analytics extracts |
| Personal working data | Staff documents and mailboxes | Shared drives, email |

### 4.2 Backup tiers

| Backup tier | Typical resilience tier | Backup RPO | Minimum frequency | Point-in-time recovery | Copies (section 5.3) | Immutable or offline copy | Restore test (section 8) |
|---|---|---|---|---|---|---|---|
| B0 *(Example)* | T0, T1 | 15 min or less | Continuous log or change capture, plus daily full or snapshot | Required | 3-2-1-1-0 | Required, 35-day lock minimum | Monthly sample, quarterly full, immutable copy every 6 months |
| B1 *(Example)* | T2 | 4 h | Every 4 h | Recommended | 3-2-1-1-0 | Required, 35-day lock minimum | Monthly sample, full every 6 months, immutable copy yearly |
| B2 *(Example)* | T3 | 24 h | Daily | Not required | 3-2-1-1 | Required, 14-day lock minimum | Quarterly sample, yearly full, immutable copy yearly |
| B3 *(Example)* | T4 | 7 days | Weekly | Not required | 2 copies, 1 off-site | Recommended | Yearly sample, full every 2 years |
| [Tier] | [Tier] | [RPO] | [Frequency] | [Required / Not required] | [Rule] | [Lock] | [Cadence from section 8] |

Backup RPO and resilience RPO are different objectives. The backup RPO
limits loss after deletion, corruption or malicious encryption, which
replicate instantly to every live copy. The resilience tier RPO in the
Resilience Tiering, HA and DR Design limits loss after the loss of a
site or region. Where the resilience RPO is tighter than the backup RPO
(tiers T0 to T2 in the example: near zero, 5 min and 1 h), replication
or log shipping under the IT Disaster Recovery Plan
(`ops/disaster-recovery-plan`) meets it. A backup tier never relaxes the
resilience tier, and a replica never counts as a backup (BKP-PS-10).

### 4.3 Example tier assignment

*Example:* Corvid Commerce assigns backup tiers to the systems in
section 3.1 of its IT Disaster Recovery Plan, which is the single source
of truth for system IDs, resilience tiers and recovery objectives:

| System ID | System | Resilience tier, RTO, RPO (DR plan 3.1) | Backup tier | How the resilience RPO is met | Backup and Restore Procedure |
|---|---|---|---|---|---|
| SYS-02 *(Example)* | Orders database | T1, 1 h, 5 min | B0 | Cross-region streaming replica (DR plan 4.1) | BRP-ORDERS-001 |
| SYS-05 *(Example)* | Payments ledger service | T1, 1 h, 1 min | B0 | Synchronous standby in region B | [BRP-LEDGER-001] |
| SYS-01 *(Example)* | Checkout API | T1, 1 h, n/a (stateless) | None for the service; its configuration is in the B1 source code and infrastructure repositories | Not applicable | Covered by BRP-ORDERS-001 data set D-03 |
| SYS-07 *(Example)* | Catalogue search index | T3, 4 h, 24 h | B2 | Nightly snapshot copied cross-region | [BRP-SEARCH-001] |
| SYS-03 *(Example)* | Reporting warehouse | T3, 72 h, 24 h | B2 | Daily snapshot copied cross-region | [BRP-REPORTING-001] |

SYS-07 is derived data, but rebuilding it from scratch takes longer
than its 4 h RTO, so the exclusion in 2.2 does not apply and it keeps a
B2 backup.

### 4.4 Frequency check

The interval between backups plus the time to make the copy durable
must not exceed the RPO. *Example:* a B1 system backed up every 4 hours
whose backup takes 50 minutes to complete can lose up to 4 h 50 min of
data, which exceeds the 4-hour RPO; it needs a 3-hour interval or
change capture.

## 5. Policy statements

<!-- Guidance: Number every statement so procedures, audits and exceptions can cite it. Questions: can an auditor test each statement with evidence? Pitfall: statements like "backups should be secure", which cannot be tested. -->

The key words MUST, MUST NOT, SHOULD and MAY are used as follows: MUST
and MUST NOT are mandatory; SHOULD is expected unless an exception is
approved under section 10; MAY is optional.

### 5.1 Coverage and inventory

- **BKP-PS-01** Every production system MUST have a backup tier recorded
  in the configuration management database (CMDB) or service catalogue
  before it goes live.
- **BKP-PS-02** Every system MUST have an approved Backup and Restore
  Procedure (`ops/backup-restore-procedure`) that lists each data set,
  its tier, its jobs and any exclusion.
- **BKP-PS-03** Backup operations MUST reconcile the inventory of
  protected data sets against the CMDB at least monthly and report any
  production data set with no backup job.
- **BKP-PS-04** New data stores created through self-service MUST
  inherit a default backup tier of B1 until the data owner sets one.

### 5.2 Frequency and recovery objectives

- **BKP-PS-05** Backup frequency MUST meet the RPO of the backup tier,
  taking job duration into account (sections 4.2 and 4.4).
- **BKP-PS-06** Systems in tier B0 MUST support point-in-time recovery
  across the full short-term retention period.
- **BKP-PS-07** Backups SHOULD be application-consistent; where only
  crash-consistent copies are possible, the procedure MUST describe the
  recovery steps that make the data consistent.

### 5.3 Copies and the 3-2-1-1-0 convention

The organisation adopts the industry convention known as 3-2-1-1-0 as
its target for tiers B0 and B1. It is a widely used vendor-originated
rule of thumb, not a standard or a legal requirement:

| Digit | Meaning in this policy |
|---|---|
| 3 | At least three copies of the data, counting the production copy |
| 2 | Stored on at least two different media types or storage services, so one failure mode cannot affect all copies |
| 1 | At least one copy in a different location (another region or site) |
| 1 | At least one copy that is immutable for its retention lock period or kept offline (air-gapped) |
| 0 | Zero errors: every backup is verified, and restore tests complete with no unresolved error |

- **BKP-PS-08** Backups for tiers B0 and B1 MUST meet 3-2-1-1-0.
- **BKP-PS-09** Backups for tier B2 MUST meet 3-2-1-1 and SHOULD meet
  the zero-errors verification.
- **BKP-PS-10** A replica or a synchronised copy MUST NOT be counted as
  a backup copy, because deletion and corruption replicate to it.
- **BKP-PS-11** The off-site copy MUST be in a location that does not
  share the same disaster scope (power, flood plain, cloud region) as
  the primary.

### 5.4 Immutability and offline copies

- **BKP-PS-12** The immutable copy MUST use a write-once mechanism
  enforced by the storage platform (for example object lock in
  compliance mode, a hardened repository or tape kept offline) that no
  administrator in the production identity domain can remove before the
  lock expires.
- **BKP-PS-13** Lock periods MUST be at least the minimum in section 4.2
  and SHOULD be longer than the organisation's expected time to detect
  a compromise.
- **BKP-PS-14** Deleting a backup or shortening a lock before expiry
  MUST require dual authorisation by two named roles from section 3.1,
  and MUST raise a security alert.
- **BKP-PS-15** Offline media, where used, MUST be stored in a secured
  location with a custody log and checked for readability at least
  yearly.

### 5.5 Access control and ransomware isolation

- **BKP-PS-16** Backup storage for the immutable copy MUST sit in a
  separate account, subscription or tenant with its own identity domain
  (section 7).
- **BKP-PS-17** Credentials for the backup platform MUST NOT be usable
  from production workloads or from staff day-to-day accounts; access
  MUST use phishing-resistant multi-factor authentication.
- **BKP-PS-18** Production systems SHOULD only push backups to the
  isolated store; the isolated store MUST NOT expose delete or overwrite
  permissions to the production account.
- **BKP-PS-19** Security operations MUST alert on anomalous backup
  activity: mass deletion, lock changes, unusual restore or export, and
  sudden changes in backup size or change rate.
- **BKP-PS-20** Restores after a suspected compromise MUST be made into
  an isolated environment and scanned before reconnection, and MUST use
  a restore point from before the earliest known indicator of
  compromise.

### 5.6 Encryption and key escrow

- **BKP-PS-21** All backups MUST be encrypted at rest and in transit
  with algorithms and key lengths approved in the organisation's
  cryptography standard, aligned with NIST SP 800-57 Part 1 Rev. 5.
- **BKP-PS-22** Keys protecting the immutable copy MUST be managed
  outside the production key management domain, so that loss or
  compromise of the production account does not make backups unusable.
- **BKP-PS-23** Key material or recovery credentials needed to decrypt
  B0 and B1 backups MUST be escrowed under dual control (split
  knowledge between at least two key custodians) and the escrow MUST be
  tested in at least one restore test per year.
- **BKP-PS-24** Key rotation MUST NOT make retained backups unreadable;
  retired keys MUST be kept for at least the longest retention period
  of the data they protect.

### 5.7 Monitoring and failure handling

- **BKP-PS-25** Every backup job MUST report success or failure to a
  monitored system; a failed or missed job for tiers B0 and B1 MUST
  raise an alert to the owning team within 1 hour *(Example value)*.
- **BKP-PS-26** A data set with no successful backup within twice its
  scheduled interval MUST be treated as an incident under the Incident
  Severity Matrix (`ops/incident-severity-matrix`).
- **BKP-PS-27** Backup verification (checksum or catalogue integrity
  check) MUST run after every job for tiers B0 and B1.

### 5.8 Restore testing

- **BKP-PS-28** Every system MUST pass restore tests at the cadence of
  its tier (section 8), with evidence recorded in its Backup and Restore
  Procedure.
- **BKP-PS-29** A failed restore test MUST be treated as a backup
  failure: it is fixed, retested and reported in the monthly compliance
  report.
- **BKP-PS-30** Integrity of a backup MUST be checked before it is used
  for a production restore (NIST CSF 2.0 RC.RP-03).

## 6. Retention schedule

<!-- Guidance: Agree retention with legal and records management; backups are not an archive. Questions: which legal, contractual or regulatory periods apply to each record type, and how do deletion requests and legal holds reach backups? Pitfall: keeping every backup for seven years "to be safe", which increases cost, breach impact and privacy risk. -->

| Backup type | B0 *(Example)* | B1 *(Example)* | B2 *(Example)* | B3 *(Example)* |
|---|---|---|---|---|
| Point-in-time logs | 7 days | 3 days | n/a | n/a |
| Daily | 35 days | 35 days | 14 days | n/a |
| Weekly | 13 weeks | 8 weeks | 5 weeks | 5 weeks |
| Monthly | 13 months | 13 months | 6 months | 3 months |
| Yearly | [Per records schedule] | [Per records schedule] | Not kept | Not kept |

Rules:

- **BKP-PS-31** Retention MUST follow the records schedule maintained by
  legal and records management (see ISO 15489 Records Schedule,
  `compliance/iso-15489-records-schedule`); backups MUST NOT be used as
  the long-term archive for records that need retrieval by business
  users.
- **BKP-PS-32** A legal hold MUST suspend expiry of the affected
  backups until legal releases it, and the hold MUST be logged.
- **BKP-PS-33** When personal data must be erased, the erasure MUST be
  applied to live systems; data in backups MAY remain until the backup
  expires, provided it is not restored into use and any restore
  re-applies recorded erasures. Confirm this approach with the data
  protection officer for each jurisdiction.
- **BKP-PS-34** Expired backups MUST be deleted automatically, and
  deletion MUST be logged.

## 7. Ransomware isolation architecture

<!-- Guidance: Show how the immutable copy is isolated from the production identity domain. Questions: if an attacker has full administrator rights in production, which backup copies survive? Pitfall: immutable storage administered by the same identity provider and admin group as production. -->

```mermaid
flowchart LR
    subgraph PROD["Production account (identity domain A)"]
        APP["Workloads and databases"]
        SNAP["Local snapshots (copy 2)"]
    end
    subgraph BKP["Isolated backup account (identity domain B)"]
        REPO["Backup repository, other region (copy 3)"]
        LOCK["Object lock, compliance mode"]
    end
    subgraph OFF["Offline vault"]
        TAPE["Offline or cold copy, quarterly"]
    end
    KMS["Backup key management, escrowed keys"]
    APP --> SNAP
    APP -- "push only, no delete" --> REPO
    REPO --> LOCK
    REPO -. "quarterly export" .-> TAPE
    KMS -. "decrypt on restore" .-> REPO
```

*Example:* At Corvid Commerce, production accounts can write new backup
objects into the isolated account but hold no permission to delete,
overwrite or change lock settings. The isolated account is administered
by two named engineers through a separate identity provider tenant with
hardware security keys. A quarterly export of B0 data to an offline
cold-storage vault provides a second line of defence if the isolated
account itself is compromised.

## 8. Restore testing

<!-- Guidance: Set a cadence per tier and define what counts as a passed test. Questions: does the test restore to a clean environment, prove data integrity and measure time against the RTO? Pitfall: "restore tests" that only check that a backup file exists. -->

| Test type | B0 *(Example)* | B1 *(Example)* | B2 *(Example)* | B3 *(Example)* |
|---|---|---|---|---|
| Automated sample restore of one recent backup with integrity check | Monthly | Monthly | Quarterly | Yearly |
| Full restore of the system to an isolated environment, timed against RTO | Quarterly | Every 6 months | Yearly | Every 2 years |
| Restore from the immutable or offline copy, using escrowed keys | Every 6 months | Yearly | Yearly | n/a |
| Restore as part of a DR test (`ops/dr-test-report`) | Per DR plan schedule | Per DR plan schedule | Per DR plan schedule | n/a |

A restore test passes when:

1. The restored data set is complete: record counts, checksums or
   reconciliation match the source at the backup point.
2. The data is consistent: the application starts and passes its
   functional checks.
3. The restore completes within the RTO of the system, or the gap is
   recorded as a finding.
4. Evidence (date, backup point, duration, checks, result, tester) is
   stored in the system's Backup and Restore Procedure.

Sampling SHOULD rotate across data sets and backup ages, so that over a
year every data set and at least one monthly and one yearly backup are
restored.

## 9. SaaS and third-party data

<!-- Guidance: SaaS providers usually protect their platform, not your data from your own deletion or a compromised admin account. Questions: what does each contract promise, and for how long can deleted data be recovered? Pitfall: assuming the provider's recycle bin is a backup. -->

- **BKP-PS-35** For each SaaS application holding business records or
  critical data, the system owner MUST document the provider's backup
  and restore commitments and the gap against this policy.
- **BKP-PS-36** Where the provider's commitments do not meet the backup
  tier, the organisation MUST take its own backup (through export or a
  third-party backup service) or record an exception.
- **BKP-PS-37** Exit plans for SaaS applications MUST include a tested
  full export of the data in a usable format.

| SaaS application | Data class | Tier | Provider commitment | Own backup | Gap |
|---|---|---|---|---|---|
| *Example:* Customer support platform | Business records | B2 | Deleted items recoverable for a limited period stated in the contract | Daily API export to isolated account | None |
| *Example:* Source code hosting | Operational configuration | B1 | Platform redundancy only | Nightly mirror of all repositories to isolated storage | None |
| [Application] | [Class] | [Tier] | [Commitment] | [Method] | [Gap] |

## 10. Exceptions and risk acceptance

<!-- Guidance: Allow exceptions, but make them visible, time-limited and owned. Questions: who can approve which kind of exception, and what compensating control applies? Pitfall: permanent exceptions that nobody reviews. -->

An exception is needed when a system cannot meet a MUST or SHOULD
statement. The system owner raises it with the statement ID, the
reason, the risk, the compensating controls and a remediation date.

| Exception scope | Maximum duration | Approver |
|---|---|---|
| SHOULD statement, any tier *(Example)* | 12 months | Policy owner |
| MUST statement, tier B2 or B3 *(Example)* | 6 months | Policy owner and data owner |
| MUST statement, tier B0 or B1 *(Example)* | 3 months | Chief information security officer and data owner |
| Immutability or isolation statements (BKP-PS-12 to BKP-PS-20) *(Example)* | 3 months | Chief information security officer, reported to the risk committee |

| Exception ID | Statement | System | Reason | Compensating control | Expires | Approver |
|---|---|---|---|---|---|---|
| BKP-EX-001 *(Example)* | BKP-PS-08 | Legacy billing archive | Platform cannot write to object lock | Weekly offline copy to cold storage vault | 2026-12-31 | [@ciso] |
| [BKP-EX-NNN] | [BKP-PS-NN] | [System] | [Reason] | [Control] | YYYY-MM-DD | [@approver] |

Expired exceptions are reported as non-compliance until renewed or
closed.

## 11. Compliance measurement

<!-- Guidance: Measure compliance monthly with numbers anyone can recompute. Questions: what is the denominator for each metric, and what threshold triggers escalation? Pitfall: reporting job success rates only, which hides data sets that have no job at all. -->

| Metric ID | Metric | Formula | Target *(Example)* |
|---|---|---|---|
| BKP-M-01 | Backup coverage | Production data sets with an active job / production data sets in the CMDB | 100% |
| BKP-M-02 | Job success rate | Successful jobs / scheduled jobs in the month | 99% or higher |
| BKP-M-03 | RPO compliance | Data sets whose latest successful backup is younger than their RPO at the time of measurement / data sets in scope | 100% for B0 and B1 |
| BKP-M-04 | Immutable copy coverage | B0, B1 and B2 data sets with a verified immutable or offline copy / B0, B1 and B2 data sets | 100% |
| BKP-M-05 | Restore test compliance | Restore tests completed on schedule and passed / restore tests due | 95% or higher |
| BKP-M-06 | Restore time within RTO | Full restore tests completed within RTO / full restore tests completed | 100% for B0 and B1 |
| BKP-M-07 | Open exceptions past expiry | Count | 0 |

*Example:* Corvid Commerce monthly report, September 2026.

| Metric | Numerator | Denominator | Result | Target | Status |
|---|---|---|---|---|---|
| BKP-M-01 *(Example)* | 412 | 418 | 98.6% | 100% | Below target: 6 new data stores without jobs |
| BKP-M-02 *(Example)* | 12,318 | 12,402 | 99.3% | 99% | Met |
| BKP-M-04 *(Example)* | 301 | 309 | 97.4% | 100% | Below target: 8 covered by BKP-EX-001 |
| BKP-M-05 *(Example)* | 46 | 48 | 95.8% | 95% | Met |
| BKP-M-06 *(Example)* | 11 | 12 | 91.7% | 100% | Below target: one B1 restore took 5 h against a 4 h RTO |

Arithmetic *(Example)*: 412 / 418 = 98.6%; 12,318 / 12,402 = 99.3%;
301 / 309 = 97.4%; 46 / 48 = 95.8%; 11 / 12 = 91.7%. Any metric below
target for two consecutive months is escalated to the risk committee
with a remediation plan.

## 12. Control mapping

<!-- Guidance: Map statements to the controls your auditors test. Cite identifiers and short names only. Pitfall: mapping every statement to every control, which makes the mapping useless. -->

| Requirement | Reference | Policy statements |
|---|---|---|
| System backup | NIST SP 800-53 Rev. 5 CP-9 | BKP-PS-01 to BKP-PS-11 |
| Testing backups for reliability and integrity | CP-9(1) | BKP-PS-27 to BKP-PS-30 |
| Test restoration using sampling | CP-9(2) | Section 8 |
| Separate storage for critical information | CP-9(3) | BKP-PS-16 |
| Transfer to alternate storage site | CP-9(5) | BKP-PS-11 |
| Dual authorisation for deletion or destruction | CP-9(7) | BKP-PS-14 |
| Cryptographic protection of backups | CP-9(8) | BKP-PS-21 to BKP-PS-24 |
| Alternate storage site, separated from primary | CP-6, CP-6(1) | BKP-PS-11 |
| System recovery and reconstitution | CP-10; CP-10(2) transaction recovery | BKP-PS-06, BKP-PS-20, section 8 |
| Backups created, protected, maintained and tested | NIST CSF 2.0 PR.DS-11 | Sections 5 and 8 |
| Integrity of backups verified before restoration | NIST CSF 2.0 RC.RP-03 | BKP-PS-30 |
| Information backup | ISO/IEC 27001:2022 Annex A 8.13 | Whole policy |
| [Requirement] | [Reference] | [Statements] |

## 13. Review and related documents

<!-- Guidance: State when and why the policy is reviewed, and which documents depend on it. -->

The policy owner reviews this policy at least every 12 months and after
any of these events: a major data loss or ransomware incident, a failed
DR test caused by backups, a new regulatory or contractual requirement,
a change of backup platform, or an audit finding against this policy.

Related documents:

- Backup and Restore Procedure (`ops/backup-restore-procedure`): per
  system implementation and evidence.
- IT Disaster Recovery Plan (`ops/disaster-recovery-plan`) and DR Test
  Report (`ops/dr-test-report`).
- Resilience Tiering, HA and DR Design
  (`architecture/resilience-tiering-ha-dr-design`).
- Business Continuity Plan (`compliance/business-continuity`).
- Incident Response Plan (`compliance/incident-response-plan`).
- Secrets Management Standard (`security/secrets-management-standard`).
- ISO 15489 Records Schedule (`compliance/iso-15489-records-schedule`).

## 14. Glossary and references

<!-- Guidance: Define the terms that cause disputes in audits and list exact editions. -->

### 14.1 Glossary

| Term | Meaning in this policy |
|---|---|
| Backup | An independent, versioned copy of data from which a past state can be restored |
| Replica | A continuously synchronised copy; it protects against site failure but not against deletion or corruption |
| Immutable copy | A copy the storage platform prevents from being changed or deleted until a lock expires |
| Offline (air-gapped) copy | A copy with no network path from production systems |
| Backup tier | The set of frequency, copy, lock and test requirements assigned to a data set |
| RPO | Recovery point objective: the maximum acceptable period of data loss |
| RTO | Recovery time objective: the maximum acceptable time to restore service |
| Key escrow | Holding copies of keys or recovery credentials under controlled custody so backups stay decryptable |
| Legal hold | A legal instruction to preserve data beyond its normal retention |

### 14.2 References

- NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information
  Systems and Organizations, release 5.2.0 (August 2025):
  https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
- NIST Cybersecurity Framework 2.0, February 2024:
  https://www.nist.gov/cyberframework
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal
  Information Systems, May 2010, updated November 2010:
  https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final
- NIST SP 800-209, Security Guidelines for Storage Infrastructure,
  October 2020: https://csrc.nist.gov/pubs/sp/800/209/final
- NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part
  1, General, May 2020: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
- CISA, FBI, NSA and MS-ISAC, #StopRansomware Guide (2023), which
  recommends offline, encrypted and regularly tested backups:
  https://www.cisa.gov/stopransomware/ransomware-guide
- ISO/IEC 27001:2022 with Amendment 1:2024, Annex A control 8.13
  (information backup), cited by number only.
- The 3-2-1-1-0 rule: an industry convention extending the older 3-2-1
  rule, promoted by backup vendors; no standards body owns it.

## Standard and licence note

Based on NIST SP 800-53 Rev. 5 (release 5.2.0), NIST CSF 2.0, NIST SP
800-34 Rev. 1, NIST SP 800-209, NIST SP 800-57 Part 1 Rev. 5 and the
CISA #StopRansomware Guide, which are US Government works not subject
to copyright in the United States. ISO/IEC 27001 is copyrighted by ISO
and IEC and is cited by control number only. The 3-2-1-1-0 rule is an
industry convention and is described here in original words. All text,
policy statements and the Corvid Commerce example are original and
fictional. Check the current official version of each source before
relying on it. Template licence: MIT.