ISO 27001 control 5.29: information security during disruption

When primary systems fail and teams scramble to restore operations, security controls are often the first casualty. Recovery speed becomes the singular focus, and the safeguards that protect data confidentiality and integrity get disabled, bypassed, or forgotten entirely. ISO 27001 control 5.29 exists because of this recurring failure. Organizations that invest heavily in security under normal conditions routinely abandon those protections the moment disruption hits, creating exactly the kind of exposure window that attackers are waiting for.

What 5.29 requires

ISO 27001 Annex A control 5.29 requires organizations to plan, implement, and maintain processes that ensure information security controls remain effective during periods of business disruption. The official objective directs organizations to develop and maintain plans so that security controls continue to operate effectively, or are adequately compensated for, when normal operations are interrupted by disaster recovery efforts, system outages, or crisis scenarios.

The critical distinction here is integration. Business Continuity Planning (BCP) and Disaster Recovery (DR) plans cannot treat security as a separate workstream that gets addressed after availability is restored. Control 5.29 requires security to be embedded directly into continuity and recovery plans from the outset. Every failover procedure, every backup restoration process, and every emergency access protocol needs corresponding security controls documented alongside it. This means the security team must be an active participant in BCP/DR planning, not a reviewer who signs off after the fact.

Most BCP frameworks focus heavily on availability. They measure Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs), testing whether systems can come back online within acceptable windows. Control 5.29 forces equal attention on confidentiality and integrity during those recovery windows. Compensating controls for degraded environments must be pre-approved and documented before a crisis occurs, not invented under pressure during an active incident. If a production environment uses multi-factor authentication and role-based access control, the DR environment must either replicate those controls or have a formally accepted alternative that maintains an equivalent level of protection.

Why 5.29 matters

During a DR failover, the pressure to restore services creates conditions where security shortcuts become the path of least resistance. Teams disable Multi-Factor Authentication (MFA) to speed up access provisioning. Log collection stops because the secondary environment wasn’t configured for it. Broad administrative access gets granted to accelerate recovery, with the intention of revoking it “once things settle down.” These decisions, each individually defensible under pressure, collectively create a security posture that would never pass review under normal operations.

Disruptions create a window where the oversight mechanisms that normally catch risky behavior are at their weakest. Change management processes get bypassed. Approval workflows are suspended. The people who would normally review access requests or audit configuration changes are consumed by the recovery effort itself. Security Operations Center (SOC) teams may be operating from backup facilities with limited tooling, reduced staffing, or degraded monitoring capabilities. This isn’t a theoretical concern; it’s the operational reality of every major outage, migration failure, or disaster event.

Sophisticated threat actors understand this dynamic and deliberately time campaigns to coincide with known disruption windows. Ransomware operators frequently deploy payloads during weekends, holidays, or periods of known organizational change because they know that detection capabilities and response capacity are degraded. Advanced Persistent Threat (APT) groups have been observed staging attacks to coincide with publicized IT migrations, mergers, or infrastructure transitions where security teams are stretched thin and attention is divided.

What attackers exploit

• Disabled or bypassed access controls during failover, where emergency access policies override normal authentication requirements and privilege boundaries collapse
• Unencrypted data on backup and recovery systems that weren’t configured with the same data protection standards as production environments
• Missing audit logs in secondary environments, eliminating the forensic trail needed to detect and investigate unauthorized activity during or after the disruption
• Temporary admin access that becomes permanent because no one tracks the revocation timeline once the immediate crisis passes and operational priorities shift
• Unpatched or outdated DR environments that haven’t received the same vulnerability management attention as production systems, leaving known exploits available
• Social engineering targeting staff during chaotic recovery periods, when verification processes break down and urgency overrides the caution that would normally prevent unauthorized actions
• Unsecured communication channels used during incident response, including personal devices, unencrypted messaging apps, and ad hoc file sharing that bypass data loss prevention controls

How to implement 5.29

Implementing control 5.29 requires weaving security requirements into every layer of business continuity and disaster recovery planning. The goal is to ensure that no recovery action degrades security posture below a formally accepted threshold, and that every deviation from normal security operations is planned, time-limited, and documented.

For your organization (first-party)

Effective implementation follows a structured approach across eight areas:

1. Conduct an information security Business Impact Analysis (BIA). Go beyond traditional availability-focused BIA by assessing the confidentiality and integrity impacts of disruption scenarios. Identify which security controls are critical to maintaining data protection during degraded operations and map the dependencies between business processes and their security requirements. This analysis should categorize controls into three tiers: those that must remain fully operational during disruption, those that can operate in a degraded mode with compensating controls, and those that can be temporarily suspended with formal risk acceptance.
2. Integrate security requirements into BCP/DR plans. Every recovery procedure should include explicit security steps. If the DR plan describes how to fail over a database, the corresponding security requirements for access control, encryption, and audit logging in the failover environment must be documented alongside it. Use a control mapping matrix that pairs each production security control with its DR equivalent, identifying any gaps that require compensating measures.
3. Define “degraded mode” security protocols. Not every production security control will be available during disruption. Formally document which controls may be temporarily reduced, what compensating measures apply, the maximum acceptable duration of degraded operation, and the criteria that trigger a return to full security posture. This documentation should include explicit risk acceptance sign-off from the Chief Information Security Officer (CISO) or equivalent authority.
4. Provision redundant security infrastructure. Security Information and Event Management (SIEM) collection, identity providers, certificate authorities, and key management systems need the same redundancy planning as the business applications they protect. If the primary SIEM goes down with the data center, security monitoring shouldn’t go dark. Consider geographic separation of security infrastructure so that a regional disruption doesn’t eliminate both production and security monitoring simultaneously.
5. Establish break-glass Identity and Access Management (IAM) procedures. Pre-define emergency access accounts with documented scope, approval chains, automatic expiration timers, and mandatory post-use audit requirements. These accounts should exist before a crisis, not be created during one. Store break-glass credentials in a secure, offline-accessible vault (such as hardware security modules or sealed envelopes in a physical safe) that remains available even when identity systems are down.
6. Implement immutable backups. Backup integrity is a prerequisite for security during recovery. Immutable, air-gapped, or write-once backup strategies following the 3-2-1-1-0 rule (three copies, two media types, one offsite, one immutable, zero errors) ensure that backup data cannot be modified or encrypted by ransomware, even if the production environment is fully compromised. Regularly validate backup encryption and verify that decryption keys are accessible through a separate key management path.
7. Test regularly. Annual DR simulations must explicitly validate security controls, not just application availability. Test whether MFA works in the failover environment, whether logs are collected and forwarded correctly, whether break-glass accounts expire as designed, and whether encryption is maintained across backup restoration. Document the results and track remediation of any identified gaps to closure.
8. Conduct post-incident reviews. Every disruption event, whether real or simulated, should feed back into plan updates. Evaluate whether security controls performed as expected, document any unanticipated security impacts, and update plans accordingly. This connects directly to control 5.27, which requires learning from information security incidents and applying those lessons to strengthen future preparedness.

Common mistakes to avoid:

• Treating BCP and security as separate workstreams managed by different teams with no shared planning sessions or integrated testing schedules
• Never testing whether security controls actually survive failover in the DR environment, relying instead on assumptions that “the same config” was applied
• Granting emergency access without defined revocation procedures, expiration timers, or post-event audit requirements
• Assuming that a cloud provider’s DR capabilities automatically preserve your security configuration, encryption keys, access policies, and monitoring integrations
• Storing DR plans exclusively on systems that become unavailable during the disruption they’re meant to address, such as internal wikis hosted on the affected infrastructure

For your vendors (third-party assessment)

When assessing vendor compliance with 5.29, focus on evidence that security is actively maintained during their disruption scenarios, not just that they have a BCP document on file.

Questionnaire questions to include:

• How are information security controls maintained during business continuity and disaster recovery operations?
• What compensating controls are in place when primary security mechanisms are unavailable during failover?
• How frequently do you test security control effectiveness within DR environments, and what is the scope of those tests?
• What is your process for revoking emergency access privileges after a disruption event concludes?
• How do you ensure audit logging continues in backup and recovery environments?

Evidence to request: BCP/DR plans with embedded security requirements, most recent DR test report showing security control validation, break-glass IAM procedure documentation, post-disruption review reports with security findings, and backup encryption configuration evidence.

Red flags during assessment:

• BCP documentation that makes no mention of information security controls or treats security as a post-recovery activity
• DR test reports that only validate availability metrics (RTO/RPO achievement) without security verification
• No defined process for emergency access revocation or expiration
• DR environments that are significantly behind production on patching, configuration, or security tooling
• Inability to produce post-disruption review documentation or evidence of lessons learned

Verification methods: Request the most recent DR test report and confirm that security controls were explicitly part of the test scope. Ask for evidence of post-disruption reviews that include security findings and tracked remediation actions. Compare the vendor’s production security architecture documentation against their DR environment documentation to identify gaps.

Audit evidence for 5.29

Auditors assessing control 5.29 will look for documented evidence that security is integrated into business continuity planning, tested regularly, and improved through post-disruption reviews. For a broader view of what to expect during an ISO 27001 audit, preparation should begin well before the assessor arrives. The following artifacts form a comprehensive evidence package that demonstrates ongoing compliance.

Cross-framework mapping

Control 5.29 aligns with continuity and resilience requirements across multiple regulatory frameworks. Organizations pursuing multi-framework compliance can leverage their 5.29 implementation to satisfy overlapping requirements, reducing duplicate effort across audit preparation.

Related ISO 27001 controls

Control 5.29 operates within a cluster of incident management and continuity controls in Annex A. Understanding these relationships helps organizations build a cohesive implementation rather than addressing each control in isolation.

Frequently asked questions

What is ISO 27001 5.29?

ISO 27001 control 5.29 requires organizations to maintain information security controls during periods of business disruption. It ensures that security protections for confidentiality, integrity, and availability don’t get bypassed or disabled when teams are focused on disaster recovery and service restoration.

What happens if 5.29 is not implemented?

Without 5.29, disruption events become security events. Emergency access persists beyond the crisis, audit trails go missing, and attackers exploit the gap between when normal controls are suspended and when they’re restored. Organizations also face nonconformity findings during ISO 27001 certification audits, which can delay or jeopardize certification.

How do you audit 5.29?

Auditors review BCP and DR documentation for embedded security requirements, examine test records to confirm security controls were validated during DR exercises, and check for post-disruption review reports. They verify that compensating controls are documented, that break-glass procedures include defined revocation processes, and that lessons learned feed back into plan updates.

How UpGuard helps

The UpGuard platform delivers the persistent oversight that control 5.29 demands, even when primary operations are disrupted.

• Breach Risk: Continuously monitors your external attack surface for configuration drift, exposed assets, and security posture changes that could go undetected during a disruption event.
• Vendor Risk: Provides real-time visibility into your vendor ecosystem’s security posture, so you can verify that third-party BCP/DR commitments translate into maintained security controls during their disruption scenarios.

Rather than discovering security gaps after a disruption event, UpGuard surfaces exposure changes and vendor risk shifts continuously, so your team maintains awareness before, during, and after any operational interruption.

Learn more about the UpGuard platform