Control Definition
The organization must plan how it will keep information security at an appropriate level while business is disrupted — deciding in advance which protections continue through a crisis, what compensating measures apply where normal controls cannot operate, and how full control coverage is verified back into place once operations return to normal.
Control Objective
To prevent a business disruption from turning into a security breach by protecting information and associated assets throughout the disruption and the recovery that follows.
What This Really Means
Attackers read the news too. A flood, a ransomware outage, a failed data center, a regional power crisis — every disruption degrades two things at once: your controls and your attention. Fraudsters time payment-diversion attempts to known outages, phishing campaigns dress themselves in your incident's clothing, and inside the organization people start bypassing approvals "just this once, to keep things running". A.5.29 makes one statement: security is not among the things you are permitted to lose in a disaster. Which protections hold, which may bend, and how everything snaps back — all of it gets planned while the sky is clear.
Concretely, the control asks you to determine the security requirements that apply in adverse situations and write them into the business continuity and disaster recovery plans themselves. Which controls must hold no matter what: access control (failover must not mean a shared admin password on a whiteboard), logging and monitoring (the SIEM has to see the DR environment, because if logging goes dark during the disruption you lose the record covering exactly the window any investigation will care about), physical security during evacuation and site loss (equipment and documents in a damaged or unstaffed building, media in transit during relocation), and data protection in degraded modes (the failover environment enforces the same classification handling and encryption as the systems it replaces).
The control is realistic about crisis operation: not every peacetime control survives every scenario, and the discipline is degrading deliberately instead of accidentally. Define in advance which controls may relax, under whose authority, with what compensating measures, and for how long — an exception with an owner and an expiry, recorded in a register, not a free-for-all. Break-glass accounts with sealed credentials and mandatory post-use review are the canonical example: emergency access exists, but it is designed, logged, and closed. The alternative — improvised relaxation by whoever is on shift — is how "temporary" shared accounts survive for months after the crisis ends.
Restoration is the half most organizations forget, and auditors do not. When normal service resumes, security gets verified back: exceptions closed, break-glass credentials rotated, emergency firewall rules removed, the disruption window's logs reviewed for anything that rode in on the chaos. What auditors treat as the heart of A.5.29 is two artifacts: continuity plans that contain explicit security requirements rather than never mentioning the word, and exercise or real-disruption evidence showing security was tested and restored — not merely that services came back inside their recovery targets.
Why It Matters
Disruptions are a perfect storm for security: controls are degraded, staff are exhausted and improvising, normal approval chains are suspended in the name of speed, and adversaries deliberately exploit the moment. The patterns repeat across incidents — fraudulent payment-change requests timed to a publicized outage, intrusion attempts against hastily stood-up remote access, data walked out of an evacuated office — because a crisis is the best cover an attacker ever gets.
The quieter failure is that the degraded state becomes permanent. Emergency access granted during the crisis is never revoked; the temporary firewall rule outlives the incident by a year; the DR environment that was always the softer copy of production becomes a standing back door to the same data. And where logging lapsed during the event, the organization permanently loses the ability to reconstruct what happened in precisely the period that matters most.
Where security is not planned into disruption, organizations face:
- •Breaches riding on the crisis – attackers time fraud and intrusion to failover windows, when monitoring is thinnest and approvals are being bypassed
- •The DR environment as a soft target – a failover site with weaker access control and no monitoring offers the same data at a fraction of the difficulty
- •"Temporary" exceptions that become permanent – emergency accounts, opened firewall rules, and disabled checks routinely outlive the disruption by months
- •A blind spot exactly where it hurts – if logging and monitoring lapse during the disruption, the window an investigation most needs is the one with no record
- •Two crises for the price of one – a security incident landing mid-disruption hits a team already exhausted, with degraded tooling and divided command
Regional Compliance Context
For BFSI organizations in India, this control is a supervisory expectation as much as an ISO one: RBI master directions expect regulated entities to preserve security and oversight when operating from DR, and SEBI's CSCRF carries comparable resilience expectations for market intermediaries. Two clocks also keep running through any disruption — CERT-In's 6-hour reporting window applies to reportable incidents even when they strike mid-crisis, and the 180-day log retention direction does not pause because primary systems failed over, which is an architectural argument for keeping logging alive in the DR environment. Where personal data is in scope, DPDP Act 2023 breach duties likewise run on their own timetable regardless of what else is burning.
Implementation Guidance
Derive Security Requirements for Disruption Scenarios
Work from your risk assessment and business impact analysis: for each plausible disruption — site loss, ransomware, utility failure, supplier collapse, pandemic-style remote shift — determine what protection the information still requires. Classification does not change because the building flooded; what changes is how confidentiality, integrity, and availability get maintained. Record the requirements per scenario so they can be designed into the plans rather than recalled under stress.
Write Security into the BC and DR Plans Themselves
Add explicit security sections to each continuity and recovery plan: access control during failover, logging and monitoring continuity, physical security on evacuation, and secure communication channels for the response. Make security sign-off a mandatory approval step for plan changes. A separate security annex nobody opens mid-crisis is the anti-pattern — the requirements live where the responders will actually be reading.
Define Degraded Modes, Exception Authority, and Expiry
Decide in advance which controls may relax in which scenarios, what compensates, who is authorized to approve the relaxation, and when it expires. Record every emergency exception in a register at the moment it is granted. Design break-glass access properly: sealed credentials, alerting on use, and a mandatory post-use review. Deliberate degradation is acceptable; improvised degradation is the finding.
Hold the Failover Environment to Production Standard
The DR site, standby region, or recovery environment inherits the production security baseline: the same hardening, access tiers, MFA, encryption, and endpoint protection. Include DR assets in vulnerability management, patch cycles, and quarterly access reviews — the standby estate is the most commonly forgotten scope in audits, and it holds the same data as production.
Keep Logging and Monitoring Alive Through the Event
Extend SIEM coverage to failover infrastructure before it is ever used, buffer log forwarding so a failover does not silently drop events, and stage an out-of-band alerting path for scenarios where the primary monitoring stack is itself down. Where emergency actions must be manual, assign a scribe — a contemporaneous record of what was changed during the disruption is what the restoration review and any investigation will stand on.
Plan Physical Security for Evacuation and Site Loss
Define what happens to equipment and media when a site is evacuated or damaged: secure or remove portable media where time safely allows, control access to a building that is unstaffed or full of repair contractors, supervise equipment relocations with documented handling, and keep CCTV and alarms running on backup power. People come first in every evacuation — which is exactly why asset handling must be decided beforehand, not during.
Test Security in Every BC Exercise and Verify Restoration After
Give every continuity exercise explicit security objectives: confirm responders can reach what they need and nothing more, verify logs are flowing from the recovery environment, and execute the break-glass procedure as designed. After real disruptions, run a restoration checklist — close exceptions, rotate emergency credentials, remove temporary rules, review the disruption window's logs — and feed every gap into corrective action with an owner and a date.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.29:
Documentation
- Business continuity and DR plans containing explicit information security requirements, with security sign-off on plan changes
- Degraded-mode or emergency exception procedure defining what may relax, authorization levels, compensating controls, and expiry
- BC/DR exercise reports that include security objectives, with the findings and corrective actions they produced
- Break-glass account procedure with sealed-credential handling, use alerts, and post-use review records
- Post-disruption restoration checklists or records showing exceptions closed, credentials rotated, and control coverage verified
Interviews
- BC manager or CISO on how security requirements entered the continuity plans and who may authorize relaxing a control mid-crisis
- IT or platform engineers on access control, encryption, and logging in the failover environment compared with production
- Facilities or site leads on physical security arrangements during an evacuation or extended site loss
Observations
- Configuration of the DR environment inspected against the production baseline — access tiers, MFA, encryption, monitoring agents
- SIEM or monitoring coverage of failover infrastructure demonstrated live
- A sampled BC exercise traced through its security objectives, results, and the closure of resulting actions
Practitioner Insights
My first test of this control takes thirty seconds: I open the business continuity plan and search for security content — who may relax a control, what happens to logging in failover, how access is governed at the recovery site. In a striking number of organizations the answer is nothing; the plan was written by operations for availability, and security appears nowhere in it. The second question is sharper: during your last disruption or DR test, who authorized the exceptions, and where is the record showing they were closed? Exceptions need an owner, an expiry, and a review — "whoever was on shift opened a firewall rule" is the finding writing itself.
The gap I find most often is not the plan — it is the DR environment itself. Production has MFA, hardening, EDR, and SIEM agents; the standby copy stood up two years ago has a shared admin login and no monitoring, and it holds exactly the same data. The fix is one line in each procedure: put DR assets into the same access reviews, patch cycles, and scanning scope as production. And after any real outage, actually walk the restoration checklist — in most organizations I look at, the emergency account created during the last incident is still active, still shared, and officially remembered by nobody.
Common Challenges & Solutions
Challenge
Continuity plans are written entirely by operations and contain no security content at all.
Solution
Run a joint review and add explicit security sections to each plan: access during failover, logging continuity, physical security on evacuation, secure communications for the response team. Then make security sign-off a mandatory approval step for BC/DR plan changes, so the content cannot silently disappear in the next revision.
Challenge
Emergency exceptions — shared accounts, opened firewall rules, disabled MFA — quietly outlive the disruption.
Solution
Record every relaxation in an exception register at the moment it is granted, with an owner, a compensating control, and an expiry date. Make the post-disruption restoration checklist a formal closure step for the continuity event, and have internal audit sample old exceptions periodically — a register only works if someone checks it.
Challenge
The failover environment drifts ever further below the production security baseline.
Solution
Build both estates from the same hardened images or infrastructure-as-code so drift requires effort instead of neglect. Include DR assets in vulnerability scanning, patching, and quarterly access reviews, and run a periodic configuration comparison between the two environments with findings tracked to closure.
Challenge
Monitoring and logging go dark at exactly the moment everything else is going wrong.
Solution
Deploy monitoring agents and log forwarding to DR infrastructure before it is ever activated, buffer log shipping so failover does not drop events, and stage out-of-band alerting for when the primary monitoring stack is itself disrupted. Assign a scribe for manual emergency actions — if the tooling cannot record the window, a person must.
Challenge
Continuity exercises measure whether services came back in time, and never whether security held.
Solution
Write security objectives into every exercise scenario: attempt access that should be denied, confirm logs are flowing from the recovery environment, execute the break-glass procedure end to end. Add a security observer to the exercise team and report security findings alongside recovery-time results, so they receive the same management attention and corrective-action treatment.
