Backup and Restoration Policy

1. Purpose

This policy makes sure that information and the systems that hold it can be recovered to a known good state after deletion, corruption, ransomware, hardware failure, human error or loss of a site. It sets the minimum rules for what is copied, how often, where copies are held, how they are protected, and how the Organisation proves that a restore actually works.

A backup that has never been restored is treated as unproven. The policy therefore gives restoration testing the same weight as taking the backup.

2. Scope

The policy applies to every information system, database, file store, configuration repository, cloud workload and SaaS tenant that holds information owned or processed by the Organisation, whether hosted on site, in a data centre or by a supplier. It applies to employees, contractors and suppliers who administer those systems.

• In scope: production systems, supporting services such as directory, DNS and certificate authorities, network and security device configuration, source code and build artefacts, email and collaboration data, and the backup infrastructure itself.
• In scope: laptops and mobile devices only where the Organisation has decided that data is held locally and cannot be recovered from a central source [the exception list is kept by the Head of IT Operations].
• Out of scope: personal devices holding no Organisation data, and temporary scratch or test data that can be regenerated within [1 working day] and is marked as such in the asset register.

3. Terms and Definitions

4. Roles and Responsibilities

5. Policy Statements

5.1 Backup planning and design

1. Every system must be assigned a backup tier by its system owner at onboarding and again at each annual review, and the tier, RPO and RTO must be recorded in the asset register.
2. Backup frequency must be no longer than the system RPO. Where the RPO is shorter than the time between scheduled jobs, the system must use continuous replication, log shipping or snapshots in addition to scheduled backup.
3. The restore method must be capable of meeting the RTO. A system whose measured restore time exceeds its RTO is a finding, and the owner must either fund a faster method or approve a longer RTO in writing.
4. Backups must follow the 3-2-1-1 pattern for Tier 1 and Tier 2 systems: at least [three] copies of the data, on [two] different media or services, with [one] copy held off site, and [one] copy immutable or logically isolated.
5. Backup scope must include configuration and the items needed to rebuild a service, not only data: infrastructure definitions, encryption keys or key escrow references, certificates, licence keys, directory data and runbooks.
6. Information that regulation or contract requires to be held in a given country must be backed up only to locations in that country. The Organisation's applicable law obligations are listed in the records of legal and contractual requirements.

5.2 Backup tiers and schedules

The table gives default values. A system owner may choose a stricter schedule, never a looser one, without a recorded exception.

5.3 Retention and expiry

• Backups must be deleted when the retention period ends, using a method that makes the data unrecoverable, and the deletion must be logged.
• Personal data in backups must not be restored into production if the data subject's erasure request has been completed since the backup was taken; the restore runbook must include re-applying erasure requests from the erasure log.
• Legal hold overrides expiry. The legal owner informs the backup administrator in writing, and held backups are labelled and excluded from automatic deletion until the hold is released.

5.4 Protection of backups

• Backups must be encrypted in transit and at rest using approved algorithms and key lengths as set in the Cryptography Policy. Encryption keys for backups must be stored separately from the backups, and key recovery must be tested together with data recovery.
• Access to the backup system must use named accounts with multi-factor authentication. Administrator rights over backup infrastructure must be separate from administrator rights over the systems being backed up, so that one compromised account cannot delete both data and its copies.
• Deletion or shortening of retention on a Tier 1 or Tier 2 backup must need approval from a second person [four-eyes control], and must raise an alert to the security monitoring team.
• The backup network, management console and storage must be segregated from user networks, and backup servers must be hardened and patched under the Patch Management Policy and Secure Configuration Policy.
• Removable backup media, where still used, must be labelled by classification, kept in locked storage, moved by authorised people with a transfer log, and destroyed at end of life under the Asset Disposal Process.
• Backups carry the classification of the data they contain and are handled under the Information Classification and Handling Policy.

5.5 Monitoring and failure handling

• Every backup job must produce a success, warning or failure result that is collected by monitoring. The backup administrator must review the results every working day by [10:00] and record the review.
• A failed Tier 1 backup must be reported as an incident within [1 hour] of detection and retried within [4 hours]. A failed Tier 2 backup must be corrected by the next working day. A job that fails twice in a row must be escalated to the Head of IT Operations.
• Capacity of backup storage must be monitored and reviewed monthly; free space below [20%] must trigger a capacity request under the Capacity Management and Planning Procedure.
• Changes to backup configuration, schedules or retention must follow the Change Management Policy and Procedure.

5.6 Restoration and testing

A restore is the only proof that a backup is usable. The following minimum test schedule applies.

• Restoration tests must be performed into an isolated environment, never over live data, unless the test is part of an approved disaster recovery exercise.
• The test record must state the system, backup used, start and end time, data loss measured, issues found and sign-off by the system owner. Failed tests must produce a corrective action with an owner and date.
• Where a test shows that an RTO or RPO cannot be met, the system owner must report this to the Head of IT Operations within [5 working days].

5.7 Third-party and cloud backups

• Where a supplier or cloud provider runs backups, the contract must state frequency, retention, location, encryption, who can access the copies, restore support times and the right to test or receive evidence of testing.
• SaaS data must not be assumed to be backed up by the provider. For every SaaS service holding Tier 1 or Tier 2 information, the service owner must either confirm provider backup meets this policy in writing or arrange an independent export or backup at the frequency in the tier table.
• Evidence from suppliers must be reviewed at least [annually] under the Supplier Relationship Management Policy.

6. Compliance and Monitoring

Adherence is checked through the following activities.

7. Measures

8. Procedure Reference

The detailed steps, job designs, runbooks and forms that implement this policy are in the Backup Management and Retention Procedure. Recovery after a major outage is handled under the BCP and DR Procedure. Where the two documents differ, this policy prevails until the procedure is corrected.

9. Records and Evidence

Annexure A: Restoration test record

10. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

11. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

12. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• Backup Management and Retention Procedure
• BCP and DR Procedure
• Information Classification and Handling Policy
• Cryptography Policy
• Information Security Aspects of Business Continuity Policy
• Logging and Monitoring Policy