Business continuity is one of the most misunderstood areas of ISO 27001 implementation. Some organisations interpret it as requiring a fully-fledged ISO 22301-style BCP programme. Others dismiss it as low priority and produce a token document that fails audit. The reality sits in the middle: ISO 27001 has specific, bounded requirements for business continuity that are achievable without a dedicated BCM programme — but they do require genuine thought and tested documentation.
What A.5.29 and A.5.30 Require
| Control | Title | What it requires |
|---|---|---|
| A.5.29 | Information security during disruption | Plan for maintaining information security at an adequate level during adverse situations. Define what security controls need to remain operational and how you will achieve this if normal operations are disrupted. |
| A.5.30 | ICT readiness for business continuity | Plan, implement, maintain, and test ICT continuity — based on continuity objectives and ICT continuity requirements. This includes recovery procedures, backup restoration, and alternative processing arrangements. |
BCP vs Disaster Recovery: Understanding the Distinction
A Business Continuity Plan (BCP) addresses how your organisation continues operating during a disruptive event — it is the operational response. A Disaster Recovery Plan (DRP) focuses specifically on restoring IT systems and data after a failure. ISO 27001 has requirements for both, but they do not need to be separate documents. For most SMEs, a combined BCP/DRP document is entirely appropriate.
RTO and RPO: The Two Critical Metrics
Your BCP/DRP must define recovery objectives for each critical system. Two metrics matter:
RTO — Recovery Time Objective
The maximum time your organisation can tolerate being without a system or service before the business impact becomes unacceptable.
Example: "Our CRM must be restored within 4 hours of a failure."
RPO — Recovery Point Objective
The maximum amount of data loss your organisation can tolerate, expressed as a time window. Determines how frequently you must back up data.
Example: "We cannot lose more than 1 hour of transaction data."
Define RTO and RPO for each system in your ISMS scope. Your backup strategy (A.8.13) and recovery procedures must be designed to meet these objectives. If your RPO is 1 hour but you back up daily, there is an unresolved gap that an auditor will identify.
What Your BCP/DRP Document Must Address
- Scope — which systems, services, and processes are covered
- Key dependencies — what systems, suppliers, or people the business relies on
- RTO and RPO for each critical system
- Recovery procedures — step-by-step instructions for restoring each system
- Roles and responsibilities during a disruption
- Communication plan — how to notify staff, customers, and regulators during an incident
- Alternative processing arrangements — how to operate if primary systems are unavailable
- Test schedule — when and how the plan will be exercised
Testing: The Most Missed Requirement
A.5.30 explicitly requires that ICT continuity is tested. A BCP/DRP that has never been tested is not a plan — it is a document. Auditors will ask when you last tested your recovery procedures and what the results were. Common forms of testing include:
Backup restoration test
Restore data from backup to a test environment and confirm the restored data is complete and usable. This should be done at least annually for each critical system.
Tabletop exercise
Walk through a scenario (e.g., ransomware attack, data centre outage) with key staff to identify gaps in the plan without actually executing recovery procedures.
Full recovery drill
Actually execute recovery procedures for a system — either in a test environment or during a planned maintenance window — and measure actual RTO against the objective.
The test record must document the date, scope, method, participants, results, and any issues identified. Issues identified during testing should generate improvement actions — an action log linked to the BCP review cycle.
Backup controls: A.8.13
Your BCP/DRP sits alongside your backup control requirements under A.8.13. Backups must be taken at a frequency consistent with your RPO, stored securely (ideally off-site or in a different cloud region), tested regularly, and protected from the same threats as your primary data. A backup that is vulnerable to the same ransomware attack as your production data provides no real recovery capability.
If you want help implementing your business continuity programme in line with what auditors expect, our ISO 27001 consulting service covers continuity controls as part of the full Annex A implementation.