# Backup Policy: [Organization name] > ISMS-level policy for information backup: what is backed up, how often, > how many copies exist and where, how long they are kept, how they are > protected against encryption by ransomware and against deletion by a > compromised administrator, how SaaS data is covered, and how restores > are proven by testing. It supports ISO/IEC 27001:2022 + Amd 1:2024 > Annex A control A.8.13 (information backup), with links to A.5.29, > A.5.30, A.8.14 and A.8.24, and draws on the guidance in ISO/IEC > 27002:2022. Backup requirements come from the risk assessment and the > business impact analysis, not from tool defaults. Replace every > `[bracketed]` value and every row marked *Example*. ## Document control | Field | Value | |---|---| | Document ID | [DOC-ISMS-061] | | Version | [1.0] | | Status | [Draft / In review / Approved / Superseded] | | Owner | [@head-of-it-operations] | | Approvers/reviewers | [@isms-manager], [@ciso], [@dpo], [@coo] | | Last updated | YYYY-MM-DD | | Effective from | YYYY-MM-DD | | Classification | [Internal] | | Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (A.8.13); ISO/IEC 27002:2022 | | Next scheduled review | YYYY-MM-DD | | Inputs | [Business impact analysis DOC-ISMS-120], [Risk register DOC-ISMS-016], [Asset inventory DOC-ISMS-012] | | Evidence records | [Backup and restore test log DOC-ISMS-071], [backup job reports], [retention settings exports] | | Related documents | [ICT readiness plan DOC-ISMS-047], [Business continuity plan DOC-ISMS-121], [Cryptographic key register DOC-ISMS-070] | ### Approvals | Role | Name | Decision | Date | |---|---|---|---| | Policy owner | [@head-of-it-operations] | [Prepared] | YYYY-MM-DD | | ISMS manager | [@isms-manager] | [Reviewed] | YYYY-MM-DD | | Top management sponsor | [@coo] | [Approved / Approved with changes] | YYYY-MM-DD | ### Revision history | Version | Date | Author | Change | |---|---|---|---| | 0.1 | YYYY-MM-DD | [@owner] | First draft from the business impact analysis | | 1.0 | YYYY-MM-DD | [@owner] | Approved for issue | | 1.1 *(Example)* | YYYY-MM-DD | [@owner] | Added immutable copy for SaaS mail and files after risk RISK-024 | | [x.y] | YYYY-MM-DD | [@author] | [Change summary] | ## Contents - [1. Purpose, scope and authority](#1-purpose-scope-and-authority) - [2. Roles and responsibilities](#2-roles-and-responsibilities) - [3. Backup tiers from risk and impact](#3-backup-tiers-from-risk-and-impact) - [4. Policy statements](#4-policy-statements) - [5. Retention schedule](#5-retention-schedule) - [6. Ransomware and insider resilience](#6-ransomware-and-insider-resilience) - [7. SaaS and cloud platform backups](#7-saas-and-cloud-platform-backups) - [8. Restore testing](#8-restore-testing) - [9. Exceptions](#9-exceptions) - [10. Size tiers](#10-size-tiers) - [11. Records and evidence](#11-records-and-evidence) - [12. Control mapping](#12-control-mapping) - [13. Compliance, measurement and review](#13-compliance-measurement-and-review) - [14. References](#14-references) - [Standard and licence note](#standard-and-licence-note) ## 1. Purpose, scope and authority This policy makes sure that information, software and system configuration inside the ISMS scope ([DOC-ISMS-002]) can be recovered to a known good state within the time and data-loss limits that the business has agreed. It applies to every system, platform and data set listed in the asset inventory ([DOC-ISMS-012]) with an availability or integrity requirement of Medium or higher, and to every supplier that holds that data on the organization's behalf. | Item | Value | |---|---| | In scope | [Production databases, object storage, file shares, SaaS mail and files, source code repositories, identity provider configuration, infrastructure-as-code, network and firewall configuration, OT controller programs, endpoint data classed Confidential] | | Out of scope | [Data that can be fully rebuilt from source within the RTO, for example build artefacts and caches; personal data on BYOD devices outside managed containers] | | Authority | Approved by [top management body]; binding for all staff, contractors and suppliers handling in-scope data | | Relation to other policies | Retention periods here are maximums for backup copies; legal retention of records is set in `data/data-retention-deletion-standard` | Backup is not archiving and not replication. Replication (A.8.14, redundancy) keeps a second live copy and copies corruption and deletion too. Archiving keeps records for legal reasons. A backup is an independent point-in-time copy that can be restored after the live data and its replicas have been damaged. ### 1.1 Relationship to the NIST-based backup policy The template library contains two backup policies that cover the same subject from different frameworks: | Aspect | This policy (`isms/backup-policy`, DOC-ISMS-061) | `ops/backup-policy` (POL-BKP-001) | |---|---|---| | Framework | ISO/IEC 27001:2022 Annex A (A.8.13 and related controls) | NIST SP 800-53 Rev. 5 (CP-6, CP-9, CP-10) and NIST CSF 2.0 | | Best for | An ISMS that needs one policy traceable to the SoA and the control evidence matrix | An IT operations function that wants detailed statements (frequency check, RACI, resilience tier mapping) | | Backup tier names | T1 Critical to T4 Low (section 3) | B0 to B3, mapped to resilience tiers T0 to T4 from the architecture design | | Statement IDs | BKP-POL-001 onwards | BKP-PS-01 onwards | | Shared rules | 3-2-1-1-0 as an industry convention, replicas never count as backups, immutable copy in a separate identity domain, encryption with escrowed keys, restore from a point before the earliest indicator of compromise | Same | Choose one of these approaches and record it in the policy framework (`isms/isms-policy-framework`): 1. **One policy (recommended)**: approve this document as the backup policy for the ISMS and do not issue `ops/backup-policy`; copy any operational detail you need from it into section 4 or into `ops/backup-restore-procedure`. 2. **Policy plus operational standard**: approve this document as the policy and issue `ops/backup-policy` as a subordinate operational standard. Its tiers, frequencies, retention periods and test cadences must then be the same values as sections 3, 5 and 8 here (rename its B0 to B3 tiers to match, or add a mapping table), and it cites this policy as its parent. 3. **NIST-based policy only**: approve `ops/backup-policy` as the policy and use section 12 of this template as a mapping annex so the SoA entry for A.8.13 still points to evidence. The worked values in the two templates are independent examples (for example, the T2 RPO of 24 hours here and the B1 RPO of 4 hours there). Neither set is a recommendation: take your own values from the business impact analysis. In the ops template, T0 to T4 are resilience tiers from the architecture design, not backup tiers, so do not mix the two tier schemes in one document. ## 2. Roles and responsibilities | Role | Responsibilities | |---|---| | Policy owner [@head-of-it-operations] | Maintains this policy, the backup tier assignments and the restore test plan; reports compliance to the ISMS manager quarterly | | Information owner (per data set) | Confirms the tier, RPO and RTO for their data; signs off restore test results; approves retention exceptions as risk owner, within the limits in section 9 | | Backup operator | Runs and monitors jobs, investigates failures within one business day, performs restores and records them in the test log | | Backup security custodian | Holds the credentials and keys that control immutability, retention locks and backup encryption; separate from day-to-day production administrators | | ISMS manager [@isms-manager] | Checks the policy against the risk register and SoA, includes backup metrics in the measurement programme, follows up audit findings | | Data protection officer [@dpo] | Advises on retention of personal data in backups and on handling erasure requests that touch backup copies | | Suppliers | Meet the backup clauses in their agreements and provide evidence of backup and restore on request | ## 3. Backup tiers from risk and impact Each data set is assigned one tier. The recovery point objective (RPO) is the maximum acceptable data loss measured in time; the recovery time objective (RTO) is the maximum time to restore the data and make it usable again. | Tier | Typical data | RPO | RTO | Minimum backup frequency | Copies | |---|---|---|---|---|---| | T1 Critical *(Example)* | Production customer database, identity provider configuration | 15 minutes | 4 hours | Continuous log shipping or snapshots every 15 minutes, plus a full daily copy | Production, second region, immutable copy | | T2 High *(Example)* | Object storage with customer files, source code, SaaS mail and files | 24 hours | 24 hours | Daily | Production, separate service or account, immutable copy | | T3 Standard *(Example)* | Internal file shares, wiki, ticketing data | 24 hours | 3 days | Daily | Production, separate account | | T4 Low *(Example)* | Rebuildable systems where configuration is in code | 7 days | 5 days | Weekly configuration export, code in the repository | Repository plus one copy | ```mermaid flowchart LR A["BIA: RPO and RTO per service"] --> B["Assign tier T1 to T4"] R["Risk register: ransomware, deletion, region loss"] --> B B --> C["Configure jobs, copies and retention"] C --> D["Monitor job results daily"] D --> E["Restore test per plan"] E --> F{"RPO and RTO met?"} F -- Yes --> G["Record in test log DOC-ISMS-071"] F -- No --> H["Corrective action and retest"] H --> C G --> I["Annual review of tiers"] I --> B ``` ## 4. Policy statements ### 4.1 Coverage - **BKP-POL-001**: Every in-scope data set must have a recorded tier, owner, backup method and restore procedure before it goes live. The change process (`ops/change-request`) must check this. - **BKP-POL-002**: The backup inventory must be reconciled with the asset inventory at least quarterly. Unprotected assets are reported to the ISMS manager as nonconformities. - **BKP-POL-003**: Configuration that is needed to rebuild a service (infrastructure-as-code, identity provider settings, DNS zones, firewall rules, encryption key metadata) is backed up like data. ### 4.2 Frequency and copies - **BKP-POL-004**: Backup frequency must meet the tier RPO in section 3. - **BKP-POL-005**: T1 and T2 data must follow the 3-2-1-1-0 convention: at least three copies (including production), on two different storage services or media, one copy in a different location or region, one copy immutable or offline, and zero unresolved errors after restore verification. The convention is an industry practice, not a requirement of ISO/IEC 27001. - **BKP-POL-006**: The off-site or second-region copy must not share a single failure point with production (same account, same credentials, same storage cluster). ### 4.3 Protection of backups - **BKP-POL-007**: Backups must be encrypted in transit and at rest with algorithms approved in `security/cryptography-standard`. Backup encryption keys are recorded in the cryptographic key register ([DOC-ISMS-070]) and escrowed so that a restore is possible if the key management service itself is unavailable. - **BKP-POL-008**: Access to backup consoles requires phishing-resistant multi-factor authentication and named privileged accounts. Deleting backups, shortening retention or disabling immutability requires a second approver. - **BKP-POL-009**: Backups hold the same classification as the source data and are handled according to `isms/information-labelling-handling-procedure`. Physical media in transit are tracked and encrypted. ### 4.4 Monitoring - **BKP-POL-010**: Job results are monitored daily. A failed T1 or T2 job is investigated the same business day; two consecutive failures are logged as a security event and reported per `isms/security-event-reporting-procedure`. - **BKP-POL-011**: Backup platform audit logs are sent to central logging (`security/security-logging-standard`) and alerts are raised for deletion, retention changes and mass restore activity. ### 4.5 Retention and deletion - **BKP-POL-012**: Backup copies are kept for the periods in section 5 and then deleted securely (A.8.10). Backups must not be used to extend the retention of personal data beyond what is lawful. - **BKP-POL-013**: When a data subject requests erasure, live data is erased; backup copies that cannot be edited are put beyond use and age out on schedule, and any restore must re-apply erasures recorded since the backup date. ## 5. Retention schedule | Copy type | T1 | T2 | T3 | T4 | |---|---|---|---|---| | Point-in-time (15 minutes or hourly) *(Example)* | 7 days | n/a | n/a | n/a | | Daily *(Example)* | 35 days | 35 days | 30 days | n/a | | Weekly *(Example)* | 13 weeks | 13 weeks | 8 weeks | 4 weeks | | Monthly *(Example)* | 13 months | 13 months | 6 months | n/a | | Immutable copy lock period *(Example)* | 35 days | 35 days | n/a | n/a | | Legal hold | As instructed by [@legal], recorded in the legal register | Same | Same | Same | Retention of 35 days on daily copies is chosen so that a restore point exists from before a typical undetected compromise window; set your own figure from incident history and threat intelligence. Record the reason for each retention period in the table notes. ## 6. Ransomware and insider resilience The following rules apply in addition to section 4: 1. **Isolation**: backup infrastructure uses a separate identity domain or cloud account from production, with no standing trust that lets a production administrator manage it. 2. **Immutability**: at least one copy of T1 and T2 data is written to storage with a time-based retention lock (compliance-mode object lock or equivalent) or to offline media. The lock cannot be shortened by any single person, including the backup security custodian. 3. **Clean restore point**: before restoring after a suspected compromise, the incident lead and backup operator select a restore point dated before the earliest indicator of compromise, scan the restored data in an isolated environment, and record the decision in the incident record ([DOC-ISMS-021]). 4. **Credential recovery**: break-glass credentials for the backup platform are stored offline (sealed envelope in a safe or hardware token held by two people) and tested twice a year. 5. **Detection**: unusual deletion, encryption-like change rates or mass restore requests raise an alert to the security monitoring function (`isms/security-monitoring-procedure`). ```mermaid flowchart TD A["Ransomware or destructive event confirmed"] --> B["Contain: isolate production, keep backup platform offline from it"] B --> C["Identify earliest indicator of compromise"] C --> D["Select restore point dated before it"] D --> E["Restore to isolated recovery environment"] E --> F{"Scan and integrity checks clean?"} F -- No --> D F -- Yes --> G["Re-apply erasures and changes recorded since the restore point"] G --> H["Owner sign-off and return to service"] H --> I["Record in incident register and post-incident review"] ``` ## 7. SaaS and cloud platform backups | Platform type | Provider typically covers | The organization covers | Rule | |---|---|---|---| | Productivity suite (mail, files, chat) | Infrastructure resilience, short retention and recycle bins | Independent point-in-time copies, long retention, protection against admin or attacker deletion | T2: third-party or native backup to a separate account with immutable storage | | Infrastructure and platform cloud | Durability of the storage service | Snapshots, cross-account and cross-region copies, retention locks, key escrow | Tier per section 3; copies in a separate account | | Business SaaS (CRM, ticketing, HR, finance) | Platform availability | Regular data exports or API backups, export format that can be imported elsewhere | T3 minimum; T2 where the BIA says so | | Source code platform | Repository availability | Mirror or scheduled export including issues and settings, plus CI secrets inventory | T2 | For each SaaS service, record in the supplier register (`isms/supplier-register`) whether a backup exists, where, and the date of the last restore test. Cover data portability at contract end in the cloud exit plan (`isms/cloud-exit-plan`). ## 8. Restore testing | Tier | Minimum test | Frequency | Pass criteria | |---|---|---|---| | T1 | Full restore of the system to an isolated environment, application check by the owner | Quarterly, with one per year as part of a DR exercise | RTO and RPO met, integrity checks pass, owner sign-off | | T2 | Restore of a sample data set (for example 5 mailboxes, one repository, one bucket prefix) | Semi-annually | Data complete and readable, RTO met | | T3 | Sample file or record restore | Annually | Data readable | | T4 | Rebuild from code and configuration export | Annually | Service rebuilt within RTO | | Immutable copy | Restore from the locked copy specifically | Annually for each platform | Restore succeeds without using production credentials | Every test, and every real restore, is recorded in the backup and restore test log (`isms/backup-restore-test-log`, [DOC-ISMS-071]). System-specific steps live in `ops/backup-restore-procedure`; full recovery exercises are reported with `ops/dr-test-report`. A failed test opens a corrective action in the nonconformity record (`compliance/capa-nonconformity`). ## 9. Exceptions Requests to deviate from this policy use the security exception request (`security/security-exception-request`). Each exception records the policy statement affected, the data set, the risk score from the risk register (scale 1 to 25, `compliance/risk-methodology`), compensating measures, the approver and an expiry date. Each exception is approved at the authority the risk methodology (DOC-ISMS-010 section 2.4) sets for the residual risk: the risk owner for Low; the risk owner and department head for Medium (top management if the risk category is Averse, DOC-ISMS-015 section 9 rule 1); top management with a treatment decision for High, recorded in the risk acceptance record (DOC-ISMS-019, `isms/isms-risk-acceptance-record`). Critical residual risk is not approvable as an exception: treat it or stop the activity. Maximum duration is 12 months for Low or Medium and 6 months for High; at expiry the exception is reassessed, and a renewal is a new decision (DOC-ISMS-122 section 7). | Exception ID | Statement | Data set | Residual score | Compensating measure | Expiry | |---|---|---|---|---|---| | BKP-EXC-001 *(Example)* | BKP-POL-005 | Legacy plant historian (OT) | 8 Medium | Weekly offline export to encrypted disk held in the site safe | YYYY-MM-DD | ## 10. Size tiers | Aspect | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large: Quillmere Group (2,400 staff, 6 sites) | |---|---|---|---| | Setting | One office plus remote staff; production on one public cloud provider in two regions (primary and DR); processor of customer personal data | Two offices and one colocation suite; processor for hospitals, controller for staff and marketing data | 6 sites in 4 countries including 3 plants and 1 data centre; OT and IT; ISO 22301 already certified | | Backup method *(Example)* | Native database snapshots and point-in-time recovery, cross-region copies into a separate cloud account with object lock; SaaS backup service for the productivity suite | Backup software in the colocation suite plus cloud copy with immutability; database log shipping for the clinical scheduling platform | Central backup platform per region, tape or offline vault at the data centre, OT controller program exports per plant | | Owner | Head of Engineering Operations (also the 0.5 FTE ISMS manager) with one platform engineer as backup operator | Infrastructure manager; security team of 3 holds immutability controls | Group IT operations with site leads; CISO office audits; OT engineering owns plant exports | | Restore testing | Quarterly T1 test combined with the DR region failover test | Quarterly T1, semi-annual T2, annual DR exercise with hospital customers informed | Site-by-site schedule aligned with the ISO 22301 exercise programme | | Segregation | Separate cloud account, two named custodians | Separate backup domain, custodian role in the security team | Separate backup domain per region, four-eyes change on retention locks | ## 11. Records and evidence | Record | Proves | Owner | Location *(Example)* | Retention *(Example)* | |---|---|---|---|---| | Backup inventory with tiers | Coverage (BKP-POL-001 to 003) | Policy owner | CMDB or asset inventory export | Current plus 3 years of quarterly snapshots | | Job success reports | Frequency met (BKP-POL-004, 010) | Backup operator | Backup platform reports, monthly PDF export | 3 years | | Immutability and retention settings export | Copies protected (BKP-POL-005 to 008) | Backup security custodian | Configuration export with date | 3 years | | Backup and restore test log | Restores work, RPO and RTO met | Policy owner | `isms/backup-restore-test-log` | Certification cycle plus 1 year | | Failure and corrective action records | Issues followed up | ISMS manager | Nonconformity record, ticketing system | 3 years | | Exception register entries | Deviations controlled | ISMS manager | Exception register | 3 years after expiry | | Supplier backup evidence | Outsourced data protected | Supplier owner | Supplier register attachments | Contract term plus 1 year | ## 12. Control mapping | Control (ISO/IEC 27001:2022 Annex A) | How this policy supports it | |---|---| | A.8.13 information backup | Whole policy | | A.8.14 redundancy of processing facilities | Section 1 distinguishes replication from backup; second-region copies | | A.5.29 security during disruption | Section 6 keeps backup security controls active during recovery | | A.5.30 ICT readiness for business continuity | Tiers and RTOs feed `isms/ict-readiness-business-continuity-plan` | | A.8.24 use of cryptography | BKP-POL-007 encryption and key escrow | | A.8.10 information deletion | BKP-POL-012 and 013 | | A.5.33 protection of records | Retention and legal hold in section 5 | | A.5.23 cloud services security | Section 7 | Other frameworks with a backup requirement include NIS2 (Directive (EU) 2022/2555) Article 21(2)(c), DORA (Regulation (EU) 2022/2554) Article 12 for financial entities, and GDPR Article 32(1)(c) on restoring availability of personal data. Record the ones that bind you in the legal register ([DOC-ISMS-014]). ## 13. Compliance, measurement and review | Measure *(Example)* | Target | Source | |---|---|---| | In-scope assets with a recorded tier and backup | 100% | Quarterly reconciliation | | T1 and T2 job success rate (monthly) | 98% or more, with all failures investigated | Job reports | | Planned restore tests completed on time | 100% | Test log | | Restore tests meeting RTO and RPO | 95% or more | Test log | This policy is reviewed at least annually, and after a major incident, a failed restore of T1 data, a change of cloud provider or backup platform, or a change to the business impact analysis. Breaches of this policy are handled under the disciplinary process (`isms/security-disciplinary-process`) where they result from wilful misconduct. ## 14. References | Reference | Edition and status (checked 2026-11-01) | Use | |---|---|---| | ISO/IEC 27001:2022 + Amd 1:2024 | Current; https://www.iso.org/standard/82875.html and https://www.iso.org/standard/88435.html | Control A.8.13 and related controls | | ISO/IEC 27002:2022 | Current; https://www.iso.org/standard/75652.html | Control guidance | | ISO/IEC 27031:2025 | Current; https://www.iso.org/standard/80975.html | ICT readiness for business continuity | | ISO 22301:2019 + Amd 1:2024 | Current, revision at CD stage; https://www.iso.org/standard/75106.html | Business continuity link | | NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems | May 2010, updated November 2010 | Free reference on backup and recovery planning | | Related templates | `ops/backup-policy`, `ops/backup-restore-procedure`, `ops/disaster-recovery-plan`, `ops/dr-test-report`, `isms/backup-restore-test-log`, `compliance/business-impact-analysis`, `compliance/business-continuity`, `isms/control-evidence-matrix`, `compliance/statement-of-applicability` | | ## Standard and licence note Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (Annex A control A.8.13 and related controls) and ISO/IEC 27002:2022. Control numbers are cited with short labels written for this template; no text, tables or guidance from ISO or IEC standards is reproduced, and you need the official standards to implement and audit the control. The 3-2-1-1-0 convention is an industry practice. NIST SP 800-34 Rev. 1 is a US government work. EU legal texts are cited by article only. All other text and examples are original. Check the current editions before use. Official text: https://www.iso.org/standard/82875.html and https://www.iso.org/standard/75652.html (also available from national standards bodies). Template licence: MIT.