Backup and Recovery Controls Explained for ISO 27001

Share with

Contents

Backup and recovery controls are the safeguards that make sure a usable copy of your information exists, stays protected, and can be put back within an agreed time. Almost every organisation has backups running somewhere. Far fewer can show, with evidence, that a restore actually worked last month. That gap between "we take backups" and "we can recover" is exactly what backup and recovery controls are built to close.

Inside an information security management system, these controls carry the availability side of the confidentiality-integrity-availability model, and they quietly support integrity too. A backup that cannot be verified is not evidence of anything. Strong backup and recovery controls answer four questions in writing: what gets copied, how often, where the copies sit, and who has proven they can bring the data back.

What Backup and Recovery Controls Cover

These controls are a set of rules and routines, not a single piece of technology. A complete set usually covers:

Backup scope, meaning which systems, databases, mailboxes, configurations and files are included
Backup frequency and retention periods
Storage location, media type and offsite or offline copies
Encryption and access restrictions applied to backup data
Restore procedures with named responsibilities
Restore testing and the records that prove testing happened
Monitoring of backup job success and failure

The last two matter most in practice. Backup software reports success far more often than a restore actually succeeds, because a job can complete while silently skipping a locked database or a newly added server.

Why Backup and Recovery Controls Belong in Your ISMS

Data loss rarely arrives with a warning. It comes from ransomware, a mistaken deletion, a failed migration, hardware failure or a departing employee wiping a shared drive. Your information security risk management process will flag most of these, and backup is one of the few controls that reduces the impact of nearly all of them at once.

There is also a compliance angle. Auditors, customers and regulators increasingly ask for restore test records rather than backup policies. A policy shows intent. A dated restore log with a named tester shows capability.

One more reason is cost. Recovery from a verified backup is measured in hours. Recovery without one is measured in weeks of rebuilt records, lost transactions and customer explanations.

Key Elements of Effective Backup and Recovery Controls

Defining Backup Scope Through Asset Classification

You cannot protect what you have not listed. Start from your information asset register and use asset identification and classification to decide what needs backing up and how quickly it must come back.

A practical approach is to sort assets into three tiers. Tier 1 covers systems that stop the business within hours, such as the ERP or customer database. Tier 2 covers systems the business can work around for a day. Tier 3 covers archives and reference data. Each tier gets its own backup frequency and recovery target, which stops you from paying premium recovery costs for data nobody urgently needs.

Setting Recovery Point and Recovery Time Objectives

Two numbers drive the whole design. The recovery point objective is how much data you can afford to lose, measured in time. The recovery time objective is how long you can afford to be down. If your RPO is four hours, hourly or four-hourly backups are the minimum. If your RTO is two hours, tape stored in an offsite vault will not meet it.

Agree these numbers with business owners, not with IT alone. The usual failure is IT choosing a nightly backup while the finance team assumes they will never lose more than an hour of postings.

Protecting Backup Copies With Encryption and Access Rules

Backup sets are a complete copy of your most sensitive data in one convenient package, which makes them a target. Encrypt backups at rest and in transit, and manage the encryption keys separately from the backup media.

Apply the same access control management rules you use for production. Backup administrators should be a small, named group with multi-factor authentication. Restore rights should be separate from delete rights, so a single compromised account cannot destroy both the live data and its copies.

Keeping Offline and Immutable Copies

Modern ransomware looks for backup repositories before it encrypts anything, because attackers know that a working backup removes their leverage. The common answer is the 3-2-1 rule: three copies of data, on two different media types, with one copy offsite. Many organisations now extend it to 3-2-1-1, adding one copy that is offline or immutable, meaning it cannot be altered or deleted for a fixed retention window even by an administrator.

Testing Restores on a Schedule

A backup is a hypothesis until it is restored. Set a testing calendar, for example a full restore of one Tier 1 system every quarter and a file-level restore every month, and rotate which system gets tested so coverage builds over the year.

Record the date, the system, who performed the restore, how long it took, and whether the recovered data was complete and correct. Compare the actual restore time against your stated RTO. When the two do not match, that becomes a finding to address rather than a surprise during a real incident.

Try Effivity for Free and set up your first backup verification checklist with automatic reminders.

Free Trial →

Backup and Recovery Controls in ISO 27001

ISO 27001 addresses backup within Annex A controls, where the requirement is to maintain and regularly test backup copies of information, software and systems in line with an agreed backup policy. The 2022 revision groups this under technological controls, alongside redundancy and logging.

The certification body will normally ask for four things: the backup policy, the backup schedule showing what is in scope, monitoring evidence such as job reports, and restore test records. Weak evidence in the fourth area is one of the more common findings raised during an ISO 27001 audit.

Backup also links directly to your disaster recovery planning and to business continuity management. Backup restores the data. Continuity planning decides which processes come back first and who tells customers. Auditors expect the two to agree on the same recovery targets.

Common Failures in Backup and Recovery Controls

Patterns repeat across audits:

Common Failures in Backup and Recovery Controls

New servers or SaaS applications are added to production but never added to the backup schedule
Backup job alerts go to a shared mailbox nobody monitors, so failures run for weeks unnoticed
Restore testing is done on a small text file rather than a real database, which proves nothing about capacity or timing
Retention is set far longer than needed, creating unnecessary exposure of personal data
The person who knows the restore procedure has left, and the runbook was never updated

Treat every one of these as a candidate for your risk treatment plan rather than a technical afterthought.

Metrics Worth Tracking

Four measures give a fair picture of control health: backup success rate over the month, number of systems in scope versus systems actually covered, average measured restore time against the target RTO, and the age of the oldest untested backup set. When any of these drift, raise it through your information security incident management process so the correction is tracked to closure.

Managing Backup and Recovery Controls With Effivity

Effivity's information security management software holds the documentation and evidence side of these controls in one place. Backup policies sit under version-controlled document management, restore tests can run as scheduled tasks with automated reminders and sign-off, and any failed test can be logged as a non-conformance with corrective action tracking.

Because the platform maps risks to the 93 Annex A controls and auto-generates the Statement of Applicability, your backup evidence is already linked to the clause an auditor will ask about. Dashboards show overdue restore tests at a glance instead of buried in a spreadsheet.

Get a Free Personalized Demo to see how backup evidence is captured and reported inside Effivity.

Free Demo →

Frequently Asked Questions

They are the policies, technical measures and tests that ensure copies of data exist and can be restored. They cover scope, frequency, storage, encryption, restore procedures and restore testing.

Test critical systems at least quarterly and less critical systems annually. Every test should be recorded with the date, tester, duration and whether the restored data was complete.

Yes. ISO 27001 requires backup copies of information, software and systems to be maintained and tested regularly against an agreed backup policy.

Backup is the copy of data and the ability to restore it. Disaster recovery is the wider plan covering people, sites, systems and communication after a disruption.

Keep three copies of data on two different media types with one copy stored offsite. Many organisations add a fourth element: one offline or immutable copy.

Share with