A.5.30 ICT readiness for business continuity: evidence and audit

What A.5.30 ICT readiness for business continuity asks for in practice

A.5.30 is a new control with no direct predecessor in the 2013 edition, so an auditor will not find an old clause to map it onto. What they will expect is a documented chain that runs from the business impact analysis, to the recovery objectives derived from it, to the ICT arrangements that meet those objectives, to evidence that recovery has actually been tested. The risk the control addresses is simple to state: a system the business depends on cannot be restored within the time the business can tolerate, because nobody planned for its recovery, the plan was never built into the infrastructure, or the plan was written but never exercised. The control is one of the 11 controls that were new in the 2022 revision, and it sits beside A.5.29 Information security during disruption, which covers whether security controls hold during a disruption, and A.8.13 and A.8.14 on backup and redundancy of information processing facilities. Those neighbors are where auditors look for gaps between the continuity plan and the technical measures that deliver it.

The control asks for four things that map to four verbs: ICT readiness must be planned, implemented, maintained and tested, and each step must trace back to business continuity objectives and ICT continuity requirements. Planning means agreeing which services matter, their recovery time and recovery point objectives, and the dependencies beneath them. Implementation means the backup, failover and restore capability exists in the environment. Maintenance means the arrangements keep pace with system changes, and testing means someone restores a service and records the result. Ownership is the hard part. ICT teams own the infrastructure, operations owns the service, and risk or the business owns the impact tolerance, so the objectives often sit in a document nobody in IT has signed. Before the next audit, confirm who approves the recovery objectives, who owns each ICT recovery arrangement, and where the test records are kept.

Which systems, teams and suppliers fall inside ICT readiness scope

ICT readiness under A.5.30 is only as wide as the services the organization decides to cover. The cards below cover the decisions that set that boundary, from the business services people depend on to the cloud and hosted providers that run part of the recovery path.

Business services that depend on ICT

Start from the business processes the organization must keep running or restore, not from the list of servers. For each process, record the applications, data stores, network paths, identity services and staff tools it needs. A payment or claims process, for example, may depend on a directory service and a message queue that nobody lists as critical. Each dependency you miss becomes a gap in the recovery plan, so ask process owners to confirm their dependency lists before any recovery testing starts.

Critical services chosen by impact analysis

ISO/IEC 27002 links ICT readiness to a business impact analysis, from which recovery time and recovery point objectives for ICT services are derived. The business impact analysis decides which services are critical, and that choice drives the scope of testing and the cost of redundancy. Confirm with business owners how much downtime and data loss each service can tolerate, and document who approved those figures, because auditors will trace each test back to them.

Backup platforms in scope

Backup and restore tools are part of ICT readiness, not only part of A.8.13. Decide which backup platform protects each critical service, who administers it, and where its catalog and encryption keys are held. A tool such as Bareos keeps a SQL catalog of backed-up files and can restore from a backup taken before a given date and time, so its catalog and retention settings must be included in the readiness plan. Confirm that the platform itself can be recovered if the primary site is lost.

Redundancy and failover components

Redundant sites, standby clusters, replicated storage and secondary network links fall under A.8.14 and need to be included when they carry a critical service. Scope each one by the service it supports, and record which components share a single power feed, data center or identity provider, because shared dependencies can defeat redundancy. Plan one failover test per critical service, and confirm the expected switchover time against the recovery objectives agreed in the impact analysis.

Hosted and cloud providers

A provider that runs a critical service remains in scope as part of the recovery path, even though the organization does not operate its hardware. Ask each provider for its own recovery commitments, the regions or zones it uses, how it backs up tenant data, and how and when it tests its continuity. Record the split of responsibilities in the contract and the shared responsibility model, and confirm which provider reports the organization can obtain as evidence, since these determine which gaps belong to the organization and which belong to the supplier.

Teams that own recovery steps

Recovery spans infrastructure, application, security, network and service desk teams, and each step needs a named owner who can act out of hours. Scope the people who hold credentials, runbooks, break-glass accounts and vendor contacts, and check that their availability matches the recovery objectives. Monitoring tools such as Prometheus and Grafana Alerting also belong in scope when they detect failures that trigger recovery, so confirm which team receives and acts on those alerts.

How an assessor tests ICT readiness and what they ask to see

This table walks through how an assessor tests A.5.30 element by element, from objectives through continuity requirements, plans and recovery tests. Read each row as a question the assessor will ask, the evidence they will request, and the gap they most often record.

Test element	Evidence the assessor requests	Common finding
Continuity objectives	Documented recovery time and recovery point objectives per ICT service, approved by the business owner, with the date they were last reviewed	Objectives exist but no owner signed them, or they were set without reference to business priorities
Business impact analysis link	The business impact analysis that produced the objectives, showing which processes depend on which ICT services and the impact of their loss over time	Objectives are not traceable to any business impact analysis, so the assessor cannot confirm why a service has a given target
ICT continuity requirements	A list of ICT services in scope, their dependencies (identity, network, data stores, third-party services) and the recovery order derived from the objectives	Requirements are written at system level only, and dependencies such as directory services or DNS are missing from the recovery sequence
Recovery plans and runbooks	Current plans for each in-scope service, version history, named roles, contact details and the steps needed to rebuild or fail over	Plans reference systems or staff who have left, or they have not been updated since a major infrastructure change
Plan maintenance	Change records showing plans were reviewed after infrastructure changes, with dated sign-off and a list of open corrections	Plans are reviewed on paper only, with no link to change management or to the outcome of the last test
Recovery tests	Test schedule, scenarios chosen, test scripts, timing results against objectives, and records of who participated	Tests are tabletop exercises only, or they confirm that a backup job completed without ever restoring data to a working system
Test results and follow-up	Test reports that compare achieved recovery times with objectives, a register of failed steps and the corrective actions with owners and due dates	Failed objectives are recorded but no corrective action or re-test follows, so the same gap appears in the next exercise
Backup evidence used in tests	Restore logs from the backup platform, verification outputs and the date of the last successful restore of each critical dataset	Backup success reports are shown as proof of readiness, while restore success is not demonstrated for the services that matter most

Implementing ICT readiness step by step

This sequence turns the business continuity intent behind A.5.30 into agreed recovery targets, documented ICT continuity designs, configured recovery capabilities and tested evidence that the systems can be brought back when the business needs them. Each step produces a record an assessor can sample.

Agree business continuity objectives with owners
Start with the business owners of each critical process, not with the IT team. Ask them which processes must continue, how long each can be unavailable before harm builds, and which partial service levels are acceptable during a disruption. The organization owns these decisions, and senior management should approve the resulting objectives. The step is complete when each objective is written down, named to a process owner, and approved in a record that shows who agreed and when.
Run the business impact analysis
Map each business process to the ICT services it depends on, including applications, databases, networks, identity services, backup systems and key suppliers. For each service, assess the consequences of loss over time and derive a recovery time objective and a recovery point objective. ISO/IEC 27002:2022 links this analysis to ICT readiness, so the outputs should show how each target was reached. Done means every critical ICT service has documented targets traceable to a process and an owner, and the analysis has been reviewed when services change.
Document ICT continuity requirements and recovery designs
Translate the recovery targets into requirements the technology must meet. Specify the recovery sequence, the dependencies between services, the backup frequency needed to meet each recovery point objective, the location or redundancy model, and the people who invoke each recovery. Cross-reference related controls such as A.5.29 on security during disruption, A.8.13 on information backup and A.8.14 on redundancy of information processing facilities. Done means a design document exists for each critical service and each requirement can be traced to a target from the previous step.
Implement and configure recovery capabilities
Build the backups, replicas, standby environments and failover procedures described in the designs. Where backups are used, a tool such as Bareos can schedule backup, restore and verify jobs and keep a catalog of what was backed up, while restic's check command can confirm repository structure and, with read-data options, that stored pack files are unmodified. Record configuration in version control so the state can be shown later. Done means each design element is deployed, the configuration matches the design, and a restore or failover has been performed once in a controlled way.
Monitor recovery readiness continuously
Recovery capability decays silently when backups fail, replication lags or capacity drifts. Use monitoring to measure those signals against the recovery objectives. Prometheus can collect metrics from instrumented jobs through its pull model and store them as time series, and Grafana Alerting can build rules from queries across metrics and logs and route alerts to the people who act on them. Confirm that the platform's alerting covers each objective you set. Done means each critical service has a readiness signal, an alert with a named owner, and a history that shows the signal was watched.
Schedule maintenance and recovery tests
Set a calendar for maintenance of the recovery environment and for tests of recovery scenarios, covering both component restores and broader exercises that involve business owners. Choose test scope based on the criticality ranking from the business impact analysis. Record each test's objective, the scenario, the actual recovery time and data loss achieved, and any deviations. Confirm with your certification body how it expects the test schedule to be evidenced. Done means a plan exists, tests have run at the planned intervals, and each test has a written record.
Feed results back into the plans
Compare each test result with the recovery time and recovery point objectives. Where the achieved values fall short, decide whether to change the design, the backup frequency, the staffing model or the objective itself, and assign an owner with a date. Update the continuity plans, runbooks and the business impact analysis to match. Done means each shortfall has a recorded decision and action, the affected documents show the revised version, and the next test reflects the change.

How backup, redundancy and monitoring produce the readiness evidence

Readiness is shown by restores and failover results, not by the existence of backups. An assessor testing A.5.30 will ask whether the organization can bring back the ICT services that matter within the recovery time and recovery point objectives set from its business impact analysis, and will look for dated records of tests that did so. A backup job that reports success proves that data was copied, not that a payroll system or customer portal can be rebuilt from it. Each of the three technical layers below produces a different kind of evidence, and an auditor will expect all three to agree with each other.

The first layer is the backup catalog. Bareos runs backup, restore, verify and archive jobs under its Director and keeps a SQL catalog of the files it has backed up. That catalog is the evidence of what is protected, which job protected it and when, and it lets the team restore files from the current backup or from one taken before a given date and time. Confirm with the Bareos documentation which catalog database and retention settings your version supports, and record the restore tests as dated tickets that name the system, the target time and the result. For the stored data itself, restic provides restic check, which verifies the structural consistency of snapshots, trees and pack files. Adding --read-data or --read-data-subset reads pack files back to confirm the stored data is unmodified. Run these checks on a schedule and keep the output, because an unmodified copy is only useful if it can still be read when the business needs it.

The second layer is monitoring. Prometheus collects metrics from instrumented jobs over HTTP and stores them as time series, so backup age, job duration, failed job counts and replication lag can be recorded and queried with PromQL. Grafana Alerting builds alert rules from those queries and from logs, and notifies the people who must act, so that a missed backup window becomes a tracked incident under A.5.26 rather than a surprise during a test. The evidence here is the alert history and the response record, and it shows that recovery-relevant failures are noticed. Ask the team to confirm which signals are tied to each RTO and RPO, because a dashboard that does not reference those objectives will be hard to defend.

Evidence that passes an A.5.30 review and how to keep it current

An assessor testing A.5.30 looks for a chain of evidence: the impact analysis sets the objectives, the plans implement them, tests prove they work, and monitoring shows the objectives still hold. Each artifact below should link to the next, and each needs a review cadence that the organization sets and then follows.

Business impact analysis output

The business impact analysis is the root of A.5.30 readiness. ISO/IEC 27002:2022 links ICT readiness to it, because recovery time and recovery point objectives for each ICT service are derived from it. Check that every in-scope service has a named business owner, a documented RTO and RPO, and a dated approval. Assessors often ask how a recovery objective was set, so keep the workings as well as the result. Ask the business owners to confirm the figures at the review cadence you set, and after any major change to a service.

ICT continuity plans

ICT continuity plans translate the recovery objectives into steps: who declares a disruption, which systems are restored first, where backups and standby capacity sit, and how the team communicates. Each plan should name its owner, the services it covers, its version and its approval date. Cross-check each plan against the impact analysis so that no service with a stated RTO lacks a recovery procedure. Review plans on your own schedule and whenever infrastructure, supplier or staffing arrangements change.

Dated restore and failover test records

Tests prove that the plans work, so assessors look for dated records showing what was tested, who ran it, the scenario, the measured recovery time and the outcome. A restore test that only confirms a job completed does not show that a system returned within its RTO. Backup tools such as Bareos keep a catalog of backed-up files and can restore from a chosen point in time, which gives a record of what was recovered. Set a test schedule for each critical service and keep the results even when they fail.

Backup integrity verification logs

Restores only succeed if the stored data is intact, so keep logs of integrity checks alongside the restore tests. restic's check command verifies the structure of snapshots, trees and pack files, and with the read-data options it reads pack files back to confirm they are unmodified. Retain the command output, the repository identifier and the date. Verification should run on a schedule you define, and a failed check should trigger a documented investigation rather than a silent retry.

Remediation actions from tests

A test that finds a gap is useful evidence only if the gap is tracked to closure. For each finding, record the service affected, the cause, the corrective action, the owner and the date it was closed, then retest the fix. Assessors commonly sample a failed test and ask to see the follow-up, so link each action back to the test record and the affected plan. Review open actions at the cadence you set and escalate any that pass a deadline your management has approved.

Change records that update plans

Infrastructure, application and supplier changes can quietly invalidate a continuity plan. Connect change management to continuity review: when a change alters a service's dependencies, storage, network path or recovery sequence, the change record should show whether the plan, the impact analysis and the test schedule were checked. Keep a dated log of plan revisions with the reason for each. Ask change approvers to confirm this step, and sample recent changes to test whether the link is real.

Monitoring alerts tied to recovery objectives

Monitoring shows whether recovery objectives are still achievable between tests. Prometheus collects metrics through a pull model and stores them as time series, so backup age, replication lag and standby health can be tracked over time. Grafana Alerting can build rules from queries across data sources and combine metrics and logs. Define an alert for each condition that would breach an RPO or RTO, route it to a named owner, and keep the alert history as evidence that issues were seen and acted on.

What meeting A.5.30 costs in money and effort

This table breaks down the cost and effort components of building and proving ICT readiness for business continuity, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to shape a written scope and to know what to ask for in a quote, since no figures are given here.

Cost component	Who is paid or who carries the effort	One-time or recurring	What drives it and what to ask for
Open-source tooling licenses	Usually none for Bareos, restic, Grafana and Prometheus, but support subscriptions or hosting are possible	Recurring if support or hosting is bought	Confirm each product's license and any paid support tier. Ask whether the quote includes hosting of the backup and monitoring stack.
Business impact analysis workshops	Organization staff time, with the implementation partner facilitating if engaged	One-time, repeated after major change	Number of business services in scope and how many owners must attend. Ask who produces the recovery time and recovery point objectives.
Engineering time to build backup and monitoring	Implementation partner or internal platform engineers	One-time build, then ongoing change	Number of critical ICT services, data volume and recovery targets. Ask for the backup design, restore scope and monitoring coverage in writing.
Recurring recovery testing effort	Organization owners for business sign-off, engineers for execution	Recurring at the frequency the organization sets	Test frequency and scope, such as file restores versus full failover. Ask who records results and how failed tests are re-run.
Evidence upkeep	Organization compliance or platform team, sometimes supported by the partner	Recurring	Frequency of restore logs, check results and alert history that must be kept. Ask how evidence is retained and where it is stored.
External testing or review	Independent reviewer or assessor, separate from the implementer	Periodic	Whether an outside party reviews the continuity design or test results. Ask for the reviewer's independence and scope.
Auditor sampling and certification audit effort	Certification body, paid by the organization	Recurring across the three-year cycle	Auditors sample test records and restore evidence. Ask the certification body how it samples and what records it expects.

Who owns ICT readiness, who can help and what the auditor checks

The organization owns A.5.30. Its leaders set the business continuity objectives that ICT readiness must serve, and they accept the recovery time and recovery point objectives that come out of the business impact analysis. Those decisions cannot be delegated to a partner, because the plan only means something if the business has agreed to it and funded it. Your team also approves the ICT continuity plans, assigns named owners to each recovery service, and decides which tests run and what counts as a pass.

Objectives and tolerances: Business owners state how long each service may be down and how much data loss is acceptable, and the ICT team maps those answers to systems.
Plan approval: A named role signs off each ICT continuity plan and re-approves it after material changes.
Test ownership: Your staff schedule, run or witness recovery tests, and record the results and follow-up actions.
Monitoring response: Someone on your side acts on backup failures and capacity alerts, not only the tooling that raises them.
Review cycle: Owners confirm the plans still match the current architecture at planned intervals.

Check that every recovery service has a named owner, an approved objective and a dated test record before an auditor asks for them.

Where ICT readiness programs usually fall short

ICT readiness fails in predictable places: the recovery targets were never tied to business impact, the backups were never proven to restore, and the plans no longer match the systems they describe. Each gap below is one an assessor can test, and each has a closing action you can start this quarter.

Recovery objectives without a business impact analysis

Recovery time and recovery point objectives are often set by the infrastructure team from habit rather than derived from a business impact analysis. ISO/IEC 27002 links ICT readiness to that analysis, so an assessor will ask which business process each ICT service supports and who agreed the numbers. Check that every critical service traces to a documented impact analysis signed by its business owner.

Backups never restored

Many organizations can show a backup job succeeding but cannot show a restore of a production system within its recovery objective. A backup catalog proves that files were written, not that they can be brought back. Schedule restore tests for representative systems and record the elapsed time, the data recovered and any gaps. Tools such as restic can read pack files back with restic check --read-data to confirm stored data is intact, but a full restore test still needs a person to sign it off.

Plans not updated after system changes

A continuity plan written for last year's architecture often omits new platforms, moved data stores or changed failover paths. Assessors compare the plan against the current asset inventory and change records, and a mismatch is a finding even when the plan reads well. Tie plan review to change management so that any change to a critical system triggers an update to its recovery steps. Ask who owns each recovery procedure and when it last changed.

Tests with no recorded results

Teams often run failover exercises but keep no record of scope, participants, outcomes or the problems found. Without that record, an auditor cannot tell whether the test happened, whether it met the objectives or whether findings were fixed. Each test should log what was tested, the measured recovery time, the failures and the owner of each corrective action. Retain the record with the plan so the next test can be compared against it.

Unclear cloud and supplier recovery duties

Recovery responsibilities for cloud services and outsourced platforms are frequently assumed rather than written down. The provider may cover infrastructure resilience while the organization still owns data restoration, configuration and failover decisions. Map each critical service to a responsibility split in the contract or service documentation, and confirm the provider's recovery commitments and notification duties. Where the split is unclear, ask the supplier to state it in writing before the next test.

How much effort, time and outside help does A.5.30 need?

How much does it cost to get ICT readiness for business continuity in place?

No supplied figure sets a price for A.5.30, and DeployOpen does not publish a price list, so the cost depends on your written scope. The main cost components are internal time from the people who own the business impact analysis, the recovery objectives and the systems, plus any tooling, infrastructure and external help you buy. Recurring costs include running backups and monitoring, repeating tests and keeping plans current after changes. Ask any provider for a quote that separates one-time build work from recurring operation and testing, and that lists which systems are in scope.

How long does it take before A.5.30 has usable evidence?

The supplied facts do not give a duration for building ICT readiness, so confirm any timeline against your own environment and the scope agreed in writing. Evidence cannot appear until the business impact analysis sets recovery objectives for each ICT service, the recovery designs exist, and at least one test has run and been recorded. Certification also follows its own cycle: under ISO/IEC 17021-1, a management system certification cycle lasts three years, with at least one audit in every calendar year, so the controls must work over time, not only on the day of the audit.

What does the work need from our team?

A.5.30 needs owners who can make decisions, not only technical staff. Expect input from business continuity leads who own impact analysis, service owners who agree recovery time and recovery point objectives for each ICT service, infrastructure and platform engineers who build and run backup and redundancy, and the people who run tests and record results. ISO/IEC 27002:2022 links ICT readiness to the business impact analysis, so the business side must take part early, or the technical plan will recover the wrong things first.

Can we do A.5.30 in-house without outside help?

Yes, if you have people who can perform the business impact analysis, set recovery objectives, build and operate the recovery mechanisms, and run tests with documented results. Many organizations do this in-house. Outside help is most useful where the team lacks recovery engineering experience, is too busy to run a full test cycle, or needs an independent view of the design. Whichever route you take, the organization owns the control, and the controls must be evidenced in your own environment.

What should an implementation partner do for A.5.30, and what should it not do?

An implementation partner can plan the recovery architecture, deploy and harden self-hosted platforms inside your infrastructure, configure backup and monitoring, document procedures, and prepare the test evidence. The partner should not decide your business continuity objectives, accept risk on your behalf, or claim the control is compliant. DeployOpen prepares systems, controls and evidence for assessment, but it does not issue audit reports, attestations or certifications. Only an independent auditor or certification body can conclude that the control meets ISO/IEC 27001. Agree the division of responsibilities in the written scope.

How does A.5.30 relate to A.5.29 information security during disruption?

A.5.30 covers the ICT readiness that lets systems be recovered when the business needs them, based on continuity objectives. A.5.29 covers how information security is kept at an appropriate level during a disruption, including whether continuity arrangements keep or adapt security controls. In practice, a recovery site or failover path must meet the same confidentiality and integrity expectations as production. Plan them together, and test that recovered systems still have their access controls, logging and backups in place.

What evidence should we expect an auditor to ask for under A.5.30?

Auditors commonly look for the business impact analysis and the recovery objectives derived from it, the ICT continuity requirements, the recovery plans and architecture, records of backup and restore tests, and evidence that the plans are maintained after changes. Restore test records are often the most useful evidence. Tools such as Bareos keep a catalog of backed-up files and can restore from a chosen point in time, and restic's check command can read pack files back to confirm stored data is unmodified. Confirm with your certification body which evidence it expects in your scope.

How DeployOpen prepares ICT readiness evidence for an audit

DeployOpen plans, implements and documents the self-hosted open-source platforms that support ICT readiness for A.5.30, inside your own cloud accounts, data centers or air-gapped networks. We prepare systems and evidence for your assessment, while your organization owns the control and an independent auditor or certification body issues any report or certificate.

How we scope

We agree a written scope before work starts, listing the ICT services, recovery objectives and sites in it.
We confirm with you which business continuity objectives and ICT continuity requirements the readiness work must trace back to.
We record which parts of ICT readiness stay with your staff, such as business impact analysis sign-off and management approval.

How we build

We deploy backup, restore and verification tooling such as Bareos and restic in your environment, with retention set from your agreed objectives.
We configure metrics and alerting with Prometheus and Grafana so that backup and recovery failures reach the people who must act.
We plan recovery tests across the agreed scope and run them with your teams, recording results, gaps and remediation owners.

How we hand over

We deliver configuration records, runbooks, restore test reports and alert definitions that map to the agreed scope.
We provide a readiness evidence pack that your internal owner and your assessor can sample against the live systems.
We walk your teams through the procedures so that ongoing testing and maintenance can run without us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer under a separate written scope.
We can repeat recovery tests on a schedule your organization sets, with each test documented for the next review.
We confirm with your certification body or auditor which evidence formats they accept before the assessment begins.