Information backup

What the requirement asks

Backups of information, software and systems are to be kept and tested regularly as the agreed topic-specific backup policy requires. Purpose: be able to get data and systems back after they are lost. Guidance: set a backup policy reflecting retention and security requirements, provide backup facilities sufficient to recover all essential information and software after an incident, failure or media loss, and develop and implement plans for backing up information, software and systems. A backup plan should consider: accurate, complete records of backup copies and documented restore procedures; the extent (full or differential) and frequency of backups, set by business requirements such as the recovery point objective (5.30), the security needs of the information and how critical it is to continued operation; storage in a safe remote location far enough away to escape a disaster at the main site; physical and environmental protection of backups consistent with the main site (Clause 7, 8.1); regular testing of backup media so they can be relied on, restoring to a test system rather than over the originals in case the backup or restore fails and destroys data; encrypting backups according to risk, for example where confidentiality matters; and making sure accidental data loss is noticed before the backup runs. Operational procedures monitor backup runs and deal with failed scheduled backups so backups are complete. Backup arrangements for individual systems and services are tested regularly against incident response and continuity objectives, together with the restore procedures and the recovery time the continuity plan requires; for critical systems, backups cover all system information, applications and data needed to rebuild the whole system after a disaster. For cloud services, back up the organization's own data, applications and systems held in the cloud environment and decide whether and how the provider's backup service meets requirements. Set retention periods for essential information including archive copies, and consider deleting information from backup media when retention expires (8.10), within the law. Other information: ISO/IEC 27040 covers storage security and retention. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Backup is only a control if restore is tested. The guidance asks for the scope, the frequency, the copy, the test and the result.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep the topic-specific backup policy and backup plans stating scope, extent, frequency and retention per system aligned with RPO and one live sample together.

Evidence an assessor asks for

• Backup policy and planThe topic-specific backup policy and backup plans stating scope, extent, frequency and retention per system aligned with RPO
• Backup policy and planBackup job monitoring reports with evidence that failed jobs were investigated and rerun
• Backup policy and planRestore test records onto test systems, checked against the recovery time in the continuity plan
• Backup policy and planEvidence of off-site or geographically separate backup storage with suitable physical protection
• Backup policy and planBackup encryption configuration and key management where confidentiality requires it
• Backup policy and planAssessment of cloud provider backup capabilities, or independent backups of cloud-hosted data and configurations

The question an assessor will ask

An assessor will ask for the topic-specific backup policy and backup plans stating scope, extent, frequency and retention per system aligned with RPO, then trace it to the system it protects. For A.8.13 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common gaps

• Backups run but full system restores have never been tested
• Backups are stored in the same site or cloud region as production
• Cloud SaaS data is assumed to be backed up by the provider
• Backup failures are logged but not followed up, leaving gaps

Before the next audit

Before the next audit, check one live sample for this gap: backups run but full system restores have never been tested.