A.5.29
Information security during disruption
Organizational controlsCheckpoints 6Evidence 6Cases 6
Control objective
This control requires the organization to plan in advance so that its information security level is not inappropriately degraded while normal operations are disrupted or switched to alternative arrangements due to a disaster, crisis, or major incident. During a crisis, the pressure to recover quickly often weakens security controls through relaxed access controls, temporary workarounds, or use of less-hardened alternative environments. The aim is to keep confidentiality, integrity, and availability at an appropriate level throughout the disruption and to restore controls to their normal state once operations return to normal. Unlike A.5.30 (ICT readiness for business continuity), which addresses technical recovery capability, this control focuses on sustaining and restoring security controls across the whole disruption period.
Key checkpoints
- Are information security requirements embedded in the business continuity/disaster recovery framework, defining the security level to be maintained during disruption?
- Does the alternative site/emergency environment meet an approved security baseline reflecting risks and obligations, with compensating controls for differences from normal operation?
- Are approval, usage recording, and revocation procedures in place for emergency/temporary privileges granted during a crisis?
- Are security roles, responsibilities, and decision authority assigned for disruption, and is an emergency contact scheme maintained?
- Is there a procedure to reverse temporary measures/workarounds introduced during disruption and re-establish security controls upon return to normal?
- Are the related plans validated through testing/exercises, with results fed back into improvement?
Implementation guidance
- Integrate information security requirements into the business continuity plan (BCP)/disaster recovery plan (DRP) and define the minimum security control baseline to maintain for each type of disruption.
- Design access control, encryption, backup, and logging appropriate to each alternative mode, including alternate sites, cloud failover, or manual work. Where normal controls cannot be maintained, define risks, compensating controls, approvers, duration, and restoration conditions.
- Define a break-glass emergency access procedure that specifies the approval path, usage logging, post-event review, and automatic/manual revocation.
- Document the security owner and roles (RACI), escalation paths, and internal/external communication criteria for disruption, and keep the emergency contact list current.
- Reflect obligations to maintain security and notification requirements during disruption in contracts with alternative-environment and service providers (A.5.19-A.5.22) and cloud services (A.5.23).
- Establish a return-to-normal procedure covering removal of temporary controls, data integrity verification, and access rights reset, and improve the plan periodically using exercise and real-incident results.
Evidence
- BCP/DRP with embedded information security requirements, and the minimum security control baseline per disruption type
- Security configuration records for the alternative site/emergency operating environment (access control, encryption, backup, logging settings)
- Break-glass emergency access procedure and approval/usage/revocation records
- Security roles and responsibilities (RACI), emergency contact list, and escalation scheme for disruption
- Return-to-normal procedure and records of temporary-control removal/restoration
- Exercise/test plans and result reports, and plan revision history
Nonconformity examples
- A BCP/DRP exists but does not embed information security requirements, so the security level to maintain during alternative operation is undefined.
- The alternative site fails to meet its approved emergency security baseline for access control, encryption, or logging, with no risk assessment or compensating controls.
- Emergency privileges granted during a crisis are neither logged nor revoked, so excessive privileges persist after return to normal.
- Temporary workarounds introduced during disruption are not reversed on return to normal and remain as vulnerabilities.
- The related plans are never validated through exercises, so whether security controls hold during an actual disruption cannot be confirmed.
- Contracts with alternative service/cloud providers omit obligations to maintain security and notification requirements during disruption, leaving responsibility unclear.