ISO 27001 Business Continuity Policy: A.5.29, A.5.30, and Why It Isn’t ISO 22301 (Free Policy Skeleton)

Somewhere between drafting an information security policy and staring down an ISO 27001 Stage 1 audit, most compliance owners hit the same wall: what, exactly, does “business continuity” mean under this standard? Annex A doesn’t have one control called “Business Continuity Policy” — the requirement is split across a handful of specific controls, and conflating it with the much broader discipline of enterprise business continuity management (the job of a different ISO standard entirely) is one of the most common gaps a reviewer flags in a policy draft.

This guide breaks down exactly which Annex A controls an ISO 27001 business continuity policy needs to satisfy, draws a hard line between what this standard actually requires and what ISO 22301 covers instead, and walks through the three building blocks — a business impact analysis, defined recovery objectives, and a plan that’s actually been tested — that turn a policy document into evidence an auditor will accept. If your organisation already has NIS2 Article 21(2)(c) business continuity work in place, we’ll also cover what transfers directly and what doesn’t. A free, condensed policy skeleton is included below.

The Annex A Controls Behind an ISO 27001 Business Continuity Policy

ISO/IEC 27001:2022’s Annex A doesn’t have a single “Business Continuity Policy” control. The requirement is split mainly across two organizational controls and two technological controls:

Control	Theme	What it actually requires
A.5.29 — Information security during disruption	Organizational	Maintain information security — confidentiality, integrity, and availability of in-scope data — at a predetermined, appropriate level throughout a disruption, not just once it ends [2]
A.5.30 — ICT readiness for business continuity	Organizational	Plan, implement, maintain, and test ICT continuity capability so systems and data stay available, based on business continuity objectives and ICT continuity requirements [3]
A.8.13 — Information backup	Technological	Maintain and regularly test backup copies of information, software, and systems in line with an agreed backup policy [4]
A.8.14 — Redundancy of information processing facilities	Technological	Build sufficient redundancy into information processing facilities to meet defined availability requirements [5]

A.5.29 and A.5.30 sit closest together and are the two controls most reviewers mean when they say “business continuity policy” — 5.29 is about preserving security properties under stress, 5.30 is about the technical restoration capability itself. [2][3] A.8.13 and A.8.14 are the backup and redundancy mechanics that make 5.30’s promises credible: a continuity plan that promises systems will be restored within four hours is not evidence of anything if the backups it depends on have never been test-restored. [4][5]

Whichever of these controls apply to your scope, they need a documented justification in your Statement of Applicability — “not applicable” is a defensible answer for a control, but only when the SoA explains why.

ISO 27001 vs. ISO 22301: Why “Business Continuity” Means Something Narrower Here

This is the confusion point that trips up more people than the control numbers themselves. ISO 27001 is an information security management system standard — its continuity controls exist to protect the confidentiality, integrity, and availability of information specifically, during a disruption. [2][3] They do not require you to plan for continuity of your entire business: payroll running, premises reopening, supplier contracts holding, a phone line staffed for customers. That broader scope belongs to ISO 22301, a separate, standalone standard for business continuity management systems (BCMS), with its own certification track. [6]

ISO 22301 is built around sustaining an organisation’s core business functions through any disruption; ISO 27001 is built around safeguarding information against threats, which includes disruption but stops at the boundary of the ISMS scope. [6] In practice, most organisations pursuing ISO 27001 alone can satisfy A.5.29 and A.5.30 without ever touching ISO 22301, because their scope is information and the systems that hold it — not the whole enterprise. Where it gets genuinely confusing is that a real disruption doesn’t respect this boundary: a flooded data centre is simultaneously an ISO 27001 concern (is customer data still confidential and recoverable?) and, for everything outside the ISMS scope, a problem ISO 27001 was never designed to cover. If you eventually need both standards, the ISO 27001 continuity work you build first is not wasted effort — it becomes a component of a future BCMS, not a competing document set.

For the full clause-by-clause picture of what an ISO 27001 ISMS covers beyond business continuity, see our ISO 27001 compliance guide.

The Building Blocks: BIA, RTO/RPO, and a Tested Recovery Plan

Whatever you call the resulting document, an ISO 27001-credible business continuity capability rests on three building blocks, built in this order.

1. Business impact analysis (BIA). Before you can define a recovery objective, you need to know what happens if a system or process becomes unavailable — for how long, and at what cost. A.5.30 explicitly expects a BIA to be conducted to identify how disruptions affect operations, before recovery objectives are set. [3]

2. Recovery time and recovery point objectives. These are the two numbers A.5.30 actually asks you to define, not a general statement of intent. [3]

Metric	Answers the question	Drives
RTO — Recovery Time Objective	How long can this system be down before the impact is unacceptable?	Failover design, recovery staffing, A.5.30 planning [3]
RPO — Recovery Point Objective	How much data can we afford to lose, measured in time?	Backup frequency under A.8.13, replication design [3][4]

3. A tested recovery plan. A.5.30 requires ICT readiness to be “planned, implemented, maintained and tested” — not just documented. [3] An untested plan is a hypothesis. The single most common finding in a continuity policy review is a plan that has never been exercised against its own stated RTOs, which is also why continuity plans are typically validated through the same tabletop or functional exercises used for incident response, rather than reviewed in isolation on paper.

How Your NIS2 Article 21(2)(c) Business Continuity Work Transfers

If your organisation is also NIS2-scoped, you likely already have business continuity work built for Article 21(2)(c), which requires measures covering “business continuity, such as backup management and disaster recovery, and crisis management.” [1] The good news: most of it transfers directly, because NIS2 and ISO 27001 share roughly 70–80% foundational overlap at the control level — see our full NIS2 vs. ISO 27001 comparison for the complete control-by-control mapping. Our NIS2 Article 21(2)(c) business continuity guide covers the BIA, RTO/RPO/MTPD framework, and backup discipline most NIS2 programmes already build — the same underlying work ISO 27001’s A.5.29, A.5.30, A.8.13, and A.8.14 ask for.

What you already have	What changes for ISO 27001
Your BIA, RTOs, and RPOs	Reusable directly — ISO 27001 doesn’t ask for different numbers, just a documented link from each figure to the Annex A control and Statement of Applicability entry it supports
Your backup regimen (e.g. 3-2-1-1-0)	Reusable directly if you already test restores — A.8.13 and A.8.14 ask for the same discipline under a different label [4][5]
Your crisis management procedures	Mostly reusable, but fold them into your A.5.29/A.5.30 documentation — ISO 27001 has no standalone “crisis management” control the way NIS2 Article 21(2)(c) names one [1][2][3]

The gap most NIS2-compliant organisations underestimate isn’t the technical content — it’s the paperwork format. NIS2 doesn’t require a Statement of Applicability; ISO 27001 does, and every continuity control you claim needs to trace to it. That mapping exercise, not new continuity planning, is usually the actual remaining work. For the broader case for pursuing certification on top of existing NIS2 compliance, see our guide to ISO 27001 for NIS2-compliant organisations.

Free Mini Business Continuity Policy Skeleton

The outline below is a genuinely usable starting point — short enough to adapt in an afternoon, not a teaser withheld until purchase. It covers the minimum a reviewer expects to see: a purpose, a scope, policy statements tied to specific controls, named ownership, and a review cadence.

Purpose
To ensure that the organisation maintains an appropriate level of information security during any disruption to its information systems, and that ICT services supporting critical business activities can be recovered within agreed timeframes.

Scope
This policy applies to all information systems, applications, and ICT infrastructure within the ISMS scope, and to all employees, contractors, and third parties responsible for operating or recovering them.

Policy Statements

• Information security requirements — confidentiality, integrity, and availability of in-scope data — shall be maintained at a defined minimum level throughout any disruption, not only once normal operations resume (A.5.29).
• ICT continuity requirements and objectives shall be defined for all critical systems, and a continuity plan shall be documented, implemented, and kept current (A.5.30).
• Recovery time objectives (RTO) and recovery point objectives (RPO) shall be defined for every critical system identified through a business impact analysis, and reviewed at least annually (A.5.30).
• Backup copies of critical information, software, and systems shall be taken on a defined schedule, stored securely, and test-restored at planned intervals (A.8.13).
• Redundancy shall be built into information processing facilities supporting critical systems, proportionate to their defined availability requirements (A.8.14).
• The continuity plan shall be tested at least annually, and any findings shall be tracked to closure before the next test cycle.

Roles & Responsibilities

Role	Responsibility
ISMS Manager / CISO	Owns the policy; approves RTOs, RPOs, and the continuity plan
IT / Infrastructure Lead	Implements backup, redundancy, and recovery procedures
Business Process Owners	Provide input to the business impact analysis for their function
Internal Audit / Compliance	Verifies testing occurred and findings were closed

Review Cadence
This policy shall be reviewed at least annually, and after any significant disruption, system change, or audit finding.

FAQ

Does ISO 27001 require a separate, standalone business continuity policy?
Not necessarily as one named document. What’s mandatory is that A.5.29 and A.5.30 — and, where applicable, A.8.13 and A.8.14 — are addressed somewhere in your ISMS documentation, with a clear link to your Statement of Applicability. [2][3] Many organisations write it as a single policy because it’s easier to review and test as a unit.

Do I need ISO 22301 if I’m already pursuing or holding ISO 27001?
Only if you need assurance over enterprise-wide business continuity — premises, staffing, suppliers, and processes outside the ISMS scope. ISO 27001’s continuity controls cover information security specifically. [2][3][6] Many organisations operate for years on ISO 27001 alone without ISO 22301.

What’s the actual difference between RTO and RPO?
RTO is a time budget for downtime; RPO is a time budget for data loss. A system with a 4-hour RTO and a 1-hour RPO must be restored within 4 hours, with no more than 1 hour of data missing from the point of failure. [3]

Can I reuse my NIS2 Article 21(2)(c) business continuity plan for ISO 27001?
Largely yes — the underlying BIA, RTOs/RPOs, and backup regimen transfer directly, since both frameworks ask for similar continuity discipline. [1][3] What ISO 27001 adds is the requirement to trace each element back to a specific Annex A control in your Statement of Applicability.

Which controls will an ISO 27001 auditor actually check for business continuity?
Expect an auditor to test A.5.29 and A.5.30 first — the policy and the plan — then sample A.8.13 (backup test evidence) and A.8.14 (redundancy design) if they’re marked applicable in your Statement of Applicability. [2][3][4][5] A plan that has never been exercised is the single most common finding.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• [1] NIS 2 Directive, Article 21 — Cybersecurity risk-management measures, nis-2-directive.com (verbatim mirror of Directive (EU) 2022/2555)
• [2] ISO 27001:2022 Annex A Control 5.29 Explained — Information Security During Disruption, ISMS.online
• [3] ISO 27001:2022 Annex A Control 5.30 Explained — ICT Readiness for Business Continuity, ISMS.online
• [4] ISO 27001:2022 Annex A Control 8.13 Explained — Information Backup, ISMS.online
• [5] ISO 27001:2022 Annex A Control 8.14 Explained — Redundancy of Information Processing Facilities, ISMS.online
• [6] ISO 22301 vs ISO 27001, ISMS.online