Image showing data backup and continuity arrangements

Data Backup, Disaster Recovery and ICT Continuity

Backup in Brief

Backups tested by actually restoring, not just by checking the green tick
3-2-1 - three copies, two media, one off-site or air-gapped
Recovery time and recovery point objectives set against business need

Backup, Business Continuity and ICT Recovery

The information security model has three pillars - confidentiality, integrity, availability - and the third one is what backup, business continuity and ICT recovery are about. The other controls aim to keep information confidential and intact. These controls aim to keep it accessible when systems fail, files are corrupted, premises become unusable or attacks like ransomware destroy the working copy.

The three sit on a spectrum. Backup is the technical control that copies data so it can be restored. ICT recovery is the wider technical effort to get systems and infrastructure back up. Business continuity is the broadest layer - keeping the organisation operating, with or without its usual systems, until full service is restored. A working backup without a continuity plan can still leave the business stuck for days; a continuity plan without working backups is built on sand.

Backup as an Information Security Control

Backup is the single most useful control against the worst outcomes of a security incident. Files corrupted by a misbehaving application can be restored. Files encrypted by ransomware can be restored without paying the criminals. Files deleted by accident or by a disgruntled leaver can be recovered. None of this is possible without a backup that has captured the data and that can be relied on to restore it.

The 3-2-1 principle has stood up well over the years - three copies of important data, on two different media or systems, with one copy held off-site or offline. The reasoning is that any single failure mode (a hardware fault, a fire in the office, an attacker who reaches the network and deletes the local backup) is unlikely to take out all three copies at once. The off-site or offline copy is what survives a serious incident.

Modern backup adds the immutability angle. Ransomware attacks now routinely target backups specifically, encrypting or deleting them before going after the live data. An immutable backup - one that cannot be modified or deleted for a defined retention period, even by an administrator - removes that line of attack. Many cloud backup services offer this option, and it is increasingly considered essential rather than optional.

Restore Testing and Recovery Time

A backup that has not been tested is a hope, not a control. Restore testing - periodically picking a file or system and actually restoring it from backup - is what proves that the backup is working. The first restore test in many organisations finds that the backup has been failing silently for months, or that the restore process is not documented well enough for anyone other than the original system administrator to follow.

Recovery time matters as well as success. If the backup works but takes three days to restore, that is the period the business is without the data. The recovery time objective (RTO) is the documented expectation - the longest the business can tolerate being without a particular system - and the backup design should match. Some systems can tolerate days; others need to be back within hours; a few cannot tolerate any meaningful downtime and need a hot standby rather than a backup.

The recovery point objective (RPO) is the related question of how much data loss is acceptable. A backup taken every twenty-four hours means that a failure in the late evening could lose nearly a day's work. For some systems that is fine; for others it is unacceptable. The frequency of the backup needs to match the RPO, not be left at whatever the default schedule happens to be.

Business Continuity and ICT Recovery

Business continuity is the broader picture. If the office burns down, what does the organisation do tomorrow morning? If the main supplier goes out of business, who picks up the work? If a ransomware attack takes out half the systems for a week, how do the urgent jobs still get delivered? These are not technical questions - they need answers from the people who run the business as well as the people who run the technology.

The continuity register and continuity plan record the answers. The register identifies the activities the business needs to keep doing, the systems and resources they depend on, the time the business can survive without each one, and the alternative arrangements that apply when normal operations are not available. The plan turns the register into actions that can be executed under pressure.

ICT recovery sits inside business continuity but has its own characteristics. It covers how systems are restored, in what order, with what dependencies, using what resources. A serious incident affecting multiple systems benefits from a documented sequence rather than a free-for-all - the email system before the file server, identity before everything, and so on. The plan needs to be tested at least annually and ideally exercised through simulated incidents.

Backup is the control that lets you say no. Ransomware demand for fifty grand? With working backups, no. Accidental deletion of a major document? No drama. Server caught fire? Inconvenience, not disaster. Without a working tested backup, every one of those becomes either an expensive negotiation, a long hard recovery, or a closed business. The cost of getting backup right is small. The cost of getting it wrong is enormous.

The first thing I ask in a backup audit is when the last successful restore test was carried out. The answer is often that the backups run but have never actually been tested. That is not a backup, that is wishful thinking. The second thing I ask is whether the backup is reachable from the main network with administrator credentials, because if it is, ransomware can reach it too. Immutable or air-gapped backups are now the expected position, not an extra.

For business continuity I look at whether there is a written plan, when it was last reviewed and exercised, and whether the people named in it actually know what they are supposed to do. Plans that have never been exercised tend to fall apart on first contact with a real incident.

We exercise our continuity plan once a year. The first one, a few years back, found that two of the three named recovery contacts had left the company. Since then it has been part of the annual cycle - exercise the plan, update the contacts, document the lessons.

Practical Compliance Guidance

The IMS1 Manual covers backup, business continuity and ICT recovery as part of the wider information security and business continuity sections. The continuity register sits alongside the information security risk register, with overlapping risks cross-referenced rather than duplicated.

The following alphaZ documents support a practical approach to backup, business continuity and ICT recovery.

alphaZ document	How to use it
ISO 27001 Toolkit	Full document set for setting up an information security management system, including the backup, continuity and ICT recovery procedures.
PP-8-01 Data Backup Policy Procedure	Procedure covering backup scope, frequency, retention, off-site copies, restore testing and the response when backups fail.
P-34 Business Continuity Policy Statement	Top-level commitment to maintaining critical activities through disruption, with the management framework and responsibilities.
PP-1-05 Business Continuity Policy Procedure	Procedure covering business impact analysis, continuity planning, exercising the plan and managing through actual incidents.
ER16 Business Continuity Risk Register	Register of continuity risks, the activities they would affect, the time tolerances and the recovery arrangements in place.
F-IMS21 Business Continuity Register	Register of critical activities, dependencies, recovery time objectives and the alternative arrangements that apply.
F-Q94 Business Continuity Plan Form	Template for documenting the continuity plan itself - who does what, in what order, with what resources.
F-Q95 Disaster Recovery Plan Form	Template for the technical disaster recovery plan covering ICT systems, sequencing and dependencies.
F-Q93 Continuity Test Record	Record of continuity exercises and tests, the scenarios used, the lessons learned and the actions taken.

Note - all the above files can be downloaded with an alphaZ subscription.

Frequently Asked Questions

Are cloud services backed up automatically?

Most cloud providers protect against their own infrastructure failures but do not protect customers against their own mistakes. A user deleting a file, an account being compromised, a sync error replacing good data with corrupted data - these are usually the customer's responsibility to recover from. Major business cloud services (Microsoft 365, Google Workspace, Salesforce and similar) have well-developed third-party backup products that handle exactly this gap. The shared responsibility model needs to be understood for each service the organisation depends on, and gaps filled with additional backup where needed.

How often should backups be tested?

Test restores should happen frequently enough that a failure is caught quickly and the team is practised in the process. Monthly is a good baseline for important systems, with full disaster recovery exercises at least annually. The test does not have to be a full restore every time - a sample file from a recent backup, restored to a non-production location, is enough to confirm the basic chain is working. The annual exercise should be a more substantial test that includes the people who would have to act in a real incident.

What is an immutable backup and do we need one?

An immutable backup is one that cannot be modified or deleted for a defined retention period, even by someone with administrator credentials. The point is that an attacker who breaks into the systems cannot reach the backup and destroy it before encrypting the live data. With ransomware now routinely targeting backups specifically, immutable storage has moved from being a nice-to-have to being the expected approach for any organisation that holds meaningful information. Most cloud backup services offer this as an option, often at little additional cost.

Do we need a separate disaster recovery plan as well as a continuity plan?

For most organisations the answer is yes, but the two are closely linked. The disaster recovery plan is the technical document that covers how systems are restored - sequencing, dependencies, who does what at the keyboard. The business continuity plan is the broader document covering how the business keeps operating during the recovery and what the alternative arrangements are. Smaller organisations sometimes combine them into one document; larger organisations or those with complex IT environments find it easier to separate the technical and business angles. Either way, both perspectives need to be covered somewhere.

UK Legislation

The following UK legislation is directly relevant to backup, business continuity and ICT recovery. Organisations outside the UK should identify the equivalent legislation applicable in their jurisdiction.

Further Resources