---
title: "ISO 27001:2022 Annex A 5.30 ICT readiness for business continuity"
canonical: https://www.grcmana.io/vault/iso-27001/annex-a-5-30-ict-readiness-for-business-continuity
published: 2023-03-27
updated: 2026-10-07
author: "Harry West"
framework: "ISO 27001"
control: "A.5.30 ICT readiness for business continuity"
journeyStage: implementation
---

# ISO 27001:2022 Annex A 5.30 ICT readiness for business continuity

## Key takeaways

A.5.30 requires recovery targets set by the business and a technology recovery capability that is rehearsed against them. Lean cloud teams meet it with a lightweight BIA, signed RTO and RPO, immutable backups and automated restore tests. A full ISO 22301 system is not needed.

- **Control type** — A.5.30 is a corrective control protecting availability alone. It restores systems after a disruption has landed rather than preventing the disruption from occurring.
- **RTO and RPO** — Recovery time objective is how fast a service must return; recovery point objective is how much recent data you can lose. A business impact analysis sets both.
- **Proportionate scope** — At 25–250 staff, a lightweight BIA, signed targets, a working disaster recovery plan and an honest annual test satisfy the control. A separate certified continuity system is not required.
- **Audit evidence** — Auditors trace one critical service from its BIA entry to a signed target, the technical arrangement behind it and a timed restore test showing the target is met.

The due-diligence questionnaire asks for your recovery targets and the date of your last restore test. You have backups, but nobody has ever timed a restore, and the deal is waiting.

This guide covers ISO 27001:2022 Annex A 5.30 ICT readiness for business continuity for security leads and engineering heads at 25–250-person cloud-first firms. You get the plain-English requirement, a half-day way to set recovery targets, the engineering that makes them true, and the evidence an auditor samples. None of it needs a full continuity management system.

## What does ISO 27001 Annex A 5.30 require, and how does it differ from A.5.29?

ISO/IEC 27001:2022 Annex A control 5.30 ICT readiness for business continuity needs two things. The business sets recovery targets through a business impact analysis, and the technology team builds and rehearses a way to meet them. A.5.29 keeps security standards up during a disruption; A.5.30 restores the systems themselves, backed by A.8.13 backup and A.8.14 redundancy.

The control asks two questions of the business before an outage rather than during one. How fast must each service return, which is the recovery time objective (RTO)? How much recent data can you afford to lose, which is the recovery point objective (RPO)? A business impact analysis (BIA) answers both by ranking which activities matter most and how quickly each must resume.

The three controls divide the work like this:

- **A.5.29** keeps security standards up while a disruption is under way.
- **A.5.30** restores the systems themselves against targets the business set.
- **A.8.13 and A.8.14** supply the backup and redundancy that A.5.30 relies on.

Classification keeps the scope honest. A.5.30 is corrective, so it exists to restore normal operation once a disruption has landed, and it protects availability alone. Under ISO 27001 A.5.30, the proof is a recovery that works, not a policy that describes one.

For firms with regulated clients, downtime is a contractual event. Client SLAs, FCA operational resilience rules and, for financial-sector clients, DORA all assume you know your tolerable outage. They also assume you can prove you would stay inside it. "We have backups" without a tested restoration story fails that question.

Most small firms discover their real recovery capability during their first ransomware attack. Every gap then gets paid for in days of outage: the untested backup, the runbook on the encrypted server, the missing emergency admin.

## Do you need a full ISO 22301 business continuity system to meet A.5.30?

No. At 25–250 staff, a lightweight BIA, signed recovery targets, a working disaster recovery plan and an honest annual test satisfy A.5.30. All of it sits inside the ISMS. ISO 22301 is a separate management system with its own certificate. It is worth weighing only once clients ask for certified continuity, and building it early is over-engineering.

What the control needs is narrower than a management system. These four artefacts satisfy it:

- A **lightweight BIA**, even two pages, showing the impact reasoning.
- **Signed RTO and RPO** for each critical service.
- A **working DR plan** with runbooks someone else can follow.
- An **honest annual test**, with follow-up actions closed.

ISO 22301 covers the continuity of the whole business, not just its technology. It brings its own scope, policy, internal audits and management reviews, checked in a separate certification audit. A.5.30 asks only that the technology side of recovery is planned, built and proven.

A 30-person SaaS firm that builds the full machinery first risks a thick policy set and a thin restore capability. The scale calls for a sharp DR plan written against a lightweight BIA.

When an auditor reads your evidence against ISO 27001 Annex A 5.30 ICT readiness for business continuity, the question is whether recovery works. A second certificate does not answer it. Proportionate and provable is the audit-ready position.

## How do you set RTO and RPO targets with a lightweight BIA?

Run a half-day business impact analysis. List the few services the business really runs on. Ask how long each can be down and how much data you can lose, then record an RTO and RPO for each. Leadership signs the numbers, because they are business decisions, not IT ones.

The half-day session runs in four steps:

1. **List the services** the business really runs on. Usually that is the SaaS core, the product platform, identity and communications.
2. **Ask two questions** of each: how long can it be down before it really hurts, and how much data could we stand to lose?
3. **Write an RTO and RPO** for each service in plain numbers.
4. **Get leadership to sign** them, so the targets carry business authority.

A customer-facing platform might need to return within hours with almost no data loss, while an internal wiki can wait days and tolerate a day's loss. Put someone from sales or customer success in the room, since they know what downtime costs in contract terms.

Expect the analysis itself to take days of effort, not a consulting engagement. Run it early, because the same output feeds your risk assessment.

Where you fall within the FCA's operational resilience rules, the tolerance is not optional. The [FCA Policy Statement PS21/3 on operational resilience](https://www.fca.org.uk/publications/policy-statements/ps21-3-building-operational-resilience) applies to firms such as banks, insurers, enhanced-scope SM&CR firms and payment and e-money firms. They must set impact tolerances for the maximum tolerable disruption to each important business service, then map and test so they can stay within them. Where your clients are regulated, expect their tolerances to shape the targets they ask you to meet.

RTO and RPO figures chosen because they sounded professional are a wish list, not a recovery target.

A signed page of numbers with no failover or restore behind it fails twice. The auditor asks for the reasoning, and the first real outage asks for the engineering.

## How do you reconcile SaaS vendor SLAs with your own recovery commitments?

Map what each critical service depends on, vendors included, then test whether each provider's SLA and your cloud setup can support the RTO you signed. A four-hour target resting on a vendor offering only best efforts is fiction, so change the target or the dependency, and keep your own exports.

Work through it service by service:

1. **Map dependencies** for each critical service: the cloud region, the identity provider and every vendor it needs.
2. **Read the SLA** each provider actually commits to. "Best efforts" is not a number you can plan against.
3. **Compare** each commitment with the RTO leadership signed.
4. **Fix the mismatch**: relax the target with leadership's agreement, or change the dependency. A second provider, a higher tier or your own copy of the data all count.

Dependency mapping also exposes concentration. If identity, email and the ticketing tool all sit behind one provider, a single outage removes your ability to coordinate the recovery. Record that as a risk and decide deliberately whether to accept it.

Being fully SaaS does not hand the problem to your vendors. Our reading of ISO/IEC 27001:2022 Annex A 5.30 ICT readiness for business continuity is that the supplier holds the infrastructure layer while the outcome stays yours. Auditors increasingly probe exactly this.

Three things keep a SaaS-heavy estate recoverable:

- **Your own exports or backups** of the data each critical vendor holds.
- **Targets per service**, so a vendor outage is judged against its own number.
- **A plan for operating while the vendor is down**, such as a manual route for taking orders or answering support tickets.

Record the review date beside each SLA, so a changed contract becomes a prompt to revisit the RTO.

The vendor whose SLA nobody read until the outage is the cheapest gap to close. It costs an afternoon of reading and, if the numbers disagree, one honest conversation with leadership.

## What technical resilience does A.5.30 need: multi-zone, immutable backups and break-glass access?

Buy resilience where it is cheap. Deploy what you build across zones or regions. Keep at least one immutable backup copy that ransomware with admin credentials cannot rewrite, with its encryption keys held apart from production. Add break-glass accounts with hardware MFA, so recovery can start even when your identity provider is down.

Each element earns its place against a different failure:

- **Multi-zone or multi-region** deployment covers a zone or region outage for anything you build. Add dual internet routes if the office itself matters.
- **An immutable backup copy** survives an attacker holding admin credentials, as long as the same compromise cannot reach its keys.
- **Break-glass accounts** give emergency privileged access with hardware MFA, sealed and audited.

The immutable copy matters because backups are a target. [NCSC guidance on offline and cloud backups](https://www.ncsc.gov.uk/blog-post/offline-backups-in-an-online-world) describes incidents where ransomware encrypted not only the original data but also the connected storage holding its backups. Digital separation is what keeps one copy restorable.

Break-glass accounts solve a circular problem. If the identity provider is part of the outage, nobody can sign in to fix it. Sealed credentials with hardware keys let recovery start regardless, and every use leaves an audit trail.

Match the technique to the target, since RTO buys failover and RPO buys backup frequency. A tight RTO points to warm failover, since restoring from backup takes time you may not have. A looser RTO can rely on restore alone, which costs less. A tight RPO points to frequent or continuous replication.

Expect a few weeks of engineering spread across a quarter. Design the work together with A.8.13 backup and A.8.14 redundant infrastructure, since one set of decisions on copies, zones and failover serves all three controls.

An undersized secondary environment, or one missing production's security controls, turns failover into a second incident. Size it for the signed RTO, and give it the same logging, access control and patching as the primary.

## How do you write DR runbooks that still work when your environment is down?

Write runbooks that someone capable but not the author could follow: restoration order, concrete steps, who decides what, and escalation contacts. Keep a copy that an attacker who owns your main environment cannot reach, printed or in a separate cloud store. Recovery should never depend on the environment that failed.

A usable runbook holds four things:

- **Restoration order**, set by dependencies, so the team does not start with the wrong service.
- **Concrete steps**: the commands, console paths and parameters, not "restore the database".
- **Decision roles**: who declares the disaster, who approves failover, and a named deputy for each, so the plan survives a holiday or a resignation.
- **Escalation contacts** for cloud support, key vendors and leadership, reachable without your own systems.

Test the runbook by handing it to a capable engineer who did not write it. Every question they ask is a missing step.

Write for the worst day, not the best. Assume the on-call engineer is tired, the usual chat tool is unavailable and the author is on a flight. Short numbered steps beat prose, and each should say what "done" looks like so the next person knows when to move on.

A password manager hosted in the failed environment puts the keys inside the locked house. So do break-glass details kept in a wiki on the encrypted server. Refresh the out-of-band copy whenever the architecture changes, and check it at every test.

## How do you automate backup verification and restore drills in CI/CD?

Treat restore testing as a pipeline job. On a schedule, build an environment from backups, check it, time it against the RTO and record the result automatically. Pair that with alerts on backup failures and integrity anomalies, so monitoring history becomes the evidence trail instead of a manually compiled log.

The [NCSC cyber resilience guidance for organisations](https://www.ncsc.gov.uk/blog-post/why-resilience-matters-as-much-as-defence) makes the underlying point. The organisations that handle incidents best have rehearsed them, and business impact assessments show what must keep running. Automation turns that rehearsal into routine.

Four automated pieces build the evidence trail:

- **Scheduled restore jobs.** Where infrastructure is code, each run leaves a timed record, and the annual scramble becomes a routine job with a dashboard.
- **Backup monitoring.** Alerts on failed jobs and integrity anomalies, each routed to a named owner.
- **Live dependency data.** Hold critical services, dependencies and targets as structured data tied to the asset inventory. "Does anything now breach its RTO?" becomes a query, and an architecture change raises a review flag.
- **Break-glass alerts.** Wire emergency-access use to alerts and automatic review, so the route stays both available and provably controlled.

Start small. One weekly job is enough to begin. It restores the main database into a throwaway environment, runs a few integrity queries and posts the time taken. Extend it service by service in the order the BIA ranks them.

Make failure loud. A failed restore job should open a ticket, and that ticket becomes the corrective-action record an auditor later samples.

A failover that has only ever been discussed in a tabletop is the one that fails.

A failed drill is not a failed programme. A restore that misses its target and produces three improvement actions is a good result, because it shows the loop working. Close those actions and keep the history.

| Method | What it catches | Cadence | Evidence left |
| --- | --- | --- | --- |
| Tabletop exercise | Unclear roles, missing contacts, untested assumptions | Rotated with live tests | Minutes and action list |
| Scheduled restore job | Corrupt or incomplete backups, restore times above the RTO | On a pipeline schedule | Job logs and timings |
| Live failover drill | Undersized secondary, missing controls, access gaps | After significant architecture change | Drill record and closed actions |
| Backup monitoring alerts | Failed jobs, integrity anomalies | Continuous | Alert history |

## What will an auditor ask about ISO 27001:2022 Annex A 5.30 ICT readiness for business continuity?

The auditor picks one critical service and traces the thread: BIA entry, signed target, the technical arrangement behind it, and test evidence proving it works. Expect questions on who signed the targets, your last real restore, how recovery starts without your identity provider, and whether vendor SLAs fit your RTO.

Expect these questions, each with the evidence that answers it:

- "Which services matter most, with what targets, and who signed them?" The **BIA output** and signed targets.
- "When did you last restore from backup, and did you hit the target time?" **Test records** with timings against the RTO.
- "Your identity provider is down: how does recovery start?" **Break-glass configuration** and its access audit trail.
- "Does this critical SaaS vendor's SLA fit your target?" **Vendor SLA review notes**.
- "What changed after the last test or real incident?" **Follow-up actions** with closure status.

Beyond those records, bring the runbooks and DR plan with proof of the out-of-band copy. Add the architecture or configuration material that shows the claimed redundancy and the immutable backup set-up. For ISO 27001 2022 Annex A 5.30 ICT readiness for business continuity, two pages of BIA reasoning carry more weight than a polished plan with nothing behind it.

The auditor then compares the RTO on paper with the vendor SLA or the restore timing, and probes any mismatch. In certification-body practice, gaps grade like this:

- **Major:** no BIA-derived targets at all, or a recovery capability that has never been tested in any form.
- **Minor:** a lapsed test cycle, targets without documented sign-off, or open actions from the last exercise.
- **Pattern:** several minors together add up to a major.

Prepare one service end to end before the audit. Pick the most critical, and walk the thread yourself from BIA entry to the latest restore timing. Any gap you find in that rehearsal is one the auditor would otherwise find for you.

With the restore pipeline in place, most of this evidence is a by-product, so the audit becomes a walkthrough of work already done. The same record answers the next due-diligence questionnaire.

## Frequently asked questions

### Is A.5.30 new in ISO 27001:2022, and does that change how auditors treat it?

Yes. The 2022 revision added it as a distinct control, so auditors give it deliberate attention instead of accepting a general backup policy as cover. If you certified under the 2013 edition, check that signed recovery targets and recorded restore tests exist before your transition audit.

### How often does A.5.30 require a recovery test, and must it be a live restore?

At least annually, and again after a significant architecture change. You can alternate formats, with a tabletop one cycle and a live restore the next. A live restore must appear somewhere in the rotation, with the time measured against the RTO.

### How long does A.5.30 take to implement, and what has to come first?

Treat the first live restore as part of the build, not a follow-up. The build is not finished until a restore has been timed against its target. Begin with your asset inventory (A.5.9), because the BIA cannot rank services you have not listed. If the inventory is thin, fix that first.

### Can one restore test count as evidence for both A.5.30 and A.8.13?

Yes, if the record covers what each control looks for. A.8.13 wants proof that backups are taken and can be restored. A.5.30 wants a critical service restored against its signed RTO. Record the target, the time taken and the result, and one exercise serves both.