ISO 27001 Business Continuity: What Annex A.5.29 and A.5.30 Require and How to Satisfy Your Auditor

Business continuity is where ISO 27001 implementation projects frequently stall. Organizations that breeze through access control policies and incident management procedures hit a wall when they reach Annex A.5.29 and A.5.30. The controls sound straightforward, but satisfying an auditor requires more than a recovery procedure document that nobody has tested.

The 2022 revision of ISO 27001 restructured the business continuity controls from the old A.17 domain into two focused controls under the organizational theme. This was not just a renumbering exercise. The new controls are more explicit about what constitutes adequate ICT readiness, and auditors are interpreting them with increasing rigor.

This guide covers exactly what these controls require, how to conduct a business impact analysis that feeds directly into your continuity planning, what auditors actually scrutinize during certification, and the most common failures we see in practice.

What A.5.29 and A.5.30 Actually Require

Before diving into implementation, it is worth understanding the precise scope of each control and how they differ from each other. Many organizations treat them as a single requirement, which leads to gaps that auditors will identify.

A.5.29: Information Security During Disruption

Control A.5.29 requires the organization to plan how to maintain information security at an appropriate level during disruption. This means defining what "disruption" looks like for your organization, identifying which security controls might be degraded during a disruption, and establishing procedures to maintain or restore security as quickly as possible.

The key word is "information security," not "business operations." This control is not asking you to keep the business running at full capacity. It is asking you to ensure that during a disruption, your security posture does not collapse. If your primary authentication system goes down, do people start sharing credentials? If your logging infrastructure fails, do you have a plan to restore visibility? These are the questions A.5.29 addresses.

A.5.30: ICT Readiness for Business Continuity

Control A.5.30 focuses on the technical infrastructure. It requires that ICT services have sufficient redundancy and recovery capabilities to meet the availability requirements identified through business impact analysis. This is the control that drives your Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) and ensures the technical infrastructure can actually deliver on them.

Business Impact Analysis: The Foundation Everything Builds On

The business impact analysis (BIA) is not explicitly required by ISO 27001 as a standalone document, but it is implicitly required because you cannot define meaningful RTOs and RPOs without one. Every auditor we have worked with expects to see a BIA or equivalent analysis that justifies your recovery targets.

A BIA that satisfies auditors answers four questions for each critical business process and supporting ICT service:

1. What happens if this service is unavailable? Quantify the impact in terms of financial loss, regulatory exposure, contractual obligations, and reputational damage at various time intervals (1 hour, 4 hours, 24 hours, 72 hours).
2. What is the maximum tolerable period of disruption (MTPD)? This is the point at which the impact becomes unacceptable to the organization. It directly drives your RTO.
3. How much data loss is acceptable? If you had to restore from backup, how much transaction or operational data could you afford to lose? This drives your RPO and your backup frequency.
4. What are the dependencies? Map the upstream and downstream dependencies of each critical service. Your database recovery is meaningless if the application server it supports has no recovery procedure.

Setting RTOs and RPOs That Are Honest

The most common BIA failure is setting aspirational RTOs instead of realistic ones. If your BIA says your RTO for the production database is 1 hour, but your last recovery test took 6 hours, you have a documented gap that an auditor will flag immediately.

Set RTOs based on what you can actually achieve with your current infrastructure, then compare them against the MTPDs from your BIA. If the RTO exceeds the MTPD, you have identified a risk that needs treatment. This feeds directly into your risk assessment process, which is exactly how ISO 27001 intends the system to work.

Documenting Your Business Continuity Plan

Your BCP for ISO 27001 needs to address information security specifically, not just operational recovery. Many organizations adopt an existing BCP from their operations team and assume it covers the ISO 27001 requirement. It rarely does, because operational BCPs focus on keeping the business running and often overlook what happens to security controls during the recovery process.

What the BCP Must Include

• Scope and activation criteria. Define what events trigger the plan, who has authority to activate it, and the escalation path. Be specific: "loss of primary data center" is an activation trigger; "something bad happens" is not.
• Roles and responsibilities. Name specific roles (not just individuals) responsible for each phase of the response. Include contact information, alternates, and decision-making authority.
• Communication procedures. How are stakeholders notified? What channels are used if primary communication systems are affected? Include templates for customer notifications if applicable.
• Recovery procedures for each critical service. Step-by-step procedures, including dependencies and sequence. If the application server must be recovered before the web tier, document that explicitly.
• Security considerations during recovery. This is what distinguishes an ISO 27001 BCP from a generic one. Document how access controls are maintained during recovery, how logging continues, how data integrity is verified after restoration, and what temporary security measures are in place during degraded operations.
• Return to normal operations. Procedures for transitioning from recovery mode back to normal operations, including verification that all security controls are functioning correctly before declaring the incident resolved.

Disaster Recovery: The Technical Implementation

The disaster recovery plan is the technical counterpart to the BCP. Where the BCP addresses process and coordination, the DR plan addresses infrastructure recovery. For A.5.30, auditors want to see evidence that your technical infrastructure can meet the RTOs and RPOs defined in your BIA.

Infrastructure Redundancy

A.5.30 specifically mentions redundancy. For SaaS organizations, this typically means multi-availability-zone deployments, database replication, automated failover for critical services, and geographically distributed backups. Document your redundancy architecture and map it to the services it protects.

For organizations running in AWS, GCP, or Azure, the cloud provider handles some redundancy at the infrastructure layer, but you are still responsible for application-level redundancy and data protection. Your cloud architecture decisions directly affect your ability to meet continuity requirements.

Backup Strategy

Auditors will verify that your backup strategy aligns with your RPOs. If your RPO for the production database is 1 hour, you need backup mechanisms that capture data at least every hour. This means continuous replication, transaction log shipping, or point-in-time recovery capability, not just nightly snapshots.

• Untested backups are not backups. A backup that has never been restored is an assumption, not a control. Auditors will ask for evidence of successful restoration tests, and "we have not tested yet" is a nonconformity.
• Backup monitoring gaps. If your backup job fails silently and nobody notices for two weeks, your actual RPO is two weeks regardless of what your policy says. Monitor backup success and alert on failures.
• No offsite or immutable copies. If your backups are stored in the same environment as your production data, a single event (ransomware, cloud account compromise, infrastructure failure) can destroy both. Maintain copies that are geographically separate and, ideally, immutable.
• Ignoring configuration and infrastructure-as-code. Restoring data to a server is only useful if you can also rebuild the server. Document or automate your infrastructure provisioning so that you can rebuild the environment, not just restore the data.

Testing Requirements: What Auditors Expect

ISO 27001 requires that business continuity plans are tested to ensure they remain valid and effective. The standard does not prescribe specific test types or frequencies, but auditors have clear expectations based on industry practice and the intent of the controls.

Types of Testing

At minimum, auditors expect to see evidence of at least one tabletop exercise and one technical recovery test (backup restoration or failover test) per year. Organizations pursuing certification for the first time should ideally complete at least one round of testing before the Stage 2 audit.

Documenting Test Results

Every test must produce a documented record that includes the test date, participants, scenario, expected outcomes, actual outcomes, any deviations or failures, and corrective actions. The corrective actions are critical. If a test reveals that your actual RTO is 8 hours instead of the 4 hours stated in your BIA, that is a finding that must be treated, either by improving the recovery capability or by revising the RTO with business approval.

Common Audit Findings and How to Avoid Them

Having supported organizations through dozens of ISO 27001 certification and surveillance audits, these are the business continuity findings that come up most frequently.

• No business impact analysis. The organization has a BCP but cannot explain how RTOs and RPOs were determined. Without a BIA, recovery targets are arbitrary, and the auditor cannot verify that the continuity arrangements are proportionate to the actual risk.
• BCP exists but has never been tested. This is a nonconformity in virtually every audit. A plan that has never been tested provides no assurance that it works. Even a simple tabletop exercise demonstrates that the organization has validated the plan.
• RTOs do not match actual capability. The BIA states a 2-hour RTO, but there is no evidence that a 2-hour recovery has ever been achieved. The auditor will compare stated objectives against test evidence and flag any discrepancy.
• No consideration of security during disruption. The BCP covers operational recovery but does not address how security controls are maintained. A.5.29 specifically requires maintaining information security during disruption, so a purely operational BCP is insufficient.
• Single points of failure in critical services. A.5.30 requires sufficient redundancy. If your production database runs on a single server with no replication, and your BIA classifies it as Tier 1, the control is not adequately implemented.
• Backup procedures not aligned with RPO. The RPO is 4 hours but backups run once daily. This arithmetic does not work, and auditors will catch it immediately.

Connecting Business Continuity to the Broader ISMS

Business continuity does not exist in isolation within your ISMS. It connects to several other areas that auditors evaluate holistically.

Your risk assessment should identify availability risks that feed into the BIA. Your Annex A control implementation includes controls for backup (A.8.13), redundancy (A.8.14), and monitoring (A.8.16) that directly support continuity. Your internal audit program should include business continuity in its scope, verifying that plans are current and tests have been conducted.

The management review under Clause 9.3 should include business continuity test results as an input, ensuring that senior management is aware of the organization's actual recovery capability and any gaps that need investment.

Integration with Incident Management

Your incident management process and your business continuity plan must be connected. Define clear criteria for when an incident escalates to a business continuity event. Not every incident triggers the BCP, but the people responding to incidents need to know when to escalate and how.

If you are also pursuing SOC 2 certification alongside ISO 27001, note that the SOC 2 Availability trust service criterion overlaps significantly with A.5.29 and A.5.30. Aligning your continuity documentation to satisfy both frameworks avoids duplicating effort.

Implementation Checklist for Certification Readiness

Use this checklist to verify your business continuity implementation before your certification audit. Each item represents something the auditor will look for or ask about.

• Business impact analysis completed with MTPD, RTO, and RPO defined for each critical service, reviewed and approved by business owners.
• Business continuity plan documented with scope, activation criteria, roles, communication procedures, recovery procedures, and security considerations during disruption.
• Disaster recovery procedures documented with step-by-step technical recovery instructions for each critical system, including dependencies and sequence.
• Backup strategy aligned with RPOs including backup frequency, retention, offsite storage, and monitoring of backup success.
• Redundancy implemented for critical services with architecture documentation showing how single points of failure are mitigated.
• At least one tabletop exercise completed with documented results, lessons learned, and corrective actions.
• At least one technical recovery test completed (backup restoration or failover test) with documented results showing actual recovery time versus target RTO.
• Corrective actions from tests tracked and closed with evidence of effectiveness.
• Plan review date recorded showing the plan has been reviewed for accuracy within the last 12 months.
• BCP referenced in risk treatment plan where availability risks are treated by continuity measures.

If you are using a compliance automation platform, map each of these items to evidence collection tasks so that audit preparation is continuous rather than a last-minute scramble.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.