Why You Need a Business Continuity Policy for ISO 27001
ISO 27001:2022 requires organizations to maintain information security during adverse situations and ensure ICT readiness for business continuity. Annex A controls A.5.29 and A.5.30 make this explicit, and Clause 8.1 requires operational planning that covers continuity scenarios.
Without a documented business continuity policy, you will fail your certification audit. But more importantly, without a tested continuity plan, a single ransomware attack or infrastructure failure could shut down your business for days or weeks.
This guide walks you through building a business continuity policy that satisfies auditors and actually protects your organization.
What ISO 27001:2022 Requires
Clause References
- Clause 6.1 - Actions to address risks and opportunities, including continuity risks
- Clause 8.1 - Operational planning and control for continuity processes
- Clause 8.2 - Information security risk assessment covering availability
- Clause 10.1 - Continual improvement of continuity arrangements
Annex A Controls
- A.5.29 - Information Security During Disruption: The organization shall plan how to maintain information security at an appropriate level during disruption
- A.5.30 - ICT Readiness for Business Continuity: ICT readiness shall be planned, implemented, maintained, and tested based on business continuity objectives
- A.5.2 - Information Security Roles and Responsibilities: Must include continuity responsibilities
- A.8.13 - Information Backup: Backup copies shall be maintained and regularly tested
- A.8.14 - Redundancy of Information Processing Facilities: Sufficient redundancy to meet availability requirements
Business Continuity Policy Structure
A compliant business continuity policy typically includes the following sections:
1. Purpose and Scope
Define what the policy covers:
- Which business processes are in scope
- Which locations and systems are included
- The relationship between this policy and the overall ISMS
Example scope statement: "This policy applies to all information systems, business processes, and personnel within the scope of the ISMS as defined in the ISMS Scope Statement. It covers prevention, detection, response, and recovery from events that could disrupt business operations."
2. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| Top Management | Approve the policy, allocate resources, review annually |
| ISMS Manager | Maintain the policy, coordinate testing, report results |
| Business Process Owners | Define RTO/RPO for their processes, participate in BIA |
| IT Operations | Implement and test technical recovery solutions |
| All Employees | Follow continuity procedures, report incidents |
| Crisis Management Team | Coordinate response during actual disruptions |
3. Business Impact Analysis Requirements
Your policy should mandate:
- Annual business impact analysis for all critical processes
- Defined RTO and RPO for each critical process
- Impact assessment across financial, operational, reputational, and legal dimensions
- Regular review and update when processes change
Use the RTO/RPO and BIA Helper to systematically calculate recovery objectives and generate BIA documentation.
4. Continuity Strategy
Document your approach to maintaining operations:
Prevention strategies:
- Redundant infrastructure for critical systems
- Geographically distributed data centers
- Regular security patching and vulnerability management
Detection strategies:
- Monitoring and alerting for system failures
- Automated health checks for critical services
- Incident detection and escalation procedures
Response strategies:
- Incident response activation criteria
- Communication protocols (internal and external)
- Decision authority for failover activation
Recovery strategies:
- Backup and restoration procedures
- Failover to secondary systems
- Manual workaround procedures for critical processes
5. Testing and Exercise Requirements
Your policy must specify testing frequency and scope:
| Test Type | Minimum Frequency | Scope |
|---|---|---|
| Business continuity plan review | Every 6 months | All plans |
| Tabletop exercise | Quarterly | Critical processes |
| Backup restoration test | Monthly | Rotating systems |
| Full failover test | Annually | Primary data center |
| Communication cascade test | Semi-annually | All key contacts |
6. Maintenance and Review
- Policy review frequency (at least annual)
- Triggers for unscheduled review (major incidents, organizational changes, new systems)
- Version control and change history
- Distribution and awareness requirements
Common Audit Findings
Finding 1: No Business Impact Analysis
Many organizations write a business continuity policy but never conduct the underlying BIA. Without a BIA, your RTO/RPO values are arbitrary, and your recovery strategies may be misaligned with actual business needs.
Finding 2: Untested Recovery Procedures
A policy that says "backups are taken daily" is worthless if nobody has verified that those backups can be restored within the required timeframe.
Finding 3: Missing Dependencies
Your continuity plan accounts for your primary application server failing, but not for the authentication server it depends on, the VPN that remote staff need, or the DNS service that routes traffic.
Finding 4: Outdated Contact Information
Crisis communication lists with former employees, old phone numbers, or personal email addresses that are never checked during emergencies.
Finding 5: No Integration with Risk Register
Business continuity risks should be tracked in your risk register with defined treatments. If your BIA identifies a gap between RTO and actual recovery capability, that gap is a risk that needs formal treatment.
How to Write Your Policy Step by Step
Step 1: Gather Requirements
Review ISO 27001 Clause 8.1, Annex A controls A.5.29 and A.5.30, and any regulatory or contractual requirements that apply to your organization.
Step 2: Conduct or Update Your BIA
Use structured analysis to identify critical processes, assess impacts, and define recovery objectives. The RTO/RPO and BIA Helper provides a guided workflow for this.
Step 3: Draft the Policy
Follow the structure outlined above. Keep the policy concise - detailed procedures belong in separate documents (Disaster Recovery Plan, Incident Response Plan, Crisis Communication Plan).
Step 4: Define Supporting Procedures
Your policy references but does not contain the detailed "how-to" procedures:
- Disaster Recovery Plan (technical recovery steps)
- Crisis Communication Plan (who contacts whom)
- Business Recovery Plan (manual workaround procedures)
- IT Recovery Procedures (system-specific runbooks)
Step 5: Get Approval and Communicate
Top management must approve the policy (Clause 5.1). Distribute it to all relevant personnel and include it in your security awareness program.
Step 6: Test and Improve
Schedule your first tabletop exercise within 30 days of policy approval. Document results and feed lessons learned back into the policy and procedures.
Download a Professional Template
Writing a business continuity policy from scratch is time-consuming and error-prone. The ISO 27001 Document Pack includes a complete, auditor-approved Business Continuity Policy template along with supporting templates for Disaster Recovery Plans and Incident Response procedures.
All templates are in editable Word format with no watermarks, ready to customize for your organization.
Found this article helpful?
Share it with your colleagues.