How to Build an ISO 27001 Business Continuity Plan
An ISO 27001 business continuity plan should define how your organisation protects information during disruption and restores critical ICT services. Start with business impact, agree recovery objectives, document responsibilities and procedures, then test whether those arrangements work.
The focus is information security continuity, rather than a complete enterprise-wide continuity programme. Your plan should reflect the scope, risks and obligations of your information security management system (ISMS).
Begin by separating the standard's requirements from the practical arrangements that support them.
Key takeaways
ISO 27001 addresses information security during disruption and ICT readiness, with controls selected through risk treatment.
Business impact analysis helps establish recovery priorities, although ISO 27001 doesn't explicitly require a formal BIA.
Backups, redundancy and recovery procedures must support agreed recovery objectives.
Testing and documented improvements demonstrate whether your arrangements work.
What ISO 27001 business continuity requires
ISO/IEC 27001:2022 establishes requirements for managing information security risks. ISO/IEC 27001 governs risk-based control selection and the Statement of Applicability (SoA), while ISO 27002 offers implementation guidance for Annex A controls.
Record which controls are necessary, their implementation status and the justification for exclusions. Continuity arrangements should reflect contractual, legal and regulatory obligations; NIS 2 may be relevant depending on the organisation's operations and applicable EU-facing obligations.
Our ISO 27001 implementation guide explains how scope, assessment and controls fit into the wider ISMS.
A.5.29 and A.5.30: security and ICT readiness
A.5.29 requires planning to maintain information security at an appropriate level during disruption. Availability matters, but confidentiality and integrity remain important.
Define the security controls that must continue during emergency operations. These could include access restrictions, encryption, logging and approval of exceptional access.
A.5.30 addresses ICT readiness for business continuity. ICT continuity must be planned, implemented, maintained and tested against business continuity objectives and ICT continuity requirements.
A.8.13 and A.8.14: backups and redundancy
A.8.13 covers information backup. Backups must be maintained and regularly tested against the agreed backup policy.
Secure off-site storage or a different cloud region can reduce shared exposure. These are design choices, rather than universal storage prescriptions. Protect backup administration, encryption keys and recovery credentials too.
A.8.14 addresses redundancy of information processing facilities sufficient to meet availability requirements. A critical service may need failover-ready infrastructure because restoring backups would take too long.
Start with business impact and dependencies
Define activities and acceptable disruption
Start with the services and activities supported by your ISMS. Ask business owners how disruption affects customer commitments, revenue, safety, information security and regulatory obligations.
Assess how those effects increase over time. Record the minimum operating capacity needed during disruption and the point at which the impact becomes unacceptable.
A business impact analysis provides a structured way to capture these decisions. ISO 27001 doesn't explicitly mandate a formal BIA, but it helps establish defensible continuity requirements.
Identify dependencies and security risks
Map each critical activity to its people, systems, data, premises and critical suppliers across the supply chain. Include less visible dependencies such as identity services, DNS, network connectivity, encryption keys and outsourced administration.
Then assess disruption scenarios against those dependencies. Ransomware, supplier failure, loss of premises and unavailable administrators create different recovery challenges.
Risk assessment addresses threats, vulnerabilities, likelihood and impact. Impact analysis establishes the consequences of interrupted activities. Both inform recovery priorities.
ISO/IEC 27005 guidance on information security risk supports the assessment and treatment process.
Assign an owner to each dependency. Supplier recovery commitments must support your objectives, rather than contradict them.
Set measurable RTO and RPO targets
Your recovery time objective (RTO) defines the maximum time you plan to tolerate being without a system or service. Set it so recovery occurs before business impact becomes unacceptable.
Your recovery point objective (RPO) defines the maximum tolerable data loss, expressed as time. It determines the recovery points your backup or replication arrangements must provide.
Translate each objective into a measurable recovery requirement.
Objective | Practical meaning | Evidence needed |
|---|---|---|
Four-hour RTO | Restore the required service within four hours | Timed recovery exercise, including validation |
One-hour RPO | Lose no more than one hour of data | Recoverable data points no more than one hour apart |
Both objectives | Restore service on time with sufficiently recent data | End-to-end test measuring both outcomes |
A daily backup cannot meet a one-hour RPO. Replication may reduce data loss, but it doesn't replace protected backups where corruption or malicious changes could replicate.
Agree targets with business owners before selecting technology. Include incident assessment, access, restoration and business validation within the recovery budget.
Document operating and recovery arrangements
A business continuity plan (BCP) explains how operations continue during disruption. A disaster recovery plan (DRP) focuses on restoring IT systems and data.
ISO 27001 doesn't prescribe two separate documents with those titles. SMEs can combine them in one controlled plan where responsibilities and procedures remain clear.
Define activation and continued operations
Your plan should identify its scope, owner, approver and version. State who can activate it, the activation criteria and who takes responsibility when the primary decision-maker is unavailable.
Document the operational essentials:
Identify critical activities, dependencies and minimum service levels.
Assign responsibilities, deputies and escalation routes.
Define alternative processing arrangements and their security controls.
Set communication responsibilities for employees, customers, suppliers and relevant authorities.
Record recovery objectives, exercise schedules and review triggers.
Keep contact information and a protected copy accessible when normal systems are unavailable. Define how temporary records are secured and reconciled after recovery.
Write executable recovery procedures
Document recovery order, prerequisites, access arrangements and step-by-step restoration instructions. Include checks for data integrity, security configuration and business acceptance before reopening services.
For cyber incidents, define who authorises restoration and how teams establish that the recovery environment is safe.
A failover environment needs more than spare capacity. Its identity services, connectivity, configurations and data must support the required service.
Test recovery and retain audit evidence
A completed document doesn't demonstrate recovery capability. Testing provides evidence that people, technology and suppliers can meet the objectives.
Use three complementary test methods
Backup restoration tests establish whether protected data can be recovered and used. Tabletop exercises assess decisions, escalation and communication. Full recovery drills measure service restoration against the RTO and RPO.
The following is a recommended starting schedule, rather than an ISO-mandated frequency.
Activity | Suggested starting interval | Main outcome |
|---|---|---|
Restore selected backups | Monthly | Recoverability and data integrity |
Run a tabletop exercise | Every six months | Decisions, responsibilities and communications |
Perform an end-to-end recovery drill | Annually and after major changes | Measured recovery performance |
Adjust intervals to risk, system change and business obligations. Include suppliers where their actions affect recovery.
Keep records that support improvement
Each test record should capture the date, scope, method, participants, results and issues. Record actual recovery time and the age of recovered data against the approved objectives.
Log improvement actions with owners, deadlines and closure evidence. Feed findings into the BCP review cycle, internal audit and management review where appropriate.
A successful backup job proves that a backup process ran. It doesn't prove that the service can be restored within its RTO.
Keep the evidence connected: approved objectives, recovery design, exercise results and corrective actions should tell a consistent story.
Where a target is missed, address the cause. Don't change the objective simply to match existing technical capability.
ISO 27001 or ISO 22301: which do you need?
ISO 27001 business continuity arrangements focus on information security and supporting ICT within the ISMS scope.
ISO 22301:2019 establishes requirements for a business continuity management system (BCMS). It requires a formal BIA covering prioritised activities, resource dependencies and the time before disruption becomes unacceptable.
Its continuity arrangements address critical functions within the BCMS scope. These can include manufacturing, logistics, customer service and premises, alongside IT.
ISO 22301 also gives broader structure to crisis communication with employees, customers, regulators and the media, where relevant.
Both standards use the Annex SL management system structure. Leadership, documented information, internal audit, management review and continual improvement can therefore share processes.
An ISO 27001 audit assesses continuity-related controls within the ISMS. An ISO 22301 audit assesses the scoped BCMS, including impact analysis, continuity strategies, plans and exercises.
Pursue ISO 22301 when customers, contracts or operational exposure require broader continuity assurance. ISO 27001 certification doesn't automatically demonstrate conformity with ISO 22301.
Frequently asked questions
What evidence should an ISO 27001 auditor expect?
An auditor needs evidence proportionate to your scope, risks and applicable controls. This normally includes justified control selection, approved recovery requirements, maintained procedures and exercise records.
Interviews should demonstrate that responsible staff understand their roles. Records should show how identified weaknesses were addressed. A polished plan without operating evidence is insufficient to demonstrate effective implementation.
When should the continuity plan be reviewed?
Review it at planned intervals and after significant changes or relevant incidents and exercises. Changes to suppliers, hosting, identity services, staffing or customer commitments can invalidate existing arrangements.
Update the linked procedures and contact details as well. A revised policy doesn't correct an obsolete recovery runbook.
Build continuity around demonstrated recovery
An effective ISO 27001 business continuity plan connects business impact, security requirements and tested recovery capability. Its value is demonstrated preparedness, supported by clear responsibilities and evidence of improvement.
We provide ISO 27001 implementation support to help organisations develop practical controls, documentation and certification readiness.
If you would like to find out more information or require any of our services please Contact Us. Complete our contact form to discuss your requirements.
Comments