There is a requirement in ISO 22301 for a Business Continuity Plan. It’s slightly indirect, but it’s needed to pass. ISO 27001 adds another layer: it requires that information stays secure, available, and recoverable during a disruption. It does not require a full organisation‑wide BCP — only the parts relevant to information security — but in practice, those areas overlap strongly with wider continuity.
This article has been written in a way that also signposts a number of related pieces already published on the Inoni blog. ISO 27001 touches many different aspects of continuity, and rather than repeat all that detail here, this guide functions as a kind of “mini‑wiki” — linking out to deeper explanations where they genuinely add context. Readers can dip into the specific areas they care about without the core article becoming unnecessarily long.
Many organisations will grab a template or generate a BCP with AI if they don’t have one. Useful as a starting point, but it avoids the more important question: why does ISO 27001 want a BCP at all? And why does a template often fall short in audit?
ISO 27001 certification carries value internally and externally. If the effort is being made, it’s worth integrating continuity properly so the BCP becomes something practical and informative — a tool that shows how the business behaves under pressure, not just a compliance box ticked.
Here’s where BCP touches ISO 27001, and how to address each area effectively.
1. Information Security During Disruption (Annex A.5.29)
ISO 27001 expects you to show how you will maintain or restore information security while disruption is still ongoing, not only afterwards. That includes confidentiality, integrity and availability during the messy middle of an incident.
It also expects you to consider how normal ISMS activities will continue when things are not running normally.
Our recommendation
Start with minimum viable outcomes, not systems. Identify what absolutely must continue, then map what information must be protected to support those outcomes.
This aligns well with the risk‑based continuity approach we describe in our post on survival‑focused planning.
It avoids bloated plans that treat everything as equal and keeps your BCP meaningful under pressure.
2. ICT Readiness for Business Continuity (Annex A.5.30)
This control requires ICT resources to be planned, implemented, maintained and tested based on business continuity objectives. That includes recovery timeframes, data loss tolerances, and dependencies between systems and processes.
It must be grounded in a BIA, not guesswork. Recovery must be testable, not assumed.
Our recommendation
Make the “golden thread” visible:
- What the business can tolerate (MAO/MTPD)
- What ICT must achieve (RTO/RPO)
- How this has been tested
We explain these parameters in plain English in our MAO/RTO/RPO guide.
When ICT recovery objectives reflect business reality — and you can prove they’ve been exercised — Annex A.5.30 becomes straightforward.
ISO 27001 formally includes only two continuity‑related controls (A.5.29 and A.5.30), but in practice these depend on a wider set of supporting capabilities. The following sections cover those practical areas — the things organisations typically need to get right behind the scenes in order to satisfy the intent of the standard.
3. Scenario Playbooks Beat Monolithic Plans
Large, single‑document BCPs often fail under pressure. They are slow to navigate, assumptions conflict, and responsibilities blur.
Scenario playbooks, by contrast, focus on high‑impact events and give teams short, clear decision pathways. This reflects how crises actually unfold across teams, suppliers and systems.
Our recommendation
Keep the main BCP lean and readable. Attach one‑page scenario runbooks for events like cyber incidents, cloud outages, loss of building or major supplier failure.
This approach is easier for staff to use and far more convincing for auditors.
4. Get the Handoffs Right: Incident → Crisis → Continuity
Many organisations blur the lines between incident response (detect, contain, escalate) and business continuity (restore essential operations).
ISO 27001 doesn’t dictate a specific model, but it expects the relationship between these layers to be understood and functional. Our post on the distinctions between incident response and continuity shows how gaps emerge when they aren’t.
Our recommendation
Define the handoff clearly:
- What triggers continuity activation?
- Who declares it?
- What is the first agenda?
- What decisions must be made in the first 30 minutes?
Whether you combine incident response, crisis management and continuity into one framework or separate them, clarity beats structure every time.
5. Assume Key Tools May Fail (Especially in Cyber Incidents)
ISO 27001 expects you to maintain security even when core tools are offline. Many organisations forget that email, Teams, SharePoint or cloud consoles may be unavailable in a cyber event. Our article on pen‑and‑paper fallback explains why minimal offline capability is now essential.
Our recommendation
Include a small, realistic offline continuity kit:
- Printed contacts
- Escalation paths
- Manual comms methods
- Minimal paper workarounds
The goal isn’t to operate fully on paper — it’s to maintain enough coordination to recover.
6. Cloud Outage Planning
Cloud service disruptions are rare but impactful. ISO 27001 expects continuity planning where ICT is critical to operations. Our cloud outage runbook guidance covers resilience, comms, and recovery foundations.
Our recommendation
Write a short, action‑oriented cloud outage runbook:
- How you confirm it’s the provider
- Who handles customer comms
- Which services get priority
- How you track status and decisions
This is one of the clearest signals to an auditor that ICT readiness is real and tested.
7. A Better BIA = A Better BCP
A weak BIA produces weak recovery objectives. Departments assess themselves in isolation, deadlines inflate, and impact tolerances get distorted. Our value‑stream BIA post explains why traditional BIAs often misfire.
Our recommendation
Spend more time on the quality of the BIA than the quantity of documentation.
If your impacts, tolerances and stakeholder expectations are transparent and defensible, the plan writes itself and ISO 27001 conversations become easy.
8. Ownership and Governance
BCP fails quietly without owners. ISO 27001 expects clarity on roles, responsibilities, and decision‑making.
Our “Who should own your BCP?” article breaks down senior sponsorship and PM roles.
Our recommendation
Keep the BCP policy short and governance‑focused (scope, expectations, review cycle), and keep the operational BCP practical.
Separating these two documents makes maintenance easier and avoids policy bloat.
9. Testing and Evidence
ISO 27001 rewards organisations that test little and often, rather than once a year in a marathon tabletop.
Most crises start virtually now, so exercising in the same environment matters. Our virtual crisis simulation blog covers this.
Our recommendation
Short, scenario‑based, discussion‑heavy exercises work best.
Capture lessons, update your runbooks, and make improvements visible — that’s what auditors look for.
A simple structure that satisfies ISO 27001 without turning into bureaucracy
A pragmatic ISO‑friendly structure:
- Short BCP Policy (purpose, scope, roles, governance)
- Lean Operational BCP (activation, governance, comms, minimum viable outcomes)
- Scenario Runbooks (cyber, cloud outage, building loss, supplier failure)
- ICT Readiness Pack (RTO/RPO register, DR test evidence, architecture notes)
- Exercise Log & Improvement Tracker
This keeps continuity manageable, useful and credible — without accidentally building an ISO 22301‑level programme.
Business continuity and ISO 27001 don’t have to be complicated, but they do benefit from structure, clarity and real‑world testing. If support is needed to develop the BCP, refine the BIA, or run scenario exercises, our consultants help organisations build practical, evidence‑based continuity arrangements that stand up to audit and work when it matters.