ISO 27001 Control 5.30: ICT Readiness for Business Continuity

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

Introduction

Virtually nobody tests their backups. I say that on almost every audit, and it is almost always true. The backups exist, the dashboard is green, and nobody has ever actually restored anything from them to see whether it works. Control 5.30 requires ICT readiness to be tested, so it should be done.

The second thing I hear is: “we can’t trigger a disaster recovery situation, but we know how we’d recover if it happened.” That may well be true. But you do not need to cause a disaster to test your plan. At the very least, run a desktop scenario where you step through the plan as a team and make sure it holds water.

Control 5.30 was new in the 2022 edition. This page covers what it asks for, how to set recovery objectives that mean something, how to test proportionately (starting with your backups), and how to run a tabletop exercise without triggering anything at all.

What control 5.30 actually asks for

The requirement is that ICT readiness is planned, implemented, maintained and tested based on business continuity objectives and ICT continuity requirements. In practice:

• Business continuity objectives: how long each critical activity can be interrupted, decided by the business.
• ICT requirements that follow from them: recovery time and recovery point objectives for the systems those activities depend on.
• Arrangements that can meet those objectives: backups, redundancy, recovery procedures, alternative services.
• Testing that proves it, with records.
• Maintenance, so the arrangements keep up as systems change.

The verb that matters most is “tested”, and it is the one most often missing.

Where 5.30 sits among the continuity controls

5.30 is the technology half of continuity.

5.30 proves the technology can be recovered in the time the business needs. Control 5.29 keeps security intact during disruption; 8.13 makes sure there is something to recover from; 5.30 ties them to real objectives and tests them.

Start with recovery objectives

Before you can test anything, you need to know what “recovered in time” means. Two numbers per critical system:

• Recovery time objective (RTO): the longest the system can be unavailable before the impact becomes unacceptable.
• Recovery point objective (RPO): the maximum amount of data, measured in time, you can afford to lose. A 24-hour RPO means you can lose up to a day’s work, which means you need at least a daily backup.

These are business decisions, not IT ones. Ask the people who use each system how long they could cope without it and how much work they could afford to redo. Then check whether your backups and recovery arrangements can actually deliver those numbers. It is surprisingly common to find a system the business says can lose no more than four hours of data, backed up once a week.

Test your backups

This is the minimum, and it is where I would start. A backup you have never restored from is not a control; it is a hope.

A restore test does not need to be dramatic:

• Pick something real: a mailbox, a folder, a database, a whole server image.
• Restore it somewhere safe, not over the live version.
• Check it actually works: files open, the database starts, the counts match.
• Time it, and compare with the RTO.
• Write it down: what was tested, how long it took, whether it worked, and what went wrong.

Do it at least annually for each critical system, and more often for the most critical. The first test almost always finds something: a backup that has been silently failing, a restore that needs a password nobody has, a process that takes three times longer than anyone assumed. Far better to find that on a quiet Tuesday than in the middle of a ransomware attack.

You can’t trigger a disaster, but you can rehearse one

Most organisations tell me they cannot trigger a real disaster recovery or business continuity situation, and they are right; nobody expects you to take your business offline to prove a point. But that does not excuse you from testing the plan.

A tabletop exercise is the answer. Get the people who would respond around a table for an hour or two. Give them a realistic scenario: ransomware has encrypted the file server and OneDrive on a Monday morning; your cloud accounting provider is down for three days; your IT provider’s office has burned down. Then step through the plan together. Who does what? Where are the instructions? How long would each step take? What happens when the answer is “we’d ask Dave”, and Dave is on holiday?

It costs nothing, it does not touch a live system, and it reliably finds the gaps: missing contact numbers, unclear authority, recovery steps that depend on systems that would themselves be down.

If you want ready-made scenarios, the NCSC’s free Exercise in a Box service has a set designed for exactly this, including ones aimed at small organisations. It is well worth a look.

Test in proportion

I think of testing as four levels, each building on the one before:

1. Backup restore tests: restoring real data and checking it, at least annually per critical system.
2. Tabletop exercises: walking through a scenario with the team, at least annually.
3. Partial failover: recovering a critical system in a test environment end to end.
4. Full exercise: a live test of recovery arrangements.

For ISO 27001, most small businesses should be doing the first two as a minimum. The third and fourth are for organisations whose objectives or customer commitments demand them. Whatever level you reach, record it: what was tested, what happened, what was found and what was changed.

What auditors will look for

As a Lead Auditor, this is broadly how I would work through 5.30.

1. Critical systems and their objectives. Which systems matter most, and what are their RTO and RPO? Who decided?
2. Arrangements against objectives. Can your backups and recovery methods actually meet those numbers?
3. Restore tests. Show me the last time you restored something from backup, and the record of it.
4. Exercises. When did you last walk through your continuity plan as a team, and what did you find?
5. Actions. What changed as a result of the last test or exercise?
6. Maintenance. When systems change, how do the recovery arrangements keep up?

Common issues

• Backups that have never been restored from.
• Backup dashboards showing green while a backup job has been silently failing.
• No recovery objectives, so nobody knows whether recovery would be fast enough.
• Recovery objectives set by IT without asking the business.
• Backup frequency that cannot meet the stated RPO.
• “We can’t test it” used as a reason not to test anything, including a tabletop.
• Recovery steps that depend on systems that would themselves be down.
• Test results never recorded, so there is no evidence and no learning.

The self-check

Five questions. If you cannot answer them today, an auditor will find that out for you.

• When did you last restore something from backup, and did it work?
• For your most critical system, how long could the business cope without it, and how much data could it afford to lose?
• Does your backup frequency actually meet that?
• When did you last walk through your recovery plan as a team?
• If your file server and OneDrive were encrypted tomorrow morning, how long would recovery take, really?

If the honest answer to the first question is “never”, that is the place to start this week.

A worked example

The figures below are typical rather than drawn from a single engagement. This is a composite of a first round of continuity testing in a business of this size.

A 35-person manufacturer with Microsoft 365, a cloud accounting package and one on-premises server running its production scheduling system. Backups had been in place for years. None had ever been tested.

What testing found

• The production scheduling server’s nightly image had been failing for seven weeks. The alert went to an engineer who had left.
• The first successful restore of that server took nine hours. The business had assumed two.
• Production said it could lose no more than four hours of scheduling data. The server was backed up nightly.
• A tabletop exercise using an NCSC Exercise in a Box ransomware scenario found that nobody knew who could authorise spending on outside recovery help, and the backup provider’s out-of-hours number was not written down anywhere.

What changed

• Backup failure alerts redirected to a monitored mailbox, with a weekly check.
• Recovery objectives agreed with the business for each critical system and recorded.
• Scheduling server backups moved to every four hours to meet its RPO, and a standby recovery procedure written that brought restore time down to three hours.
• Spending authority added to the incident roles sheet; the out-of-hours number added to contacts.
• Annual restore tests and an annual tabletop scheduled and logged.

Two days of effort across a month. The failed backup alone would have turned a bad day into a catastrophic one.

How control 5.30 links to other clauses and controls

• Control 5.29, Information security during disruption. Keeping security intact while the technology is being recovered.
• Control 8.13, Information backup. Backups, and testing that they restore, are the foundation of ICT readiness.
• Control 8.14, Redundancy of information processing facilities. Resilience that reduces how often you need to recover.
• Control 5.24, Information security incident management planning and preparation. Most recoveries start with an incident.
• Control 5.23, Information security for use of cloud services. Your recovery may depend on cloud providers’ own arrangements, and your exit plan.
• Control 5.20, Addressing information security within supplier agreements. Who restores your data is a contractual question as much as a technical one.

What I find in audits

In around 90% of the roughly 30 organisations I have audited or implemented ISO 27001 for since 2024, a restore from backup had never been tested. I have seen a technology company whose backups had been silently failing for months without anyone noticing. In my 2026 survey, only 15% of security professionals felt fully ready to recover from ransomware. More detail is in my findings report.

Frequently asked questions

Sources and further reading

Official legislation, standards and guidance referred to on this page.

• Exercise in a Box. Free NCSC tool with ready-made scenarios for testing your response to a cyber incident.
• Backing up your data. NCSC guidance for small organisations.
• ISO 22301:2019, Business continuity management systems. The international standard for business continuity management.
• ISO/IEC 27001:2022, Information security management systems. The standard itself, published by ISO.

Internal Audit Service

Get an independent view of your ISO 27001 ISMS before you go into an audit.

“Alan from Iseo Blue truly came to our rescue. His support ahead of our internal audit was outstanding, and he helped us get our ISMS 100% ready for the Phase 2 audit.“

– Quartile.

✓ Gain confidence
✓ Audit plan
✓ Independent view
✓ An ISO 27001 requirement

✓ Audit findings report
✓ Recommendations
✓ Review meeting
✓ Fixed price

£2,500

+ VAT where applicable

View DetailsBook a discovery call