Backup Policy Template (ISO/IEC 27001 A.8.13)

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

Approvals

Revision history

Contents

• 1. Purpose, scope and authority
• 2. Roles and responsibilities
• 3. Backup tiers from risk and impact
• 4. Policy statements
• 5. Retention schedule
• 6. Ransomware and insider resilience
• 7. SaaS and cloud platform backups
• 8. Restore testing
• 9. Exceptions
• 10. Size tiers
• 11. Records and evidence
• 12. Control mapping
• 13. Compliance, measurement and review
• 14. References
• 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.

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:

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

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.

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

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

7. SaaS and cloud platform backups

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

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

10. Size tiers

11. Records and evidence

12. Control mapping

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

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

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.