ISO/IEC 27001:2022 and business continuity: the complete guide

The Annex A controls that directly involve DR and continuity: A.5.30, A.8.13, A.8.14. What auditors actually ask for.

4 min read

TL;DR

The ISO/IEC 27001:2022 revision reorganised the Annex A controls and introduced A.5.30 — ICT readiness for business continuity, the control that explicitly demands technical ICT recovery capability. Together with A.8.13 — Information backup and A.8.14 — Redundancy of information processing facilities, it defines DR obligations for certified organisations. This guide covers what these three controls demand, how they translate into concrete evidence and how to reach the recertification audit calmly.

What changed between ISO 27001:2013 and 2022

The 2022 version brings three DR-relevant changes:

  • Reduced Annex A: from 114 to 93 controls, reorganised into 4 themes (organisational, people, physical, technological).
  • 11 new controls, including A.5.30 (ICT readiness for business continuity) and A.8.16 (monitoring activities).
  • Alignment with ISO 22301 on continuity terminology.

Certified organisations had 3 years from publication (October 2022) to migrate. From October 2025 the old 2013 standard is no longer valid. By 2026, anyone still on 2013 is effectively decertified.

The three DR-relevant controls

A.5.30 — ICT readiness for business continuity

The new control that tripped half the certified organisations. It requires:

  • defining measurable continuity objectives (RTO, RPO);
  • planning and implementing the technical capabilities to meet them;
  • regularly exercising and verifying those capabilities.

In concrete terms: a written DR plan + a drill calendar + drill records. Without the records the auditor logs an NC (non-conformance).

A.8.13 — Information backup

The classic backup control, with three specific demands:

  • documented backup strategy, aligned with the continuity policy;
  • backups stored to resist the same events that could affect the source (off-site, encrypted);
  • periodic restore verification from backups.

The last one fails most audits: having backups is not enough — restore tests must be evidenced.

A.8.14 — Redundancy of information processing facilities

Critical ICT facilities must have redundancy sufficient to meet availability objectives. Applies to network, power, cooling and — for cloud — to picking a provider with documented SLAs.

What an auditor actually looks for

Serious auditors do not read policies in stage 1. They look for 5 pieces of evidence:

  1. DR plan signed by management, dated within the last 12 months.
  2. Latest drill report with measured times and corrective actions open/closed.
  3. Backup policy declaring frequency, retention, off-site, verification.
  4. Restore test result (file extracted, hash verified, system log).
  5. Mapping of ICT controls to the business process BIA.

If these 5 are in order, the continuity-cluster audit closes in half a day.

BIA as the foundation

All ISO 27001 DR controls start from a Business Impact Analysis. Without a solid BIA you cannot defend declared RTO and RPO.

A lightweight but sufficient BIA for 27001 includes:

  • list of critical business processes (10-20 max for SMBs);
  • for each: maximum tolerable period of disruption (MTPD), RTO, RPO;
  • ICT dependencies (which systems, which data);
  • impact in euros per day and at peak;
  • management approval.

Three days of work, two workshops with process owners.

Mistakes that fail the audit

The five most frequent mistakes in the continuity cluster:

  • generic DR plan copied from a template without customisation;
  • drills never documented, or documented without measured times;
  • unverified backups, or verified with shallow checks ("the job ran");
  • incomplete runbooks (missing credentials, contacts, restart order);
  • missing BIA → DR mapping: controls adopted but not traceable to a critical process.

How to be ready in 6 months

An operational plan for organisations starting from near-zero:

  • months 1-2: BIA, draft continuity policy, pick DR solution.
  • months 3-4: DR deployment, runbooks, first internal drill.
  • month 5: official documented drill, training operations staff.
  • month 6: pre-audit with external consultant, gap fix, certification audit.

Six months is the realistic minimum. Below 4 months you are cutting corners somewhere.

How Sefthy helps cover these controls

Sefthy is built explicitly for organisations targeting 27001:

  • DR plan template generated by the Console at deploy time;
  • pre-scheduled quarterly drills with exportable reports;
  • DeepVerify for periodic backup integrity verification;
  • automatic restore reports;
  • provider certifications: ISO 27001:2022, 27017, 27018, 9001 — the provider itself covers A.8.14 on Italian sovereign cloud.

In short: the continuity cluster of your 27001 is built by your DR vendor. Pick a certified one.

FAQ

How heavy is the continuity cluster in the overall audit?

In 2025-2026 audits we see 5-8 hours out of 25-30 dedicated to the continuity cluster. It is the single cluster with the most non-conformances.

Can I get ISO 27001 without an external DR vendor?

Yes, if you run redundant infrastructure yourselves. It is more expensive but legitimate. ISO 27001 is vendor-agnostic.

Does A.5.30 still apply if I have a physical secondary site?

Yes. A secondary site does not substitute for the required evidence: DR plan, drills, runbooks.

Is the DR provider's certificate sufficient evidence for A.8.14?

It is significant evidence but not sufficient: documented due diligence on vendor selection, aligned with A.5.19-5.23, is also needed.


Want to see how Sefthy maps to ISO 27001 controls? Read Annex A.5.30 ICT readiness or ISO 27001 vs 27017 vs 27018.

Want to see Sefthy in action?

Same IP, same subnet, RTO in minutes. Try it free for 7 days or talk to one of our specialists.