Backup Management and Retention Procedure

1. Purpose

This procedure sets out how the Organisation decides what to back up, performs and watches backups, stores media safely, keeps data for the right length of time, restores it on request and proves by testing that it can be restored, so that data lost through error, failure, attack or disaster can be recovered within the recovery objectives agreed with the business.

It implements the Backup and Restoration Policy and feeds the recovery targets used in the BCP and DR Procedure.

2. Scope

The procedure covers all information that the Organisation owns or is responsible for, held on systems the Organisation operates or has outsourced, in any location.

• In scope: servers, databases, virtual machines, containers and their persistent volumes, network and security device configurations, source code and build pipelines, cloud tenants and software-as-a-service data, email and collaboration data, and business documents on file shares.
• In scope: endpoint data that is not synchronised to a managed repository, where the Organisation decides to back it up [for example administrator and executive laptops].
• In scope: backup software, catalogues, encryption keys for backup media and the media themselves.
• Out of scope: data on personal devices outside device management, and temporary data that can be regenerated without loss [such as caches and build artefacts].

3. Terms and Definitions

4. Roles and Responsibilities

5. Backup Principles

• At least [three] copies of important data, on [two] different types of media or services, with [one] copy held offsite and [one] copy immutable or air-gapped.
• Backup data is encrypted in transit and at rest under the Cryptography Procedure, and the keys are held separately from the backup data.
• Backup administration uses its own accounts with multi-factor authentication; production administrators cannot delete backups.
• A backup that has never been restored is treated as unproven until a test succeeds.
• Backups of personal data follow the same minimisation and retention rules as production data; retention in backups is not a reason to keep data longer than the retention schedule allows without a documented basis.

6. Identification of Data to be Backed Up

No system goes live without a decision on its backup. The data owner and the backup administrator make the decision together, using the steps below, and record it in the backup scope register (Annexure A).

1. InventoryList the systems and data sets from the asset register held under the Asset Management Procedure, including cloud and software-as-a-service data.
2. ClassifyTake the classification from the Information Classification and Handling Procedure; it decides encryption, access and media handling.
3. Set objectivesThe data owner sets RPO and RTO, using the business impact analysis in the BCP and DR Procedure and the tiers below.
4. Select methodThe backup administrator chooses the method, frequency, location and number of copies that meet the objectives, and estimates capacity and cost.
5. Set retentionRetention is taken from the retention schedule in this procedure; Legal and Compliance confirm where law or contract applies.
6. ApproveThe data owner and the Head of IT Operations approve the entry. Exclusions are approved in writing with the reason and the risk accepted.
7. Implement and verifyThe job is configured, run once, and test-restored before the system is accepted into production.
8. MaintainThe register is reviewed [every 6 months], and whenever a system is added, changed, moved or retired.

6.1 Backup types and schedule

6.2 Items excluded from backup

Data not backed up must be listed with the reason. Common cases are temporary files, caches, build outputs, personal data not authorised for retention, and data that the customer's contract requires the Organisation not to copy. The owner reviews each exclusion at the scope review.

7. Backup Monitoring

Backups are monitored every working day. A silent failure is the main risk, so absence of a success message is treated as failure.

1. CheckThe backup administrator reviews the dashboard and job reports by [09:30] every working day and records status in the backup log (Annexure B).
2. Classify the resultEach job is marked Success, Warning or Failed. Warnings that repeat on [two] consecutive runs are treated as failures.
3. RespondA failed Tier 1 job is raised as a high-priority ticket and rerun within [4 hours]. A failed Tier 2 or Tier 3 job is rerun within [1 working day].
4. EscalateIf a Tier 1 backup remains failed for more than [24 hours], or any data set has no good copy for longer than its RPO, the Head of IT Operations and the data owner are informed and the risk is recorded.
5. Review capacityStorage use and growth are reviewed [monthly]; an alert is raised at [80 percent] of capacity.
6. AnalyseFailure causes are reviewed [monthly] and repeated causes go to problem management.

8. Backup Media

Media includes disks, tapes, appliances, removable drives and cloud storage. Every item is registered as an asset and is encrypted.

• Media leaving the premises travels in a locked, tamper-evident container with a courier or a named employee and is logged in the media movement log (Annexure E).
• Labels show a media number and date, not the data classification or system names.
• Offsite and cloud storage locations are chosen so that a single event cannot reach both copies; where customer or regulatory commitments require data to stay in a country or region, the location respects that.
• Media found to be faulty are reported, replaced and handled under the destruction rules in this procedure.
• Where an incident calls for the preservation of logs, the Organisation keeps ICT logs for [180 days] within Indian jurisdiction as required by the CERT-In Directions of 28 April 2022 [confirm the current requirement].

9. Data Retention

Data is kept for as long as the law, contract or the business needs it and then deleted. Retention periods for backup copies follow the periods below; they do not create new reasons to keep data.

Legal and Compliance may order a legal hold. Backup media or points covered by a hold are labelled, removed from the rotation schedule and kept until Legal and Compliance releases them in writing. Where a data subject's erasure request is upheld, the primary copy is deleted at once and copies in backup expire in the normal cycle; the data is not restored into production without being deleted again.

10. Backup Restoration

10.1 Restore requests

1. RequestA user or system owner raises a restore request in [the ticketing tool] stating the data, location, time to restore to, and the reason. Annexure C is the request form.
2. Verify and authoriseThe service desk confirms the identity of the requester. The data owner approves the restoration of Confidential or Restricted data. Restores that overwrite production need a change ticket.
3. PlanThe backup administrator identifies the right restore point, the target (original location or an alternative), the expected duration and any risk to running services.
4. RestoreThe restore is carried out into a quarantine area first when the cause of loss is unknown or malware is suspected, and scanned before release.
5. ValidateThe requester or owner confirms completeness and integrity; the administrator compares record counts or checksums where available.
6. CloseThe restore is logged with start and end times, points used, outcome and sign-off; the original request is closed.

10.2 Restoration after a security incident

Where ransomware, tampering or an intrusion is suspected, the Incident Management Procedure takes precedence. The Information Security team decides which restore point is safe, systems are rebuilt from clean images before data is restored, and credentials and keys are rotated before the restored service is reconnected. Restoration is tested for persistence of the threat, and backups taken during the compromise period are quarantined until cleared.

10.3 Restoring from third-party services

For cloud and software-as-a-service data, the data owner confirms the provider's restore options and limits in advance. The service owner records the provider's contact route, the maximum retention of its own backups and what can be restored by customers, and tests the process at the scheduled test.

11. Restoration Testing

Restore tests show that media can be read, keys are available, procedures are right and the RTO can be met. Tests are scheduled in the exercise programme under the BCP and DR Procedure.

1. PlanThe backup administrator proposes the test, scope, date and rollback, and the system owner agrees a time that avoids production risk.
2. ExecuteThe test is run by someone other than the person who set up the backup, in an isolated environment, using only the documented procedure.
3. MeasureStart time, end time, data volume, restore point, errors and manual steps are recorded in the test report (Annexure D).
4. EvaluateResults are compared with RPO, RTO and the success criteria. A failed or slow test is a finding.
5. Fix and retestCorrective actions have owners and dates; failed tests are repeated within [30 days] after the fix.
6. ReportThe report is signed by the system owner and Head of IT Operations and kept as evidence. Summary results go to management.

12. Secure Disposal of Backup Media and Data

1. IdentifyMedia reaching the end of the retention period, its useful life, or found faulty is identified from the media register [monthly]. Media under a legal hold are excluded.
2. ApproveThe data owner approves the disposal of media that carried Confidential or Restricted data. The Head of IT Operations approves the batch.
3. Sanitise or destroyDisks and tapes are cryptographically erased, overwritten or physically destroyed according to the Asset Disposal Process. Media with Restricted data are destroyed physically and witnessed by Information Security.
4. Delete cloud copiesCloud copies are deleted after the object-lock period expires. The deletion is confirmed by logs from the provider and, where available, a deletion certificate.
5. Destroy keysWhere cryptographic erasure is the method, the key and all key copies are destroyed and logged under the Key Management Process.
6. CertifyThe disposal certificate is signed and filed; the media register is updated to Disposed.

13. Protection of Backups against Tampering and Ransomware

Attackers target backups before they trigger an attack. The controls below keep at least one good copy out of their reach.

• Backup administration is separate from production administration. No account has both the right to change production systems and the right to delete backups.
• Backup consoles, repositories and storage are on a management network segment that is not reachable from user networks, and reachable only through multi-factor authentication.
• At least one copy of Tier 1 and Tier 2 data is immutable for [30 days] or offline, so that it survives compromise of the main environment.
• Deleting a backup set, shortening retention or disabling a job requires approval from a second person [dual control] and generates an alert to Information Security.
• Backup agents and service accounts have only the rights needed to read data; they cannot modify production files.
• The backup system's own configuration and catalogue are backed up and stored offline, so the system can be rebuilt after a total loss.
• A clean-room restore of a sample from the immutable copy is tested [every 6 months] to prove it is usable and free from malware.

14. Cloud and Software-as-a-Service Data

A provider's resilience is not a backup. The provider usually protects the service, not the customer's data against deletion by a user, an administrator error or an attacker.

1. UnderstandThe system owner reads the provider's terms to learn what is backed up, for how long, how it can be restored and what it costs, and records it in the backup scope register.
2. DecideWhere the provider's retention or restore options do not meet the objectives, the system owner arranges an independent backup to a separate account, region or provider.
3. ProtectBackup copies are encrypted with keys the Organisation controls and the backup account is separate from the source tenant.
4. TestA restore from the provider or the independent copy is tested [annually] and results recorded.
5. ExitBefore a service ends, the owner makes sure a full export exists and is kept for the required retention before the provider deletes the tenant.

15. Backup Access and Encryption Key Management

16. Roles and Responsibilities Matrix

17. Measures

18. Reporting and Management Review

The Head of IT Operations reports on backup management to the Information Security Steering Committee [quarterly] and includes a summary in the management review.

• Success and failure rates, causes of failure and repeated incidents.
• Restoration test results, findings and corrective actions with status.
• Capacity, growth and cost of storage with a forecast.
• Exceptions, exclusions and risks accepted.
• Changes needed to objectives, tools or this procedure.

19. Records and Evidence

Annexure A: Backup scope register

Annexure B: Daily backup log

Annexure C: Restore request form

Annexure D: Restoration test report

Annexure E: Media movement log

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

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

22. 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 and Restoration Policy
• BCP and DR Procedure
• Information Classification and Handling Procedure
• Documents and Records Management Procedure
• Asset Disposal Process
• Cryptography Procedure
• Data Protection and Privacy Procedure
• Logging and Monitoring Procedure