A.5.29 Information security during disruption: evidence and audit

What A.5.29 information security during disruption requires

An auditor or customer who asks how security holds up when systems fail or a site is lost is asking about A.5.29. The control requires the organization to plan how it will keep information security at an appropriate level during a disruption. Recovering systems is not enough on its own: the plan must also say which security controls keep running, which are adapted, and who decides when a control is suspended. The control merges three ISO/IEC 27001:2013 controls, A.17.1.1 (planning information security continuity), A.17.1.2 (implementing it) and A.17.1.3 (verifying, reviewing and evaluating it), so an assessor will look for one coherent plan that covers all three stages rather than three separate documents.

The risk this control addresses is quiet. During failover to a secondary site, an emergency restore or a rushed workaround, teams often disable or bypass controls that slow recovery: multi-factor prompts, logging to the central store, network segmentation, malware scanning or change approval. Nobody decides to drop them, and nothing alerts anyone that they are gone. The plan should list the critical controls for each key service, state which ones may be relaxed under a documented emergency procedure, name the approver for each exception, and require that every relaxed control is restored and recorded when normal operations resume.

This is hard to get right because continuity teams and security teams usually plan separately. Continuity planners own recovery time objectives and runbooks, while security owns the Annex A controls. The reader should confirm whether the business continuity plan references security requirements at all, and whether the security team has reviewed the recovery runbooks and the alternate site configuration. Test this with a tabletop exercise in which a recovery runbook is walked through against the access, logging and backup controls. Gaps found there are cheaper to fix than gaps found during a real outage. Related work sits in A.5.30 for ICT readiness and A.8.13 and A.8.14 for backup and redundancy.

Which systems, teams and third parties A.5.29 covers

A.5.29 reaches further than the disaster recovery plan. The scope decisions below determine which systems, teams and providers must keep security controls running during a disruption, and which ones the organization must plan for in advance. Each one should be settled and written down before an auditor asks how continuity keeps information security at an appropriate level.

Continuity plans and recovery sites in scope

Start by listing every continuity plan, failover site, cold or warm standby and recovery environment that could hold or process information during a disruption. Each one needs a decision: is it in the ISMS scope, and if so, which controls apply there? A recovery site with weaker access control than production is a common gap. Confirm that every site named in the plans appears in the scope statement and the asset inventory, so the assessor can trace it.

Access controls during disruption

Emergency access is the control most often relaxed during an outage. Decide in advance who may use break-glass accounts, how those accounts are issued, how long they stay active and who reviews their use afterwards. The plan should state whether normal authentication, including multi-factor methods, still applies on recovery systems. Ask the continuity owner to show the procedure that revokes emergency access once normal operations resume.

Logging and monitoring on recovery systems

Recovery environments often run without the logging and monitoring that production has, so attacks can go unseen while teams focus on restoring service. Decide which logs must still be collected on failover systems, where they are sent and who reviews alerts when the normal security operations team is busy. Check that log retention on the recovery side meets the same requirement as production, and that gaps are recorded as exceptions.

Network segregation and encryption during failover

Restoring service quickly can mean connecting systems that were kept apart, or moving data over temporary links that were never reviewed. Map which network zones may be joined during a disruption and which must stay separated, and confirm that data in transit and at rest on recovery sites still meets the encryption rules for its classification. Each temporary exception should have an owner, an approval and an end date.

Manual workarounds and their controls

When systems are down, staff often move information into spreadsheets, shared drives, email or paper. These workarounds handle sensitive data outside the controls that protect the systems they replace. Identify the processes where manual handling is likely, define the approved methods, and set rules for storing, labeling and later reconciling the records. Check that the workaround is covered by the same confidentiality and disposal rules as the original process.

Third-party recovery services

Many recovery arrangements depend on providers for hosted sites, backup restoration, managed failover or emergency staffing. Each provider that touches information during a disruption falls within the supplier controls in the ISMS. Confirm in the contract what security obligations apply during an outage, how the provider reports incidents, and whether the organization can verify its controls. Ask for the provider's own continuity test results before relying on them.

How an assessor tests A.5.29

This table sets out what an assessor reviews, samples and tests for A.5.29, the evidence each step expects, and the findings that typically follow when it is missing. Read it as a checklist of what to prepare before the assessor arrives. The main takeaway is that the assessor looks for security considered inside continuity arrangements and proven by test records, not for the existence of a continuity plan alone.

Test step	What the assessor checks	Typical common finding
Review the continuity plan	Whether the plan states which information security controls must keep running during a disruption, and who decides when they can be relaxed	Continuity plan with no security section, covering recovery time and staffing only
Check security requirements for disruption modes	Whether security requirements are defined for each disruption mode the plan covers, such as failover to a secondary site, manual operation or reduced staffing	Failover procedures that drop authentication, logging or network segmentation without a documented decision
Check approval of alternate arrangements	Whether temporary or alternate security arrangements have named approvers and a defined way to restore normal controls afterwards	Emergency access granted during an outage that is never revoked or recorded
Sample test and exercise records	Whether tests and exercises verify security controls as well as recovery, and whether results and corrective actions are recorded	Tests that confirm systems restart but never verify that access control, backups or monitoring work in the recovery environment
Check backup and redundant site evidence	Whether restored or failed-over systems are shown to meet the same security baseline as production, with records from the test	No record that the secondary environment was hardened or that restored data was checked for integrity
Check review after changes	Whether the continuity security arrangements are reviewed after significant system, supplier or organizational changes, and at planned intervals	Plan last reviewed before a platform migration, with no update to the security considerations
Confirm the separation of roles	Whether the people who design the test are distinct from the people who approve its results where practical, and whether findings are tracked to closure	Only the team that wrote the plan signs off the exercise report, with no independent check

How to plan security during disruption step by step

This sequence turns A.5.29 into a documented plan: each disruption scenario gets a decision on which security controls hold, which adapt and which are accepted as reduced, with approved compensating measures tested and reviewed. The result is evidence that information security stays at an appropriate level when normal operations fail.

Identify disruption scenarios from the business impact analysis
Start from the business impact analysis and the list of critical processes it ranks. Name the disruption scenarios that could stop those processes, such as loss of a data center, failure of a key supplier, a ransomware outage, loss of staff or loss of access to a cloud region. Record each scenario with the processes and information it affects, its owner and the business impact that drives recovery priorities. Done when the scenario register is approved by the business process owners and the information security lead, and every critical process appears against at least one scenario.
Map the security controls each scenario depends on
For each scenario, list the security controls the affected processes rely on: access control, logging, monitoring, encryption, network segmentation, endpoint protection, backup integrity and supplier access. Use the Statement of Applicability and the asset inventory to confirm which controls protect the affected information. Done when every scenario has a control list that names the owner of each control and where its evidence is kept.
Decide keep, adapt or accept reduced for each control
For each control in each scenario, record one of three decisions: keep it unchanged, adapt it to the recovery environment, or accept a reduced level with a documented reason. Adaptation might mean a lighter logging pipeline or a smaller set of privileged accounts in a standby site. The information security lead decides with the risk owner, and anything accepted as reduced goes into the risk register with an owner and a review trigger. Done when each decision has a named approver and a rationale that an assessor can follow.
Document approved compensating measures
Where a control cannot run during disruption, write the compensating measure that covers the same risk. Examples include manual approval of administrator actions, read-only access to restored data, out-of-band verification of payment instructions or an extra review of restored systems before reconnection. Each measure needs a procedure, an owner and a record that shows it was used. Done when the compensating measures are approved by the risk owner and stored with the continuity plan where responders can reach them.
Align the security plan with the A.5.30 ICT readiness plan
Check that the technical recovery steps in the ICT readiness plan under A.5.30 can carry out the security decisions made in the earlier steps. Confirm that recovery sites, restored systems and backup repositories are configured to keep logging, access restrictions and integrity checks where the scenarios require them. Record any gap as an action with an owner. Done when the two plans reference each other, and the recovery runbooks include the security steps and the compensating measures.
Test the scenarios and record the results
Run tests that exercise the kept, adapted and compensating controls, such as a failover exercise, a restore from backup with integrity verification, or a tabletop walk-through of a supplier outage. Record what ran, what was observed, which security controls behaved as planned and which did not. Verification of backups can use tools such as Bareos restore jobs and restic repository checks, but confirm that each tool supports the checks you need in your environment. Done when test records name the scenario, the participants, the findings and the actions raised.
Act on findings and update the plan
Turn each test finding into a tracked action with an owner and a due date set by the organization, then update the scenario register, control decisions and compensating measures. Keep the before and after versions so that an auditor can see how the plan changed. Done when every finding has a closed action or an accepted risk, and the updated plan is approved.
Review the plan after significant change
Review the disruption plan at planned intervals and after significant changes such as a new cloud provider, a changed data center, a major system migration, a new critical supplier or a significant incident. Check that scenarios, control decisions and compensating measures still match the business impact analysis and the current architecture. Done when the review record lists the trigger, the reviewer, the changes made and the date the plan was re-approved.

Deciding whether continuity arrangements keep or adapt security controls

The central judgment in A.5.29 is made scenario by scenario. For each disruption the organization expects, such as loss of a data center, a ransomware outage of identity services or a failover to a secondary site, it should decide whether each relevant security control is kept as normal, adapted to the emergency setting, or temporarily reduced under a documented risk acceptance. Keeping a control unchanged is often right, and the decision should be explicit for each one rather than assumed. Start from the controls that protect the recovery path itself: authentication to the recovery site, privileged access, logging, backup integrity and network segmentation. These are the controls an attacker is most likely to target during a disruption, and the ones that are easiest to bypass under pressure.

Consider an illustrative case, not drawn from any client. A recovery site needs emergency administrator access because the normal directory service is unavailable. The continuity plan might keep multi-factor authentication, adapt the approval step by naming a pre-authorized break-glass group with a shortened approval window, and keep session logging forwarded to a store outside the failed environment. A reduction, such as temporarily allowing a shared account, would need a written risk acceptance stating the residual risk, the compensating monitoring, the time limit and the end date for reverting. The owner of the information or service, usually the business owner with the CISO's advice, should approve reductions, while the control owner approves adaptations. Each decision belongs in the continuity plan or a linked register with the scenario, the control, the decision, the approver, the date and the review trigger.

Confirm two things with your own assessor before relying on this approach: which of your existing continuity and access procedures already name the approver for an emergency change, and whether your ISMS risk criteria cover temporary reductions. Then test the decisions. Tabletop exercises and recovery tests should check that the break-glass steps, the logging path and the reversion to normal controls work as written. A reduction that was never exercised tends to be the one that survives longest after the disruption ends. Plan the review and reversion of every temporary decision, because an auditor will look for the closing record as readily as the original approval.

Evidence that passes A.5.29 and how to keep it current

An assessor testing A.5.29 looks for a chain of documents that connects a planned disruption to tested security behavior at the recovery site. Each artifact below answers one part of that chain, and each goes stale unless someone owns a review routine between audits.

Security-aware continuity plans

The continuity plans must state which security controls stay on during a disruption, which are relaxed, and who approves each change. Check that every recovery procedure names the security function it depends on, such as access control, logging, encryption and backup integrity. Review the plans after any material change to systems, suppliers or recovery sites, and record the review date and approver in the document itself.

Disruption scenario register

The register lists the disruption scenarios the organization has chosen to plan for, such as ransomware encryption of primary systems, loss of a data center, or a compromised identity provider. For each scenario, record the security risk it creates, such as unvetted access during failover. Refresh the register when threat intelligence or the risk assessment changes, and retire scenarios that no longer match the infrastructure.

Approved compensating control records

Where a normal control cannot run during recovery, such as a multi-factor prompt that the recovery site cannot reach, the record shows the substitute control, its owner, its limits and its expiry. Auditors sample these records to confirm that a temporary weakening was a decision, not drift. Set an expiry for each approval and check that expired exceptions were closed or re-approved.

Test reports at the recovery site

Exercise reports should show that security controls worked at the recovery site, not only that systems came back. Look for evidence of logging, access restriction, backup restore integrity checks and alerting during the test. Record failures and the follow-up actions. Ask the testing team to confirm which controls were in scope, because a test that skips security checks does not satisfy the control.

Review minutes and change records

Minutes from continuity and security review meetings show that someone examined the disruption arrangements at planned intervals and after significant changes. Change records tie each update to the plans, scenarios and compensating controls it affected. Keep both in the same repository so an assessor can trace a decision from its review to the document version it changed.

How self-hosted backup and monitoring tools produce A.5.29 evidence

An auditor testing A.5.29 will want proof that recovery paths and monitoring still work while the organization is under disruption, not just a plan that says they will. Self-hosted tools can supply that proof if they are configured to record what they do. In a Bareos deployment, the Director schedules and supervises backup, restore and verify jobs, and its job logs show whether each run completed. The SQL catalog records which files were backed up and when, so a restore test can be shown against a specific backup or against one taken before a chosen date and time. Keep the job reports, the restore test records and the catalog extracts from exercises that were run under degraded conditions, such as a restore performed with the primary site unavailable, because those show the continuity arrangements were exercised.

restic offers a separate line of evidence. Its check command verifies the structural consistency of snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack files back to confirm the stored data is unmodified. Retain the output of scheduled check runs with read-data settings chosen and documented by the organization, along with the repository location and the restore tests that followed. Grafana Alerting and Prometheus can show whether monitoring itself survived the disruption: Prometheus stores metrics as time series, and Grafana alert rules and their notification history can show when alerts fired, to whom, and whether they were acknowledged. Confirm in the client's environment that the Prometheus instance and alert routes are hosted so that they remain available when the primary site is not, and that retention settings keep records for the period the auditor will sample.

These tools produce evidence. They do not decide whether security controls should be kept, reduced or compensated during a disruption, and no log entry replaces that decision. The organization still needs a documented determination, approved by the people named in its continuity plan, that states which controls apply in each disruption scenario and what compensating measures replace any that cannot run. Before relying on any of these records, confirm each tool's behavior with the vendor documentation and in the client's own configuration, including job retention, catalog backup, and whether alert history is exported or lost when a node fails.

What meeting A.5.29 costs in money and effort

This table breaks down the main cost and effort components of meeting A.5.29, who is paid for each, whether it is one-time or recurring, and what drives it up. No prices or durations are published here because none were supplied, so use the right-hand column to shape your quote requests. The main takeaway is that tooling licence cost is usually the smallest line, while scenario analysis, plan review, exercises and assessor sampling carry most of the effort.

Cost component	Who is paid or who carries the effort	One-time or recurring	What drives it and what to ask for in a quote
Disruption scenario analysis	Internal risk and continuity owners, sometimes an implementation partner facilitating workshops	One-time to set up, then recurring at each review	Number of critical services and sites in scope. Ask the partner to list the scenarios covered and who signs them off.
Security review of continuity plans	Information security staff reviewing business continuity and disaster recovery plans	Recurring, tied to plan review cycles and material changes	Number of plans and how often systems change. Ask whether the quote covers reviewing existing plans or drafting new ones.
Open-source tooling (for example Bareos, restic, Prometheus, Grafana)	Licence cost is usually nil for these projects; hosting and engineering time are paid to your team or a partner	Hosting and storage recur; setup is one-time; upgrades recur	Backup volume, retention periods, monitoring scope and hosting model. Ask for hosting, patching and upgrade responsibilities in writing.
Exercise design and execution	Internal teams running tabletop or technical recovery exercises, often with an external facilitator	Recurring at each planned exercise	Number of exercises per year, whether they test failover in production or in a copy, and staff time pulled away from operations.
Remediation of gaps found in exercises	Engineering and operations teams, or a partner under a fixed-scope change	One-time per finding, with some recurring fixes	Number and complexity of findings. Ask how a quote handles findings that appear mid-engagement.
External testing or independent review	Specialist testers or reviewers outside the function being reviewed	Recurring, usually tied to the review cycle	Scope of systems, whether recovery paths are tested, and whether the reviewer is independent of the team that built the plan.
Evidence collection and auditor sampling	Internal compliance staff, with time from the certification body's auditors	Recurring at each surveillance or recertification audit	How many exercise records, plan versions and backup restore tests the auditor samples. Ask your certification body what evidence it expects in advance.
Training and awareness for continuity roles	Internal teams, or a training provider	Recurring as roles change	Staff turnover and the number of people named in continuity roles. Ask whether training is included in the quote.

Who plans, implements and assesses A.5.29

Your organization owns A.5.29. Only your people can decide which information security controls must keep running during a disruption, which can be relaxed, and which compensating measures are acceptable when a normal control cannot operate. Those decisions carry the risk, so they must be recorded and approved by someone with authority over the continuity plan and the ISMS.

Deciding the required level: Set the minimum security level for each critical service during disruption, based on your business impact analysis and risk assessment.
Approving compensating measures: Sign off on any alternative control, such as manual approvals replacing automated access checks, and record the residual risk.
Owning continuity arrangements: Decide whether failover sites, backup systems and emergency access keep the same controls or adapt them, and document the reasons.
Running exercises: Schedule and lead tests of disrupted-state procedures, and record what was learned and who fixed each gap.
Keeping records current: Maintain the approved plan, approval history and review dates so an auditor can trace each decision.

Before assessment, confirm that a named owner can explain every security decision in the plan and that the exercise records show decisions being tested, not just written down.

Where organizations fall short on A.5.29

Most A.5.29 gaps are not missing plans. They are plans that describe recovery without describing how security holds up while systems run degraded, moved or in a different place. The cards below cover the failure points an assessor is most likely to probe, each with a closing action the organization can take before the next assessment.

Continuity plans that ignore security

Many business continuity and disaster recovery plans list recovery steps, owners and recovery order but say nothing about access control, logging, encryption or monitoring while a site or system runs in fallback mode. A.5.29 asks for security to be planned into disruption, so the plan itself should name the security functions that must keep running. Check each recovery procedure for a security step, and add one where it is missing.

No approved record of reduced controls

During an outage teams often bypass or simplify controls, such as shared accounts, relaxed approval paths or disabled alerts, without recording it. An assessor looking at A.5.29 will ask which controls may be reduced, under whose approval and for how long. Maintain a register of permitted control reductions with named approvers, expiry conditions and a required return-to-normal check.

Tests that measure recovery only

Exercises often confirm that a service comes back within its recovery time objective and nothing more. They rarely check whether backups were restored from a clean point, whether restored systems carry their old access rights, or whether monitoring still sees the recovered environment. Extend each test scenario with security checks, such as verifying restored data integrity and confirming authentication and logging work on the failover target.

Plans not updated after changes

A continuity plan written for an on-premises data center can be wrong after a move to a new cloud region, a new managed database or a change of backup provider. The security assumptions in the plan then no longer match the systems. Tie plan review to change management so that any significant infrastructure or supplier change triggers a review of the disruption security arrangements.

Evidence scattered across tools

Proof that security was considered during a disruption often sits in backup consoles, monitoring dashboards, ticket queues and chat logs, with no single record that links an incident to the decision taken. This makes it hard to show what happened and why. Define which tool holds each piece of evidence, retain exports with timestamps and link them to the continuity record for each exercise or event.

A.5.29 questions buyers ask before hiring help

How much effort does A.5.29 information security during disruption take?

The effort depends on how many continuity plans exist, how many of them touch systems that hold sensitive information, and whether those plans already name security requirements. A.5.29 asks the organization to decide how information security will be kept at an appropriate level during a disruption and to show that the decision was checked. Work usually splits into a review of existing business continuity and disaster recovery plans, a list of the security controls each critical process depends on, decisions on which controls are kept, adapted or replaced during disruption, and tests that confirm those decisions hold. Ask any partner to estimate effort from a written list of plans and systems in scope, not from the control title alone.

Can we handle A.5.29 in-house without outside help?

Yes, many organizations do, provided someone owns the continuity plans and someone else understands the security controls those plans rely on. The usual gap is that continuity teams plan for restoring service and security teams plan for protecting data, and nobody writes down what happens to access control, logging, encryption or approvals when a site or system is running in degraded mode. Internal teams can close that gap if they have time to test the plans and record the results. Outside help is most useful when the internal team lacks an independent reviewer, has no experience with failover testing, or needs the work done before an assessment date.

How long does preparing for A.5.29 usually take?

No fixed duration applies because preparation depends on the maturity of continuity planning, the number of critical services and how often plans are tested today. A team with recent, tested continuity plans may need to document security decisions and collect evidence. A team with outdated plans may first need a business impact analysis and fresh recovery objectives. Ask any provider to state the timeline in the written scope, with the systems covered, the test dates and the dependencies on other teams, such as facilities or suppliers. Timelines that are not tied to a defined scope are not comparable across quotes.

What does the client team need to provide for A.5.29 work?

The client team owns the decisions and the business context, so it must supply access to people and records. In practice this means a named owner for business continuity, access to current plans and recovery objectives, an inventory of systems in the continuity scope (see A.5.9), contacts in facilities and key suppliers, and time for the people who run recovery exercises. Security leads must approve which controls may be relaxed during disruption and at what level of risk. Partners can draft documents and run technical checks, but they cannot accept risk on the organization's behalf. Confirm these responsibilities in the written scope before work starts.

How does A.5.29 differ from A.5.30 ICT readiness for business continuity?

A.5.29 asks whether information security is maintained during a disruption, while A.5.30 asks whether ICT systems are ready to be recovered when the business needs them. A.5.29 covers decisions such as whether a backup site keeps the same access rules, logging and encryption, and whether emergency access procedures have a time limit and an approval step. A.5.30 covers the technical readiness itself, including recovery design, failover capacity and recovery testing. The two controls share evidence, such as test records, but they answer different questions. Assessors expect each control to have its own documented decisions and its own test results.

Can a partner certify that we comply with A.5.29?

No. A partner can prepare your systems, documents and evidence for A.5.29, but only an independent auditor or certification body can assess compliance and issue a report or certificate. ISO does not certify organizations, and accredited certification bodies must assess the ISMS against the standard. The organization owns its controls and its risk decisions. When you select a partner, ask who will perform the internal review and confirm that the certification body is independent of the firm that prepared your evidence. This separation protects the credibility of the eventual certification.

How DeployOpen prepares A.5.29 evidence

DeployOpen's work on A.5.29 starts with a written scope that names the systems, services and sites whose continuity arrangements must keep information security at an appropriate level during disruption. The scope document lists the deliverables, the roles on both sides and the timeline before any configuration begins. Most engagements are fixed-scope, and a quote follows from that written scope, so the organization can see which continuity processes, recovery sites and tooling are included and which remain with its own teams. Ask for the scope to state explicitly which disruption scenarios are covered, for example loss of a primary data center, loss of a cloud region or loss of a key supplier, because each one changes which security controls must still operate.

Next, DeployOpen prepares the continuity and security documentation that the organization reviews and approves: the disruption scenarios, the decision on whether each continuity arrangement keeps a control unchanged or adapts it, the fallback procedures for access control, logging and backup integrity, and the criteria for returning to normal operations. The organization owns these decisions and the controls they describe. DeployOpen drafts, the organization approves, and the record of that approval is itself evidence. Confirm with your team which people sign each document and how often they are reviewed.

Where the organization wants self-hosted tooling, DeployOpen deploys and configures it inside the client's own cloud accounts, data centers or air-gapped networks. Examples include Bareos for scheduled backup, restore and verify jobs, restic for repository checks that read pack files back, and Prometheus and Grafana Alerting for monitoring failover conditions. The output is configured tooling and retained records, such as job reports, verification results and alert history, that an assessor can sample. DeployOpen does not issue audit reports or certifications. Independent auditors and certification bodies assess the evidence and decide conformity. Confirm with your certification body which evidence it expects for A.5.29 before the tests are run.