Backup Policy Template (3-2-1-1-0, Immutability, NIST CP-9)

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.

Document control

Approvals

Revision history

Contents

1. Purpose
2. Scope
3. Roles and responsibilities
4. Data classes and backup tiers
5. Policy statements
6. Retention schedule
7. Ransomware isolation architecture
8. Restore testing
9. SaaS and third-party data
10. Exceptions and risk acceptance
11. Compliance measurement
12. Control mapping
13. Review and related documents
14. Glossary and references

1. Purpose

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

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

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

3. Roles and responsibilities

3.1 RACI

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

4. Data classes and backup tiers

4.1 Data classes

4.2 Backup tiers

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:

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

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:

• 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

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

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

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

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

10. Exceptions and risk acceptance

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.

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

11. Compliance measurement

Example: Corvid Commerce monthly report, September 2026.

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

13. Review and related documents

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

14.1 Glossary

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.