ISO 27001 Annex A 5.29 Information Security During Disruption is a security control that mandates the explicit integration of security requirements into continuity plans. This ensures that critical confidentiality and integrity standards are maintained during outages, providing the Business Benefit of preventing data breaches during high-risk recovery events.
In this guide, I will show you exactly how to implement ISO 27001 Annex A 5.29 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.
I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.
Key Takeaways: ISO 27001 Annex A 5.29 Information Security During Disruption
ISO 27001 Annex A 5.29 requires organizations to plan how to maintain information security at an appropriate level during a disruption. When an outage or business continuity event occurs, security controls often get bypassed in the rush to restore operations. This corrective and preventive control ensures that your security posture remains intact even during a crisis. The objective is to prevent “security shortcuts” that could lead to a data breach while the organization is already vulnerable.
Core requirements for compliance include:
- Security Integration in BCP/DR: You must explicitly include information security requirements within your Business Continuity Plans (BCP) and Disaster Recovery (DR) procedures.
- Maintenance of Controls: You should aim to replicate the same level of security during a disruption as you have in normal operations. If a primary control (e.g., SSO) fails, a pre-approved Fallback Control must be ready.
- Continuity of Confidentiality & Integrity: While the focus of BCP is often on Availability, this control mandates that Confidentiality and Integrity are not sacrificed to get systems back online.
- Testing and Validation: It is not enough to have a plan; you must test it. Your business continuity exercises should include a step to verify that security controls are functioning correctly in the fallback environment.
- Lessons Learned: Following any disruption or test, you must conduct a review to identify where security was compromised and update your plans accordingly (Annex A 5.27).
Audit Focus: Auditors will look for “The Security Continuity Trail”:
- Plan Consistency: “Show me your Business Continuity Plan. Where does it describe the security controls that remain active during a failover?”
- Test Evidence: “Show me the results of your last disaster recovery test. How did you verify that data encryption and access logs were still active in the secondary environment?”
- Fallback Awareness: “If your primary VPN fails, how do staff access systems securely? What specific instructions are given to them to maintain security during this time?”
Fallback Security Checklist (Audit Prep):
| Security Scenario | Primary Control (Normal Operations) | Fallback Control (Disruption State) | ISO 27001:2022 Mapping |
|---|---|---|---|
| System Access | Enterprise Single Sign-On (SSO) with MFA. | Emergency Admin Accounts (Securely vaulted/Break-glass). | 5.29 & 5.18 (Access Rights) |
| Data Entry | Encrypted Cloud-Native Database environments. | Secure Paper Forms (Mandatory storage in Grade 1 Safes). | 5.29 & 7.10 (Storage Media) |
| Remote Access | Corporate VPN via SD-WAN with MFA enforcement. | 5G Dongles (Must utilise integrated hardware firewalls). | 5.29 & 8.20 (Network Security) |
| Physical Site | Electronic Badge Readers with centralized logging. | Physical Security Guards and Manual Sign-in Logs. | 5.29 & 7.2 (Physical Monitoring) |
Table of contents
- What is ISO 27001 Annex A 5.29?
- Watch the ISO 27001 Annex A 5.29 Tutorial
- ISO 27001 Annex A 5.29 Podcast
- ISO 27001 Annex A 5.29 Implementation Guidance
- How to implement ISO 27001 Annex A 5.29
- Fallback Security Checklist
- How to comply
- How to Audit ISO 27001 Annex A 5.29
- How to pass an ISO 27001 Annex A 5.29 audit
- What will an auditor check for ISO 27001 Annex A 5.29?
- Top 3 ISO 27001 Annex A 5.29 mistakes people make and how to avoid them
- Applicability of ISO 27001 Annex A 5.29 across different business models.
- Fast Track ISO 27001 Annex A 5.29 Compliance with the ISO 27001 Toolkit
- ISO 27001 Annex A 5.29 Applicable Laws and Related Standards
- ISO 27001 Annex A 5.29 FAQ
- Related ISO 27001 Controls
- Further Reading
- ISO 27001 Controls and Attribute values
Do it Yourself ISO 27001
Our Lead-Auditor verified templates with expert support have a 100% success rate.
What is ISO 27001 Annex A 5.29?
ISO 270001 Annex A 5.29 is Information Security During Disruption and this rule is about ensuring that information security is maintained during a disruption, outage or business continuity event.
ISO 27001 Annex A 5.29 Information Security During Disruption is an ISO 27001 control that wants you to plan and maintain information security at an appropriate level to you during disruption.
What is the purpose of ISO 27001 Annex 5.29?
The purpose of ISO 27001 Clause 5.29 is protect information and other associated assets during disruption.
What is the definition of ISO 27001 Annex 5.29?
The ISO 27001 standard defines ISO 27001 Annex A 5.29 as:
The organisation should plan how to maintain information security at an appropriate level during disruption.
ISO 27001:2022 Annex A 5.29 Information Security During Disruption
Watch the ISO 27001 Annex A 5.29 Tutorial
In this video I show you how to implement ISO 27001 Annex A 5.29 and how to pass the audit.
ISO 27001 Annex A 5.29 Podcast
In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001 Annex A 5.29 Information Security During Disruption. The podcast explores what it is, why it is important and the path to compliance.
ISO 27001 Annex A 5.29 Implementation Guidance
It is my experience that the best way to implement Annex A 5.29 is to replicate the same level of information security in your business continuity plans, disaster recovery plans and disruption operations. Doing anything else, whilst you may need to and you should, will lead to a more complex environment open to a greater level of questioning come your audits.
How to implement ISO 27001 Annex A 5.29
Implementing ISO 27001 Annex A 5.29 is about ensuring that your security posture does not collapse when your primary systems do. As a Lead Auditor, I expect to see that you have defined, implemented, and tested your security controls to work even during a significant business disruption. Follow these ten steps to build a resilient information security continuity framework that satisfies both regulatory requirements and audit scrutiny.
1. Formalise the Information Security Business Impact Analysis (ISBIA)
Conduct a specific ISBIA to identify which assets and processes require security protection during a crisis. Result: Establishes a prioritised list of assets based on data sensitivity rather than just operational uptime.
- Identify critical information assets within the organisation’s Asset Register.
- Define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) specifically for security controls like encryption and logging.
- Document the potential impact of a security failure during a period of operational disruption.
2. Determine Security Requirements for Disrupted States
Determine the minimum level of security required during a failover scenario. Result: Prevents the common mistake of lowering security bars (e.g. disabling MFA) just to get systems back online quickly.
- Establish which technical controls must remain active at all times.
- Define “Degraded Mode” security protocols for high-risk environments.
- Identify any legal or regulatory obligations that persist regardless of system status.
3. Provision Redundant Security Infrastructure
Provision failover capabilities for critical security appliances like firewalls, IDS, and MFA servers. Result: Ensures that the “protective shield” remains operational when primary infrastructure fails.
- Deploy secondary security appliances in geographically diverse regions or separate cloud availability zones.
- Verify that failover configurations are synchronised with production rule sets.
- Ensure that automated alerting systems have redundant communication paths.
4. Document Technical Information Security Continuity Plans (ISCP)
Document technical playbooks that detail how to maintain security during a transition to backup systems. Result: Provides the response team with clear instructions to follow under high-pressure conditions.
- Create step by step guides for redirecting secure traffic.
- Include manual workarounds for automated security processes that may be offline.
- Store these plans in an “offline-ready” format accessible during a total network outage.
5. Establish “Break-Glass” IAM Roles and Privileged Access
Establish emergency Identity and Access Management (IAM) procedures for disruption events. Result: Allows administrators to perform critical recovery tasks while maintaining a strict audit trail.
- Pre-configure “Break-Glass” accounts with necessary recovery permissions.
- Implement hardware-based MFA for recovery accounts to bypass potential SMS or software-token failures.
- Define a formal process for the activation and subsequent revocation of emergency privileges.
6. Implement Immutable Backups and Cryptographic Integrity
Implement backup solutions that are protected by encryption and immutability. Result: Safeguards your last line of defence against ransomware and accidental data corruption during recovery.
- Configure “Air-Gapped” or “Write Once Read Many” (WORM) storage for critical security logs.
- Ensure that cryptographic keys required for data restoration are stored in a resilient Key Management System (KMS).
- Verify the integrity of backup data through automated periodic hashing.
7. Define Rules of Engagement (ROE) for Third-Party Providers
Define clear ROE documents and SLAs with Managed Service Providers (MSPs) and cloud vendors. Result: Clarifies security responsibilities and ensures your partners are ready to support your recovery efforts.
- Verify that vendor contracts include specific security continuity obligations.
- Establish out of band communication channels with vendor support teams.
- Audit vendor SOC reports to ensure their own continuity plans meet your requirements.
8. Execute Periodic Continuity Testing and Simulations
Execute tabletop exercises and full-scale failover simulations to verify plan effectiveness. Result: Provides empirical evidence that your security controls failover correctly and meet recovery objectives.
- Conduct annual “Red Team” style disruption simulations.
- Test the ability of staff to execute playbooks without access to primary systems.
- Measure the actual recovery times against the predefined security RTOs.
9. Conduct Post-Exercise Reviews and Root Cause Analysis
Conduct a formal review after every test or real disruption to identify gaps. Result: Facilitates the continuous improvement of the ISMS by turning failures into actionable security intelligence.
- Perform a Root Cause Analysis (RCA) on any security controls that failed during the test.
- Document “Lessons Learnt” and share them with the executive leadership team.
- Update the Risk Register based on the findings of the simulation.
10. Audit the Continuity Lifecycle for Certification Evidence
Audit the entire information security continuity process as part of your internal audit cycle. Result: Generates the documented evidence required to pass the ISO 27001 Stage 2 certification audit.
- Collate evidence of testing, including timestamps and participant logs.
- Verify that all continuity plans have been reviewed and signed off by senior management within the last 12 months.
- Ensure that the Statement of Applicability (SoA) accurately reflects the implementation status of Annex A 5.29.
I’ve sat in the Auditor’s chair for 20 years. These are the exact tools I use to guarantee a pass.
Fallback Security Checklist
| Scenario | Primary Control (Normal) | Fallback Control (Disruption) |
| System Access | Single Sign-On (SSO). | Emergency Admin Accounts (in sealed envelope). |
| Data Entry | Encrypted Database. | Paper Forms (Must be locked in safe). |
| Remote Access | VPN + MFA. | 5G Dongles (Must have corporate firewall). |
| Physical Site | Electronic Badges. | Physical Guards + Manual Sign-in Log. |
How to comply
To comply with ISO 27001 Annex A 5.29 you are going to implement the ‘how’ to the ‘what’ the control is expecting. In short measure you are going to:
- Have an ISO 27001 topic specific policy for business continuity
- Implement a process for business continuity and disaster recovery
- Incorporate that process into your business operations
How to Audit ISO 27001 Annex A 5.29
Auditing ISO 27001 Annex A 5.29 requires a technical deep dive into how security persists during a system failure or major disaster. As a Lead Auditor, I look for evidence that the organisation has defined specific security requirements for “disrupted states” and has tested those controls under stress. This 10-step audit programme focuses on the intersection of resilience and data protection to ensure your compliance is robust and defensible.
1. Audit the Information Security Business Impact Analysis (ISBIA)
Inspect the ISBIA to ensure that security requirements are explicitly defined for every critical business process. Result: Confirms that recovery priorities are based on data sensitivity and not just operational uptime.
- Verify that the Asset Register is mapped to specific Recovery Time Objectives (RTO).
- Check for defined Recovery Point Objectives (RPO) for cryptographic keys and security logs.
- Ensure that senior management has formally approved the impact thresholds.
2. Review the Information Security Continuity Plans (ISCP)
Examine the documented ISCP to verify it contains specific technical instructions for maintaining security during failover. Result: Proves that security is “baked in” to the continuity strategy rather than added as an afterthought.
- Check for procedures to maintain firewall rules and ACLs during network redirection.
- Verify that out-of-band communication channels are documented and secure.
- Confirm the presence of Rules of Engagement (ROE) for third-party disaster recovery providers.
3. Provision Emergency Identity and Access Management (IAM) Roles
Audit the “Break-Glass” account procedures and temporary IAM roles used during a disruption. Result: Ensures that privileged access is controlled and logged even when standard HR onboarding/offboarding processes are bypassed.
- Inspect the vaulting mechanism for emergency administrative credentials.
- Verify that MFA is still mandatory for all remote access during a disaster state.
- Audit the revocation process for temporary access once normal operations resume.
4. Verify Security Control Parity in Recovery Environments
Inspect the security configuration of the Disaster Recovery (DR) site or cloud failover region. Result: Confirms that the recovery environment is as secure as the production environment, preventing attackers from exploiting weaker secondary systems.
- Cross-reference the patch levels of DR servers against production baselines.
- Ensure that Endpoint Detection and Response (EDR) agents are active on all failover assets.
- Verify that encryption at rest is enabled on all backup and secondary storage volumes.
5. Audit Backup Integrity and Cryptographic Protection
Evaluate the technical implementation of backup security to protect against ransomware and data corruption. Result: Guarantees that the data being recovered is authentic, integral, and protected from unauthorised access.
- Inspect logs for successful “Immutable Backup” flags or air-gapped storage verification.
- Check that backup encryption keys are stored separately from the backup data.
- Verify that backup restoration tests include a malware scanning phase.
6. Evaluate Security Logging and Monitoring Continuity
Verify that SIEM and SOC monitoring remain operational when primary systems are disrupted. Result: Ensures that a “disaster” is not used as cover for a targeted cyber attack.
- Check that logs from failover systems are being ingested by the central SIEM.
- Verify that alert logic accounts for different IP ranges or hostnames in the DR environment.
- Audit the availability of the SOC team’s access to monitoring dashboards during a site loss.
7. Inspect Evidence of Continuity Testing and Exercises
Review the results of recent tabletop exercises or full-scale failover simulations. Result: Provides empirical evidence that the information security continuity plan actually works in practice.
- Verify that security staff were active participants in the latest continuity drill.
- Check for a formal “Pass/Fail” criteria based on security RTOs.
- Inspect the “Lessons Learnt” logs to see if security gaps were identified during the test.
8. Audit Third-Party and Supply Chain Continuity
Review the continuity attestations and SOC reports of critical SaaS and infrastructure providers. Result: Validates that your security posture is not compromised by a failure in the supply chain.
- Verify that vendor contracts include specific uptime and security recovery SLAs.
- Check for evidence of “Right to Audit” clauses being exercised for critical providers.
- Ensure that vendor BCP/DR plans align with the organisation’s internal recovery timelines.
9. Review Staff Competency and Emergency Response Training
Inspect training records for employees with specific security roles during a disruption. Result: Confirms that the human element of the response is capable of executing technical playbooks under pressure.
- Check that “Emergency Response” is part of the regular security awareness programme.
- Verify that specific technical training has been provided for failing over security infrastructure.
- Audit the distribution list for continuity plans to ensure all key staff have offline access.
10. Validate Continuous Improvement via Post-Incident Reviews
Audit the “Post-Incident Review” (PIR) process following any real disruption or significant test. Result: Demonstrates that the organisation uses real-world data to strengthen its resilience over time.
- Verify that corrective actions from previous tests have been implemented and closed.
- Check that the Risk Register was updated following any identified continuity failures.
- Confirm that the ISMS Statement of Applicability (SoA) reflects the current continuity state.
The Tools We Use.
100% Audit Success. Zero AI Guesswork.
How to pass an ISO 27001 Annex A 5.29 audit
- Have a business continuity plan and disaster recovery plan
- Include in the plans the requirements for information security and what is different to normal operation
- Test the plans
- Test the information security requirements are in place as designed
What will an auditor check for ISO 27001 Annex A 5.29?
- 1. That you have documented your business continuity and disaster recovery plans: The audit will check the documentation, that you have reviewed it and signed and it off and that it represents what you actually do not what you think they want to hear.
- 2. That you can demonstrate the process working: They are going to ask you for evidence to the information security during a disruption and take at least one example. For this example you are going to show them and walk them through the process and prove that you followed it and that the process worked.
- 3. That you can learn your lesson: Documenting your lessons learnt and following this through to continual improvements or incident and corrective actions will be checked.
Top 3 ISO 27001 Annex A 5.29 mistakes people make and how to avoid them
- 1. Not having a documented disaster recovery and business continuity policy and plans: This is the most common mistake made by organisations. Documentation is essential for effective incident response.
- 2. Not including information security requirements in the plans: There are so many mistakes that can be made but this particular requirement is about information security in a disruption so be sure you understand it and can talk to it and evidence it.
- 3. Not Testing: It is important to monitor its effectiveness of the information security during a disruption. This means reviewing the process, conducting internal audits and reviewing actual incidents for lessons learnt. The number one thing to do it test and be able to evidence the test.
Applicability of ISO 27001 Annex A 5.29 across different business models.
| Business Type | Applicability | Examples of Control Implementation |
|---|---|---|
| Small Businesses | Highly applicable for ensuring that when the office is closed or the primary server is down, security is not “turned off” to save time. The focus is on simple fallback methods that maintain data confidentiality during a crisis. |
|
| Tech Startups | Critical for ensuring that automated “failover” to secondary cloud regions doesn’t leave data unencrypted or logs unmonitored. Compliance involves integrating security checks into the Disaster Recovery (DR) automation. |
|
| AI Companies | Vital for protecting massive training datasets and proprietary model weights during high-pressure recovery events. Focus is on preventing data corruption or unauthorized exfiltration during “unstable” system states. |
|
Fast Track ISO 27001 Annex A 5.29 Compliance with the ISO 27001 Toolkit
| Compliance Factor | SaaS Compliance Platforms | High Table ISO 27001 Toolkit | Audit Evidence Example |
|---|---|---|---|
| Strategy Ownership | Rents access to your continuity plans; if you cancel the subscription, your documented fallback security standards vanish. | Permanent Assets: Fully editable Word/Excel Business Continuity Policies and DR Plans that you own forever. | A localized “Fallback Security Checklist” stored on your secure server defining mandatory controls during a system outage. |
| Operational Resilience | Attempts to “automate” DR via dashboards that cannot physically manage manual sign-in logs or emergency admin credentials. | Governance-First: Formalizes your existing disaster recovery workflows into an auditor-ready framework. | A completed “Continuity Test Log” proving that security controls (like encryption) remained active during a recent simulation. |
| Cost Efficiency | Charges a “Disaster Tax” based on the number of continuity plans or simulations, creating perpetual overhead. | One-Off Fee: A single payment covers your disruption governance for one small office or a global network. | Allocating budget to redundant failover sites or resilient hardware rather than monthly “continuity” dashboard fees. |
| Architectural Freedom | Mandates rigid reporting formats that often fail to account for offline processes or specialized physical security needs. | 100% Agnostic: Procedures adapt to any environment—cloud failover, hybrid stacks, or manual paper-based fallbacks. | The ability to evolve your resilience strategy (e.g., shifting to a “Work from Home” fallback) without reconfiguring a rigid SaaS module. |
ISO 27001 Annex A 5.29 Applicable Laws and Related Standards
| Standard / Law | Relevant Control / Article | Mapping and Requirements |
|---|---|---|
| NIST CSF v2.0 | PR.IR-P1, PR.IR-P3, RC.RP-01 | Requires that recovery processes incorporate security considerations and that “degraded” operating states remain protected. |
| NIS2 Directive (EU) | Article 21 (2)(c) | Mandates business continuity and crisis management, ensuring that security measures are resilient and backups are secured during outages. |
| DORA (EU) | Articles 11 and 12 | Requires financial entities to establish an ICT Business Continuity Policy where security controls remain effective during plan activation. |
| SOC 2 (TSC) | CC9.1, A1.2, A1.3 | Focuses on Availability; requires protection against environmental threats and ensuring recovery processes do not bypass security controls. |
| EU GDPR | Article 32(1)(c) | Mandates the ability to restore availability and access to personal data in a timely manner while maintaining 100% security integrity. |
| UK Data (Use and Access) Act 2025 | Security and Resilience Clauses | Requires highly secure data environments to remain functional and integral during access surges or infrastructure disruptions. |
| UK Cyber Security and Resilience Bill | MSP Resilience Obligations | Expands NIS requirements to Managed Service Providers, ensuring their security controls do not “fail open” during infrastructure outages. |
| CIRCIA (USA) | Section 2242 | Categorises the failure to maintain security during a disruption as a reportable “substantial cyber incident” for critical infrastructure. |
| EU AI Act | Article 15 (Robustness) | High-risk AI systems must be resilient to errors or faults; security during model failover must prevent bias or accuracy degradation. |
| ISO/IEC 42001 (AI Management) | Annex A.5.5 (Robustness) | Requires AI systems to maintain predefined security and accuracy performance levels during technical failures or adversarial attacks. |
| HIPAA (USA) | 164.308(a)(7) | The “Contingency Plan” standard: mandates protecting ePHI while operating in emergency mode, including backup and recovery plans. |
| CCPA / CPRA (California) | 1798.100 (e) | Interprets “reasonable security” to include operational resilience and the prevention of data loss during system downtime. |
| EU Product Liability Directive (PLD) | Article 4 (Defectiveness) | Classifies software as a product; failure to maintain security during disruption leading to harm is legally defined as a “product defect.” |
| ECCF (EU Cybersecurity Cert) | Assurance Levels | Requires proof that security functionality persists during all defined failure states to achieve “Substantial” or “High” labels. |
ISO 27001 Annex A 5.29 FAQ
What is ISO 27001 Annex A 5.29?
ISO 27001 Annex A 5.29 is an organisational control that mandates information security must be maintained at a predetermined level during a disruption or disaster. It ensures that security controls are not abandoned during an emergency and mandates that business continuity plans include specific security provisions.
Is information security continuity mandatory for ISO 27001?
Yes, maintaining information security during a disruption is a mandatory requirement if your risk assessment identifies that a loss of security during an incident would impact the organisation. Auditors expect to see security embedded within your Business Continuity Plan (BCP).
How does 5.29 differ from 5.30 (ICT Readiness)?
The primary difference is that Control 5.29 focuses on the “security” of information during an event, whereas Control 5.30 focuses on the “recovery” and availability of the technology itself. Both controls must work in tandem to satisfy a full ISMS audit.
Can security controls be bypassed during an emergency?
No, security controls should never be bypassed; however, ISO 27001 allows for “emergency procedures” that must be pre-defined, risk-assessed, and formally authorised. Bypassing MFA or encryption during a disaster creates a significant insider threat risk.
What evidence do auditors expect for ISO 27001 Control 5.29?
Auditors look for verifiable proof that security was considered during business continuity planning, including test reports and documented recovery objectives. This includes a Business Impact Analysis (BIA) that includes security requirements and post-test reports.
How often should security continuity plans be tested?
ISO 27001 requires security continuity plans to be tested at “planned intervals” or following significant changes, which typically translates to an annual requirement. Annual testing is the industry standard for maintaining certification.
ISO 27001 Controls and Attribute values
| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
|---|---|---|---|---|
| Corrective | Confidentiality | Protect | Continuity | Protection |
| Preventive | Integrity | Respond | Resilience | |
| Availability |
About the author
