ISO 27001 A.8.13: Prove that backups can restore useful service

What A.8.13 requires in practice

A.8.13 requires backup copies of information, software and systems to be maintained and tested regularly, in line with the organisation's agreed topic-specific policy on backup. Three types of material are named, so a copy of files alone may not be enough to restore working service.

In practice the organisation decides what must be recoverable and how quickly, makes copies accordingly and keeps those copies protected and available when needed. The test requirement is the part most often missed: the organisation has to check from time to time that copies can actually be restored. A backup job reporting success shows only that a copy was made.

Outputs include an agreed backup approach, working copies, protection for those copies and records of restoration tests with their results. The control does not set a schedule, a medium or a retention period; those follow from the backup policy and business needs. Restoring a realistic scenario to a separate environment is a method Sterling's teams recommend, not a stated rule.

Define what must be recoverable

Start with the business service and the information needed to operate it. A database may depend on software, configuration, access arrangements and other components before staff can use it. Confirm that the backup scope includes what is necessary for the intended recovery, rather than copying whichever folders were easiest to select.

Agree tolerable information loss and recovery timing with the responsible business owner. These decisions influence backup frequency, retention, storage and restoration arrangements. Connect them with ICT readiness for business continuity. A technical team should not silently decide how much customer work the organisation can afford to lose.

Protect copies and the ability to recover them

Backups can contain the same sensitive information as live systems. Apply suitable access, physical and technical protection, considering risks that could affect both the original and its copies. Where encryption is used, the recovery process also needs appropriate access to the required keys and supporting information.

Consider the consequences of a site incident, compromised administration or a damaged storage service. A copy that shares all the same failure conditions as its source may not provide the intended recovery capability. The appropriate separation and protection depend on the risk assessment, rather than on a universal formula applied without context.

Why tested backups matter to the business

Backups are the last line of defence when systems fail, data is corrupted or ransomware strikes. Their value is only realised if the business can restore what it needs in the time it can afford to wait. Many organisations discover on the worst day that a backup was incomplete, unreadable or missing a critical component. Tested recovery protects revenue, contractual commitments and reputation, and helps leaders make accurate promises to clients about recovery. It also shows the business has thought about its own dependencies, including cloud services and suppliers who may hold the sole copy. Insurers and customers increasingly ask when a restoration was last proven, and an auditor will want an example, not an assurance.

How to implement A.8.13

Work backwards from what the business must be able to recover, and prove the route works before the day it is needed.

1. Identify the information, software and system configurations the business cannot do without, and agree how much loss and delay it can tolerate.
2. Decide how each item is backed up, including cloud and supplier-held data where responsibilities may be shared.
3. Protect the copies from the same failures as the originals, such as ransomware, accidental deletion and site loss.
4. Monitor backup jobs and decide who reviews failures, how quickly they are resolved and how the business is told when a protected item has no recent good copy.
5. Schedule restoration tests that recover realistic scenarios, not only a single file, and record what happened.
6. Act on test findings, for example missing components, undocumented steps or slow recovery, and retest after each correction so improvement is proven.
7. Review the approach when systems, suppliers or recovery expectations change.

Illustrative software example: the missing configuration

Illustrative construction example: drawings stored at a project office

A hypothetical construction project keeps working drawings in a local repository and assumes that synchronisation to another device provides sufficient recovery. An authorised exercise examines what happens after an accidental deletion. The team finds that the deletion can also be reflected in the synchronised location.

The project owner evaluates an appropriate backup arrangement, including retained versions or separate recovery copies where suitable, and tests restoration of a designated sample. Staff confirm that the restored drawing is the correct version and is available through the approved workflow. The example demonstrates why a second visible copy is not automatically an adequate backup strategy.

Clarify cloud and supplier responsibilities

Determine what the provider actually supplies and what remains the customer's responsibility. Service availability, replication and a provider's own operational backups may not meet the organisation's information-recovery requirements. Review the service terms, available restoration options, retention and any dependencies on provider support.

Ask how recovery would be requested and verified. A statement that data is backed up is incomplete if nobody knows which account can initiate restoration or how long the process may take. Keep provider arrangements aligned with information deletion and retention decisions so old copies do not remain without a justified purpose.

Build confidence in recovery evidence

Common nonconformities with A.8.13

Backup findings usually concern the gap between copying and recovering.

• Backup jobs run and report success, but no restoration has ever been tested, so recovery time is a guess.
• Backups cover data but not the configuration or software needed to rebuild a working system.
• Backup copies stored where the same incident, such as ransomware, could reach them.
• Failed jobs ignored or left unresolved for long periods, with no one accountable for noticing.
• Cloud or supplier-held data assumed to be backed up, with no confirmation of what the provider actually does.