ISO 27001:2022 Annex A 5.29 Information Security During Disruption Explained

In this guide you will learn how to implement ISO 27001 Annex A 5.29 Information Security During Disruption and pass your audit from ISO 27001 Lead Auditor Stuart Barker – author of the ultimate ISO 27001 Toolkit.

ISO 27001 Annex A 5.29 is an ISO 27001 control that wants you to plan and maintain information security at an appropriate level to you during disruption.

Purpose & Definition

The purpose of ISO 27001 Annex A 5.29 is protect information and other associated assets during disruption.

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

FREE ISO 27001 Annex A 5.29 Training Video

In this free training video you will learn How to implement ISO 27001Information Security During Disruption (Annex A 5.29) and Pass Your Audit.

Implementation Guide

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.

Business Continuity Templates

Information Security During Disruption is a key part of business continuity.

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.

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:

1. Have an ISO 27001 topic specific policy for business continuity
2. Implement a process for business continuity and disaster recovery
3. 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.

How to pass the audit

1. Have a business continuity plan and disaster recovery plan
2. Include in the plans the requirements for information security and what is different to normal operation
3. Test the plans
4. Test the information security requirements are in place as designed

ISO 27001 Templates

What an auditor check

• 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 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.

ISO 27001 Annex A 5.29 FAQ

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