Business continuity planning is one of the areas where organisations implementing ISO 27001 frequently ask the same question: is a full Business Continuity Plan required to achieve certification? The honest answer is that the standard requires specific, defined things — and a comprehensive BCP is not always one of them. What it does require is proportionate and often misunderstood.
ISO 27001 addresses business continuity through two Annex A controls: Control 5.29 (Information security during disruption) and Control 5.30 (ICT readiness for business continuity). Understanding what each requires — and where ISO 27001 stops and a dedicated BCM standard begins — is essential for building controls that are genuinely effective rather than just sufficient to pass an audit.
The Relationship Between ISO 27001 and Business Continuity
ISO 27001 is an information security standard. It is not a business continuity standard. The relevant business continuity standard is ISO 22301, which is dedicated to business continuity management systems and is considerably more comprehensive in its BCM requirements.
What ISO 27001 requires is that information security is maintained during disruptions — that the confidentiality, integrity, and availability of information is protected even when normal operations are disrupted. This is a narrower requirement than full business continuity planning, though the two are deeply related: you cannot maintain information security during a disruption without having thought through how your critical information systems and processes will behave.
Organisations that already have a BCP will find that it addresses much of what ISO 27001 requires. Organisations without a BCP will find that ISO 27001 requires them to think about continuity in a more structured way than perhaps they have before — but the standard does not require a 200-page BCP document.
Control 5.29: Information Security During Disruption
Control 5.29 requires that the organisation plans how it will maintain information security at an appropriate level during disruption. This means:
Identifying what matters. Before you can plan to protect information security during disruption, you need to know what systems and processes are critical from an information security perspective. Which systems hold sensitive data? Which processes must continue for regulatory or contractual reasons? Which systems, if unavailable, would prevent the business from meeting its legal obligations?
Planning the response. For the critical systems and processes identified, what are the continuity arrangements? This might include backup systems, failover mechanisms, manual workarounds, or alternative processing arrangements. The key question is: how will information security be maintained if your primary systems are unavailable?
Maintaining access controls and protections during disruption. Disruptions — including major incidents like ransomware attacks, natural disasters, or prolonged system outages — can create pressure to bypass security controls in the name of speed. The plan should explicitly address how access controls, data protection, and security monitoring will be maintained even when the organisation is operating in an emergency mode.
Testing the arrangements. A plan that has never been tested is a plan that may not work. Control 5.29 expects that continuity arrangements are verified — not just documented.
Control 5.30: ICT Readiness for Business Continuity
Control 5.30 is a more specific and technically focused requirement. It addresses the readiness of the organisation’s ICT (Information and Communication Technology) infrastructure to support business continuity objectives.
The control requires that ICT readiness be planned, implemented, maintained, and tested based on business continuity objectives and ICT continuity requirements. In practical terms this means:
Recovery time objectives (RTOs). For critical systems, how quickly do they need to be restored following a disruption? These should be defined based on business requirements — the finance system might need to be restored within four hours; an internal wiki might tolerate a 48-hour outage.
Recovery point objectives (RPOs). For critical systems, what is the maximum acceptable data loss? A system backed up weekly has an RPO of up to seven days — any data created since the last backup would be lost in the event of a system failure. An RPO of one hour requires much more frequent backup or replication.
ICT continuity arrangements. What technical mechanisms are in place to meet the defined RTOs and RPOs? This might include backup infrastructure, cloud failover, database replication, or documented recovery procedures.
Testing. RTOs and RPOs are objectives, not guarantees. They need to be tested to confirm that recovery can actually be achieved within the defined timeframes. A backup that has not been tested is not a reliable backup.
ISO 27001 Business Continuity: Controls 5.29 and 5.30
Two distinct but related controls — one focuses on security during disruption, one on ICT recovery capability
What You Actually Need to Document
ISO 27001 does not prescribe the format or extent of business continuity documentation. What it does require is evidence that you have:
- Identified which systems and processes are critical from an information security perspective
- Defined how information security will be maintained during disruption
- Established RTOs and RPOs for critical ICT systems
- Implemented technical arrangements to meet those objectives
- Tested that those arrangements work
For many smaller organisations, this can be addressed within an existing document framework — the risk assessment, risk treatment plan, and a relatively compact ICT continuity procedure — rather than requiring a full standalone BCP.
For larger organisations, or those with complex IT environments, regulatory requirements, or significant customer obligations, more comprehensive documentation and testing programmes are appropriate.
ISO 27001 Business Continuity: What You Need vs What's Good Practice
The standard requires specific elements — not necessarily a full Business Continuity Plan
The BCP and ISO 27001: A Practical Framework
Where an organisation does have or needs a BCP, ISO 27001 expects information security to be embedded within it. The BCP should:
Include information security in the impact assessment. When assessing the impact of disruption scenarios, information security consequences should be explicitly considered — data loss, regulatory exposure, breach notification obligations, and the risk of security controls being bypassed during recovery.
Define security responsibilities during a disruption. Who is responsible for information security during an incident or disaster? How are access permissions managed when key personnel are unavailable? How is the integrity of recovered data verified?
Address communication security. During a disruption, organisations often use alternative communication channels — personal email, consumer messaging apps, verbal instructions. The plan should address how sensitive information is protected during these periods.
Include information security in testing. BCP exercises should test whether information security controls remain effective during simulated disruptions — not just whether operations can be restored.
Key Scenarios to Plan For
ISO 27001 does not specify which disruption scenarios to plan for. Your risk assessment should drive scenario selection based on the threats most relevant to your organisation. Common scenarios that intersect information security and business continuity include:
Ransomware and system encryption. Ransomware represents both a security incident and a continuity event. Your response plan should address containment, recovery from backup, and how to restore operations without propagating the infection.
Cloud service provider outage. Organisations that rely heavily on cloud providers for critical processing may find that their continuity depends on the availability of services they do not control. Plans should identify alternative arrangements or acceptable downtime thresholds.
Key personnel unavailability. If the ISMS lead or IT manager is unavailable during a security incident, who acts? Knowledge dependencies and single points of failure in security operations should be identified and addressed.
Facility unavailability. If your primary office or data centre is inaccessible, can staff work securely from alternative locations? What are the information security implications of emergency remote working arrangements?
What Auditors Look For
When auditors review Controls 5.29 and 5.30, they are assessing whether the organisation has:
Defined criticality. Is there a documented view of which systems and processes are critical, and why? Has information security been considered in that assessment?
Documented plans. Are there documented continuity and recovery arrangements for critical ICT systems? Do they address information security specifically?
Defined RTOs and RPOs. Has the organisation set recovery objectives and are they based on actual business requirements?
Tested arrangements. Is there evidence that backup and recovery arrangements have been tested — not just implemented? Test records are a common request.
Information security in the plan. Does the plan address how security controls will be maintained during disruption? Or does it focus solely on operational recovery without considering the security implications?
Get Started
Free Templates
Free
The 14 mandatory documents. The starting point for any ISO 27001 project.
A great way to get started without the commitment.
Templates
Full Toolkit
£85
130+ documents; policies, risk register, audit pack, staff communications and everything else you need to build a working ISMS.
Buy now →Do-It-Yourself
DIY Course
£285
The Do-It-Yourself course introduces the standard, its requirements, and then shows you how to implement it, stage by stage.
Includes the full toolkit & email consultancy.
More support?
Coaching
~£3,500
I can guide you through the standard and help you tailor it to your business through a series of coaching workshops.
Includes the full toolkit, personal consultancy, and first-pass guarantee.
Common Mistakes
Confusing having a backup with having a continuity plan. Regular backups are necessary but not sufficient. A continuity plan addresses what happens when a disruption occurs — how the organisation responds, how quickly it recovers, and how security is maintained throughout. Backups are one input into that plan.
Setting RTOs and RPOs without testing them. An RTO of four hours for the main ERP system is only meaningful if you have verified that restoration can actually be achieved in four hours. Untested RTOs are aspirations, not commitments.
Treating BCP as an IT-only exercise. While Control 5.30 is ICT-focused, information security during disruption (Control 5.29) involves the whole organisation. HR, finance, operations, and management all have roles in maintaining security when normal operations are disrupted.
Planning for recovery but not for the disruption itself. The continuity plan needs to address both the acute phase — immediate response and containment — and the recovery phase. Organisations that focus only on recovery procedures and neglect the incident response and containment phase often find that the recovery is slower and less effective than planned.
Never testing the plan. A continuity plan that has never been exercised is not a continuity plan — it is a document. Even a desktop walkthrough exercise reveals gaps that documentation alone cannot surface.
FAQs
Does ISO 27001 certification require a full Business Continuity Plan?
No. ISO 27001 requires evidence that you have addressed Controls 5.29 and 5.30 — information security during disruption and ICT readiness for business continuity. This can be achieved with a focused ICT continuity procedure and tested backup/recovery arrangements, without a comprehensive BCP. However, for many organisations — particularly those with regulatory obligations or significant customer commitments — a full BCP is appropriate and good practice regardless of ISO 27001 requirements.
What is the difference between ISO 27001 and ISO 22301 for business continuity?
ISO 22301 is a dedicated Business Continuity Management System (BCMS) standard. It is considerably more comprehensive than ISO 27001’s BCM-related requirements, covering business impact analysis, continuity strategy, plan development, exercising, and programme management. ISO 27001 focuses specifically on maintaining information security during disruption — a subset of what ISO 22301 addresses. Organisations with mature continuity requirements may seek certification under both standards.
How often should we test our continuity arrangements?
The standard does not specify a frequency. Annual testing is a reasonable minimum for most organisations. High-risk environments or organisations with frequent changes to their IT environment should test more often. At minimum, backup restoration should be tested regularly — many organisations test monthly for critical systems — and a broader recovery exercise should be conducted at least annually.
Our backups are in the cloud — does that satisfy Control 5.30?
Cloud-based backup is a valid and commonly used approach. The key requirements are that backups are tested regularly to confirm they can be restored within your defined RPO and RTO, that the backup configuration is reviewed to ensure it covers all critical data, and that the arrangements remain fit for purpose as your environment changes. The specific technology is less important than the evidence that it works.
What should be in an ICT continuity procedure?
At minimum: the critical systems covered, defined RTOs and RPOs for each, the backup and recovery arrangements in place, the individuals responsible for recovery activities, escalation procedures, and a testing schedule. For more complex environments, detailed recovery runbooks for critical systems may also be appropriate.
