What is ISO 27001 Annex A 5.29 – Information Security During Disruption?
ISO 27001 Annex A 5.29 focuses on ensuring that information security is maintained at an appropriate level during disruption.
Organizations can experience many types of disruption, such as:
- Cyberattacks
- Ransomware
- Cloud-service outages
- Internet outages
- Data-center failures
- Power failures
- Natural disasters
- Fire or flooding
- Pandemic or health emergencies
- Loss of critical personnel
- Supplier failures
- Major software failures
- Hardware failures
- Denial-of-service attacks
During a disruption, an organization may be tempted to focus only on getting systems back online.
However, security controls should not simply be abandoned because the organization is operating under pressure.
Simple explanation
When normal operations are disrupted, the organization should continue protecting information and systems at an appropriate level while maintaining or restoring business operations.
For example, if a SaaS company experiences a major cloud outage, it should not respond by giving everyone administrator access simply because the business is under pressure.
Why is A.5.29 Important?
Security requirements do not disappear during an emergency.
In fact, disruption can create additional security risks.
For example:
- Emergency access may bypass normal approvals.
- Employees may use personal devices.
- Backup systems may be accessed.
- Temporary systems may be poorly secured.
- Security monitoring may be reduced.
- Staff may share credentials to work faster.
- Vendors may be given emergency access.
- Normal change-control procedures may be bypassed.
This means that disruption can create an environment where security controls are weakened exactly when the organization is most vulnerable.
Simple principle
Keep security operating during the crisis—not just before and after it.
What Does A.5.29 Require?
The organization should determine how information security will be maintained during disruptive situations.
This should be integrated with the organization’s:
- Business continuity plans
- Disaster recovery plans
- Incident response plans
- Crisis management procedures
- Backup and recovery procedures
- Emergency access procedures
The organization should identify:
- Critical information
- Critical systems
- Security requirements
- Minimum acceptable security controls
- Emergency procedures
- Roles and responsibilities
- Communication methods
- Alternative operating arrangements
- Recovery priorities
The approach should be proportionate to the organization’s risks and business requirements.
A.5.29 vs Business Continuity
A.5.29 is closely related to business continuity, but they are not exactly the same.
Business continuity asks:
Can the organization continue or recover its important business activities?
A.5.29 asks:
How will information security be maintained while the organization is operating during disruption?
For example:
A company may have a disaster recovery plan to restore its customer application.
A.5.29 also requires consideration of:
- Who can access the recovery environment?
- Are emergency credentials protected?
- Are recovery systems securely configured?
- Are logs available?
- Is sensitive information protected?
- Are temporary changes documented?
- Are emergency privileges removed after recovery?
Information Security During Different Types of Disruption
1. Cybersecurity Incident
Example:
Ransomware affects employee endpoints.
Security priorities may include:
- Isolating affected systems
- Protecting backups
- Restricting access
- Preserving evidence
- Maintaining critical services securely
- Monitoring for further compromise
2. Cloud Outage
Example:
Primary cloud region becomes unavailable.
Security considerations may include:
- Secure failover
- Authentication
- Encryption
- Backup environment security
- Emergency access
- Logging
- Data integrity
3. Office Unavailable
Example:
Office building becomes inaccessible.
The organization may move to remote working.
Security considerations include:
- Secure remote access
- MFA
- Device security
- VPN or zero-trust controls
- Secure communication
- Protection of confidential information
4. Critical Personnel Unavailable
Example:
The only cloud administrator is unavailable during a major outage.
The organization should have:
- Backup personnel
- Emergency access procedures
- Documented responsibilities
- Secure privileged access
- Escalation procedures
5. Supplier Disruption
Example:
Critical SaaS provider experiences a prolonged outage.
The organization should consider:
- Alternative suppliers
- Backup processes
- Secure data recovery
- Temporary workarounds
- Access controls
- Data integrity
Activities Required to Implement A.5.29
1. Identify Critical Business Services
Determine which business services must continue during disruption.
Examples:
- Customer application
- Payment processing
- Authentication
- Customer support
- Production infrastructure
- Communication
- Backup systems
Then determine the security requirements for those services.
2. Identify Critical Information Assets
Determine which information must remain protected during disruption.
Examples:
- Customer data
- Personal information
- Financial information
- Source code
- Credentials
- Intellectual property
- Contracts
- Security logs
- Backup data
3. Define Minimum Security Requirements
During disruption, not every normal process may be possible.
The organization should therefore define which security controls are non-negotiable.
For example:
| Security Control | During Disruption |
|---|---|
| MFA | Must remain enabled |
| Encryption | Must remain enabled |
| Privileged access | Restricted |
| Logging | Maintained where technically possible |
| Backup protection | Maintained |
| Access approval | Emergency process |
| Change management | Emergency process |
| Security monitoring | Maintained at appropriate level |
This creates a practical minimum security baseline for emergency operations.
4. Define Emergency Access
Disruptions may require access that would not normally be granted.
For example:
A production engineer may need temporary administrator access to restore a critical service.
The organization should define:
- Who can authorize emergency access
- How access is granted
- How long it remains active
- What activities are logged
- How access is reviewed afterward
- How access is revoked
Simple principle
Emergency access should be controlled, not unlimited.
5. Maintain Authentication and Access Controls
During a crisis, organizations should avoid practices such as:
- Sharing administrator passwords
- Creating uncontrolled accounts
- Disabling MFA without justification
- Giving everyone administrator access
- Using personal accounts for production systems
Emergency procedures should preserve appropriate identity and access controls.
6. Protect Backups
Backups are particularly important during disruption.
The organization should ensure that backups are:
- Available
- Protected
- Appropriately segregated
- Access-controlled
- Tested
- Protected against unauthorized modification or deletion
This is especially important during ransomware incidents.
A backup that is connected to the compromised environment and can easily be deleted may not provide reliable recovery.
7. Maintain Security Monitoring
Security monitoring should continue at an appropriate level during disruption.
Examples:
- Authentication monitoring
- Cloud activity monitoring
- Endpoint monitoring
- Network monitoring
- Critical application monitoring
- Security alerts
If normal monitoring becomes unavailable, the organization should define alternative arrangements.
8. Secure Alternative Working Arrangements
If employees need to work from another location, the organization should consider:
- MFA
- Secure devices
- Endpoint protection
- Secure remote access
- Encryption
- Access controls
- Data protection
- Secure communication
- Physical security
For startups, this is particularly important because many organizations operate with distributed or remote teams.
9. Define Alternative Communication Channels
During a major disruption, normal communication systems may be unavailable.
The organization should consider alternative methods for communicating with:
- Employees
- Customers
- Suppliers
- Management
- Incident-response teams
- Regulators where applicable
Communication channels should themselves be appropriately protected.
10. Define Emergency Change Management
During disruption, changes may need to be implemented quickly.
For example:
A production server needs an emergency configuration change to restore service.
Normal change-management approval may not be practical.
However, emergency change management should still include:
- Authorization
- Documentation
- Testing where possible
- Risk consideration
- Logging
- Post-implementation review
This is closely related to A.8.32 – Change Management.
11. Maintain Supplier Security During Disruption
Critical suppliers may be required during recovery.
Examples:
- Cloud provider
- Managed security provider
- Internet provider
- Backup provider
- Payment processor
- DNS/CDN provider
The organization should understand:
- Who to contact
- What emergency support is available
- What security requirements apply
- What information may be shared
- How supplier access is controlled
12. Define Recovery Priorities
Not every system needs to be restored at the same time.
For example:
Priority 1
Customer-facing production system
Priority 2
Authentication infrastructure
Priority 3
Critical databases
Priority 4
Internal collaboration systems
Priority 5
Non-critical applications
Security requirements should be considered at each recovery stage.
Startup Example – Major Cloud Disruption
Consider a SaaS startup running its production environment on AWS.
A major infrastructure problem makes the primary production environment unavailable.
The company activates its business continuity and disaster recovery procedures.
Without A.5.29
The team may:
- Share administrator credentials
- Disable MFA
- Give multiple developers unrestricted access
- Deploy untested changes
- Use temporary storage without encryption
- Forget to enable logging
- Ignore security monitoring
The business may recover, but security risk may increase significantly.
With A.5.29
The startup:
- Activates the disaster recovery plan
- Identifies critical services
- Activates the approved recovery environment
- Uses controlled emergency access
- Maintains MFA
- Preserves logging
- Restricts privileged access
- Documents emergency changes
- Monitors the recovery environment
- Verifies data integrity
- Reviews emergency access after recovery
- Removes temporary access
This allows the organization to maintain security while restoring business operations.
Startup-Focused Quick Summary
For a startup, A.5.29 can be implemented through a simple principle:
When normal operations stop, security controls should not stop with them.
Define:
Critical Systems
What must remain available?
Critical Information
What must remain protected?
Minimum Security Controls
What security controls must continue?
Emergency Access
Who can get emergency access?
Emergency Changes
How are urgent changes approved and recorded?
Monitoring
How will security events be detected?
Recovery
How will secure operations be restored?
Minimum Security Baseline During Disruption
A startup can document a simple baseline:
| Security Area | Minimum Requirement During Disruption |
|---|---|
| Authentication | MFA maintained where technically possible |
| Privileged Access | Restricted and monitored |
| Encryption | Maintained |
| Logging | Critical security logging maintained |
| Backups | Protected from unauthorized modification/deletion |
| Emergency Access | Time-limited and authorized |
| Change Management | Emergency process followed |
| Monitoring | Critical systems monitored |
| Data Protection | Sensitive information protected |
| Third Parties | Emergency access controlled |
| Recovery | Security validation before return to normal |
Disruption Security Checklist
| Activity | Completed? |
|---|---|
| Critical business services identified | ☐ |
| Critical information identified | ☐ |
| Minimum security requirements defined | ☐ |
| Business continuity plan reviewed | ☐ |
| Disaster recovery plan reviewed | ☐ |
| Emergency access procedure defined | ☐ |
| Emergency credentials protected | ☐ |
| Backup protection verified | ☐ |
| Recovery environment secured | ☐ |
| Security monitoring considered | ☐ |
| Alternative communication defined | ☐ |
| Emergency change process defined | ☐ |
| Supplier contacts identified | ☐ |
| Recovery priorities defined | ☐ |
| Post-disruption security review defined | ☐ |
Audit Evidence for A.5.29
An auditor may look for evidence that information security has been considered during business disruption.
Useful evidence includes:
Business Continuity
- Business Continuity Plan
- Business Impact Analysis
- Disaster Recovery Plan
- Recovery procedures
- Business continuity testing records
Security
- Information security requirements for continuity
- Emergency access procedure
- Emergency change procedure
- Security recovery checklist
- Recovery environment security configuration
Technical Evidence
- Backup configuration
- Backup testing records
- Recovery testing
- Monitoring configuration
- Authentication controls
- Access logs
Testing
- Disaster recovery exercises
- Tabletop exercises
- Business continuity tests
- Failover tests
- Lessons learned
- Corrective actions
Supplier Management
- Critical supplier contacts
- Supplier continuity information
- Cloud recovery documentation
- Supplier DR/BC assurance
Audit Checklist – ISO 27001 A.5.29
An auditor may ask:
Planning
- How do you maintain information security during disruption?
- Which business services are critical?
- Which information assets are critical?
- What security requirements must continue?
Emergency Access
- How is emergency access granted?
- Who can authorize it?
- Is it logged?
- Is temporary access removed afterward?
Recovery
- Are recovery environments protected?
- Are backups protected?
- How do you verify data integrity?
- How do you ensure restored systems are secure?
Change Management
- How are emergency changes managed?
- Are emergency changes documented?
- Are they reviewed afterward?
Monitoring
- How do you maintain security monitoring during disruption?
- What happens if your primary monitoring platform becomes unavailable?
Testing
- Have you tested your continuity and recovery arrangements?
- What did you learn from the last test?
- Were corrective actions completed?
Common Mistakes
1. Treating Business Continuity as Only an Availability Problem
Organizations sometimes focus entirely on:
“How quickly can we restore the system?”
But they also need to ask:
“How do we restore it securely?”
2. Disabling Security Controls During an Emergency
Examples:
- Disabling MFA
- Sharing passwords
- Giving everyone administrator access
- Disabling logging
Emergency conditions should not automatically become an excuse for uncontrolled access.
3. No Emergency Access Procedure
A crisis occurs and nobody knows:
- Who can authorize access
- How access should be granted
- How it should be monitored
- When it should be removed
4. Ignoring Backup Security
Backups may themselves be targeted during ransomware or other attacks.
5. No Recovery Environment Security Review
A disaster recovery environment may be less secure than the production environment.
Organizations should not assume that “backup” automatically means “secure.”
6. No Emergency Change Documentation
Teams sometimes make many urgent production changes and document them later—or never.
Emergency changes should still be traceable.
7. Forgetting Temporary Access
Temporary administrator access can become permanent if nobody reviews it after the incident.
8. Ignoring Suppliers
A startup may depend on a cloud provider, payment provider, DNS provider, or other critical supplier.
Their disruption can affect both business operations and information security.
Practical Startup Implementation Model
A startup can implement A.5.29 using eight steps:
1. Identify
Identify critical services, systems, and information.
↓
2. Assess
Determine what security risks exist during disruption.
↓
3. Define
Define minimum security requirements.
↓
4. Prepare
Prepare emergency access, communication, backup, and recovery arrangements.
↓
5. Operate
Maintain appropriate security controls during disruption.
↓
6. Monitor
Monitor critical systems and activities.
↓
7. Recover
Restore normal operations securely.
↓
8. Review
Review what happened and improve the continuity process.
Startup model
Identify → Assess → Define → Prepare → Operate → Monitor → Recover → Review
Policy vs. Process vs. Evidence
| Type | Example |
|---|---|
| Policy | Business Continuity & Information Security Policy |
| Process | Information Security During Disruption Procedure |
| Plan | Business Continuity Plan |
| Plan | Disaster Recovery Plan |
| Procedure | Emergency Access Procedure |
| Procedure | Emergency Change Procedure |
| Evidence | DR test results |
| Evidence | Emergency access records |
| Evidence | Recovery exercise report |
| Improvement | Post-disruption corrective actions |
A startup does not necessarily need separate documents for every item.
A practical structure can be:
Business Continuity Policy
↓
Business Continuity & Disaster Recovery Plan
↓
Security During Disruption Procedure
↓
Emergency Access / Change Procedures
↓
Testing & Actual Disruption Records
Relationship with Other ISO 27001 Controls
A.5.29 is closely connected with business continuity, incident management, access control, backup, and recovery controls.
| Control | Relationship |
|---|---|
| A.5.24 | Incident-management preparation |
| A.5.26 | Incident response |
| A.5.27 | Learning from incidents |
| A.5.29 | Maintaining information security during disruption |
| A.5.30 | ICT readiness for business continuity |
| A.5.23 | Cloud security can affect continuity and recovery |
| A.5.19–A.5.22 | Supplier security and supplier continuity |
| A.5.15–A.5.18 | Access and identity controls during emergency operations |
| A.8.13 | Backup |
| A.8.14 | Redundancy of information-processing facilities |
| A.8.32 | Emergency changes must remain controlled |
Important distinction: A.5.29 vs A.5.30
A.5.29 – Information Security During Disruption
Focuses on:
Maintaining information security while the organization is experiencing disruption.
A.5.30 – ICT Readiness for Business Continuity
Focuses more specifically on:
Ensuring ICT capabilities are planned and ready to support business continuity objectives.
Together:
Business Continuity Requirements
↓
ICT Readiness
↓
Secure Disruption Operations
↓
Secure Recovery
Useful Documents for A.5.29
- Business Continuity & Information Security Policy
[Insert Draft Document Link] - Information Security During Disruption Procedure
[Insert Draft Document Link] - Business Continuity Plan
[Insert Draft Document Link] - Disaster Recovery Plan
[Insert Draft Document Link] - Emergency Access Procedure
[Insert Draft Document Link] - Emergency Change Procedure
[Insert Draft Document Link] - Business Continuity Testing Checklist
[Insert Draft Document Link] - Disaster Recovery Test Report
[Insert Draft Document Link]
Questions an Auditor May Ask
An auditor may ask:
“What happens to your information security controls when your normal business operations are disrupted?”
The organization should be able to explain:
- Critical systems
- Critical information
- Minimum security requirements
- Emergency access
- Backup arrangements
- Recovery procedures
- Monitoring
- Emergency changes
- Supplier coordination
The auditor may then ask:
“Show me evidence that these arrangements have been tested.”
Useful evidence could include:
- Tabletop exercises
- Disaster recovery tests
- Failover tests
- Backup restoration tests
- Emergency access tests
- Corrective action records
Startup-Focused Final Takeaway
ISO 27001 Annex A 5.29 is about ensuring that information security remains effective during periods of disruption.
A disruption is precisely when an organization may be tempted to bypass normal security controls.
A mature organization prepares for this in advance.
The startup should know:
- What must continue
- What must remain protected
- Which security controls are mandatory
- Who can obtain emergency access
- How emergency changes are controlled
- How backups and recovery systems are protected
- How security monitoring will continue
- How secure operations will be restored
In one sentence:
A.5.29 ensures that information security is maintained at an appropriate level when normal business operations are disrupted, rather than allowing emergency conditions to create uncontrolled security weaknesses.
The practical sequence
Identify → Assess → Define → Prepare → Operate → Monitor → Recover → Review
For startups, the key lesson is simple:
Business continuity should not mean “keep the business running at any cost.” It should mean “keep critical business operations running while protecting information and systems at an appropriate security level.”