ISO 27001:2022 Annex A 5.29: information security during disruption

The enterprise due-diligence questionnaire arrives with one question you cannot answer cleanly: how does security hold up when your systems fail? Your continuity plan lists recovery times and failover steps, but says nothing about whether MFA, logging and encryption survive the outage. ISO 27001:2022 Annex A 5.29 information security during disruption is the control that closes that gap.

This guide is for operations directors, heads of IT and compliance leads at regulated and B2B SaaS firms with 25–250 staff. It covers what A.5.29 requires, where it ends and A.5.30 begins, how to build it into the continuity documents you already hold, and what auditors sample.

What does ISO 27001 Annex A 5.29 require?

Annex A 5.29 ISO 27001:2022 requires you to plan, ahead of any disruption, how information security keeps working when normal operations don't. That means deciding which controls must keep running and which pre-approved fallbacks replace those that can't. It also means planning how baselines return afterwards, all proven by testing rather than written down and shelved.

Continuity planning naturally obsesses over uptime. This control asks the harder question: does security survive the bad day too? It carries confidentiality, integrity and availability, but its weight sits on the first two, which must not be sacrificed while everyone chases the third.

A working answer has three parts:

• Controls that keep running. Decide in advance which security controls must operate through a disruption, such as access control, logging and encryption.
• Pre-approved fallbacks. For controls that cannot run, agree a risk-assessed compensating measure in writing, so responders choose from a list instead of improvising.
• Return to baseline. Define how those measures stand down and configurations are restored once recovery completes.

All three live inside your business continuity process, not beside it. Most of the effort lands before anything breaks: degraded-mode baselines, compensating measures and control parity in standby environments.

Disruption covers more than a data-centre fire. A cloud region outage, a ransomware response that takes systems offline, a failed supplier and a lost office network each put a different control at risk. The impact analysis should name which security services each scenario touches.

The control does not ask you to keep every safeguard running at full strength. Some genuinely cannot run when an identity provider or a log pipeline fails. It asks that the substitute was chosen and approved on a calm day.

How does A.5.29 differ from A.5.30 and ISO 22301?

A.5.29 keeps confidentiality and integrity intact through a disruption, while Annex A 5.30 owns ICT readiness: restoring availability within recovery targets. ISO 22301 is the wider business continuity management standard covering the whole organisation. The two Annex A controls are tested together, but they answer different questions.

The boundaries in practice:

• A.5.29, protection during the event. Confidentiality and integrity hold while services are degraded.
• A.5.30, ICT readiness. Infrastructure and services return within agreed recovery targets, which is the availability side.
• ISO 22301, the wider discipline. A full business continuity management system that also covers people, premises, suppliers and communications. A.5.29 takes only the security slice.

Escalation into both typically arrives through incident response under Annex A 5.26. A security event is triaged there, and the moment it becomes a declared disruption, continuity arrangements take over.

Because the controls overlap in time, one exercise can test both. Run a single failover and ask two questions of it: did services return within target, and did access control, logging and encryption hold while they did?

A failover test that only measures uptime has tested half the control.

The practical test of the boundary is ownership. Give A.5.30 to whoever runs infrastructure and A.5.29 to whoever owns security, and have them sign the same exercise report.

Why do availability incidents turn into data breaches?

Because the fastest fixes under pressure are security shortcuts: MFA switched off, firewall rules loosened, an unpatched failover environment promoted to production. Attackers expect distracted engineers and unfamiliar defences. UK GDPR and, for financial entities, DORA both expect protection to hold through disruption, so "we were in DR mode" mitigates nothing.

The classic failure mode is self-inflicted. Nobody sets out to weaken a control. Someone does it to restore service faster, calls it temporary and moves on to the next fire.

Four shortcuts recur:

• MFA switched off because the identity provider is down or slowing the responders.
• Firewall rules loosened to get replication or remote access working.
• An unpatched failover environment promoted to production, carrying every vulnerability the primary no longer has.
• Change control bypassed so a fix can ship without review, leaving no record of what changed.

Each choice looks reasonable at 2am. The damage is that the relaxation outlives the incident, and an attacker only needs it to last a day.

The regulatory stakes make this a board matter. The ICO guidance on data security and business continuity expects continuity arrangements that set out how personal data is protected and recovered. It also expects you to restore access to that data in a timely manner after an incident, and to test those measures regularly.

For financial entities, DORA Article 11 response and recovery requirements go further. ICT business continuity plans must keep critical or important functions running. They must be tested at least yearly, including cyber attack scenarios and switchovers to backup capacity.

Underneath all of it sits one root cause: continuity framed as uptime. If the plan never mentions confidentiality or integrity, nobody has decided what protection looks like in degraded mode, so responders decide for themselves under pressure. The fix is to write that decision down before the outage.

How do you implement ISO 27001:2022 Annex A 5.29 information security during disruption?

Fold security into the continuity and DR documents you already hold rather than writing a standalone plan. Extend the business impact analysis to identity, logging and encryption, and write pre-approved degraded-mode rules for each. Then link the incident response plan to continuity and test the assertions in your annual failover exercise.

Work through these five steps in order, after your asset and risk work exists and alongside A.5.30:

1. Add security to the documents you hold. Give the existing continuity and DR plans a security section. A separate "security continuity plan" is one more standalone document, and integration is what the control actually asks for.
2. Extend the business impact analysis. The BIA ranks processes by how badly downtime hurts. Add security services to it: rank assets by data sensitivity and set recovery targets for identity, logging and encryption, not just customer-facing apps.
3. Write the degraded-mode rules. If the identity provider is down, which access process applies? If the SIEM feed drops, what monitoring stands in? Pre-approved compensating measures are the difference between a managed fallback and an improvised shortcut.
4. Link incident response to continuity. The NCSC cyber incident response planning guidance says an incident response plan should sit alongside inter-linked business continuity, disaster recovery and communications plans. In practice, name who can declare a disruption and which degraded-mode rules switch on when they do, so containment never strips out protection.
5. Test the security assertions. Inside the annual failover exercise you already run for A.5.30, check whether access control, logging and encryption held. Close the exercise with a written report listing actions, owners and dates.

A degraded-mode table needs only three columns: the control that failed, the approved substitute and the condition that ends it. For example, if the SIEM feed drops, the substitute might be a scheduled manual review of platform logs until the feed is confirmed healthy.

Larger organisations split out formal impact analyses and dedicated continuity strategies. At 25–250 staff that is overhead without benefit. A few pages of security content in the DR plan, one table of degraded-mode rules and an extra line in the exercise script are enough. That satisfies both auditors and enterprise customers.

How do you keep standby environments and logging at parity with production?

Hold the standby environment to production's standard: same patch level, endpoint protection deployed, firewall rules synchronised. Then route failover logs into central monitoring so you are not blind when most exposed. An unhardened DR environment is a pre-built back door, and an unmonitored one hides the intruder who uses it.

Standby environments drift because they sit idle. Nothing breaks when a patch is missed or an agent is never installed. Nobody notices until failover puts production traffic on the least-defended system you own.

A one-page parity baseline should record, for production and standby side by side:

• Patch level for operating systems and key services.
• Endpoint protection agents deployed and reporting.
• Firewall rules and security groups, synchronised.
• Log forwarding to central monitoring.

Compare the two before every exercise and after any major change. Where infrastructure is defined as code, deploy both environments from the same templates and most drift disappears at source.

Endpoint agents are easy to miss because standby hosts are often built from images that predate the agent rollout. Rebuilding standby images from the current production baseline closes that gap.

Telemetry is the second gap. Logs from failover infrastructure need a route into central monitoring, because losing visibility exactly when you are most exposed is the commonest silent gap. A typical cause is mundane: the log connector was built for production and never replicated for the standby.

Prove the route works rather than assume it. After each failover test, compare event counts from the standby for the test window against what central monitoring received.

Run the same comparison as a quick check before standby takes live traffic, so a failed check becomes a decision rather than a surprise. Kept current, the parity baseline answers the auditor's request to see standby against production in minutes rather than days.

How should emergency privileged access work during a disruption?

Emergency admin access should be protected by strong MFA, record every use in the logs, and be revoked once the incident closes. Pair it with immutable or offline backups and an offline copy of the recovery playbook. After recovery, stand down compensating measures and confirm baselines and monitoring are restored.

Break-glass accounts exist for the day the identity provider itself is down, so they cannot depend on it. Keep a small number of dedicated accounts and store their credentials apart from the systems they unlock. Alert on every login, so any use is visible within minutes.

Immutable backups cannot be changed or deleted inside their retention window, even by someone with admin credentials. Only a restore test proves they work. Keep the recovery playbook printed or on offline media, because the document is useless if it lives on the system that failed.

Rehearse the break-glass path in the annual exercise. An emergency account that has never been used is the one most likely to fail on the day, through an expired token or a lost credential.

The step that gets skipped is restoration. Recovery is declared done while systems still run in degraded mode, and the "temporary" relaxations stay in place for months.

A temporary exception with no expiry date is a permanent control failure.

Run a deliberate close-out after every real disruption:

1. Stand down each compensating measure and revoke emergency access.
2. Restore baselines by returning configurations to the agreed standard.
3. Confirm monitoring by checking that logs are flowing and alerts are healthy.

Give every pre-approved exception an owner and an end condition when you write it, so the stand-down becomes a checklist item rather than a memory test.

What do auditors examine for A.5.29?

Auditors read the continuity plan for security substance beyond uptime and pull the latest exercise report to see whether security outcomes were tested and actioned. They may also compare standby configuration against production. Continuity with no security content, or never tested, typically grades major; parity drift or stale exercises grade minor, aggregating to major as a pattern.

Expect these questions when auditors assess ISO 27001 information security during disruption:

• "Show me where your continuity plan addresses security, not just recovery of service."
• "How did you decide which security controls keep operating during a disruption, and what stands in for the ones that can't?"
• "Is the DR environment patched and protected to the same standard as production? Show me."
• "During your last failover test, did central logging keep receiving data, and how do you know?"
• "Walk me through emergency access: who can use it, how is use recorded, how is it revoked?"
• "When did you last test any of this, and what changed as a result?"

The evidence that answers them is mostly an extension of artefacts you already hold:

• Continuity and DR plans with degraded-mode procedures, not just recovery steps
• The impact analysis showing security services were considered
• The pre-approved compensating-control list
• Configuration baselines or screenshots showing production and standby parity
• Monitoring records showing log flow continued during the last failover test
• The exercise report with its follow-up actions
• Continuity commitments from critical vendors, such as SLA terms and SOC 2 or ISO certificates
• Evidence that staff were briefed on what changes during a crisis

The cheapest finding to avoid is the stale exercise. Date the report, give each action an owner and close the actions before the next audit. The "last tested" question then becomes a document you hand over.

A continuity plan nobody has rehearsed is a hypothesis, not a control.

How does GRC engineering automate A.5.29 evidence?

GRC engineering turns A.5.29 from an annual scramble into a monitored condition. Drift detection raises tickets when standby diverges from production, and synthetic events prove DR telemetry still flows. Backups and restores are checked automatically, and failover exercises run as tracked workflows that produce the audit trail as a by-product.

Four automations do the work:

• Drift detection. Patch and configuration state is compared continuously between production and standby, with a ticket raised for each divergence. Parity stops being an annual discovery.
• Log-pipeline health checks. Synthetic events sent from DR infrastructure confirm telemetry reaches central monitoring. A dropped pipeline alerts before a crisis, not during one.
• Backup integrity. Immutability settings and scheduled restore tests are verified automatically, with results filed as evidence.
• Self-documenting exercises. The failover test runs as a tracked workflow that captures what was tested, what held and the follow-up actions.

The human layer stays where judgement lives. Deciding what acceptable security in degraded mode means, getting it agreed and owning the exercise cadence is governance work that sits with a Fractional CISO.

Control parity, log routing from DR infrastructure and immutable backup design are cloud security architecture. The automation above is what GRC engineering builds on top of both.

At this scale, the result is an answer to the due-diligence question that arrives as a dashboard export, with the exercise report and drift history attached.

Frequently asked questions