Control Definition
ICT readiness must be planned, implemented, maintained, and tested against requirements derived from the organization's business continuity objectives — so the systems that carry critical information can be kept available, or recovered within agreed timeframes and data-loss limits, when disruption strikes.
Control Objective
To ensure information and the ICT services that process it remain available — or are recovered fast enough — to meet the recovery objectives the business has committed to.
What This Really Means
Business continuity makes promises; A.5.30 asks whether your technology can keep them. The business says order processing must be back within four hours with no more than fifteen minutes of data lost — this control is the chain of proof behind that sentence: requirements derived from a business impact analysis, an architecture engineered to meet them, plans and people ready to execute, and tests showing the numbers are real. A.5.30 is one of the 11 controls introduced in the 2022 revision — the 2013 edition treated continuity mainly as keeping security going through a crisis (now A.5.29) and never squarely required ICT recoverability itself. The 2022 edition closed that gap and, in doing so, built the ISMS bridge to ISO 22301, the dedicated business continuity standard.
The numbers come from the business, not from IT. The business impact analysis identifies critical processes and how much downtime and data loss each can tolerate; the ICT services underneath each process then inherit two figures: an RTO — recovery time objective, how quickly the service must be restored — and an RPO — recovery point objective, how much data, measured in time, the business can afford to lose. Those figures cascade directly into engineering. Backup frequency must beat the RPO (A.8.13 — a nightly backup cannot deliver a fifteen-minute RPO), and the failover design must beat the RTO (A.8.14 — restore-from-backup cannot deliver a five-minute RTO). Tiering keeps this affordable: minutes-level objectives for the revenue path, days-level for the intranet, with the cost of each tier a management decision made in daylight.
Readiness is organizational as much as architectural. The control expects a structure with competent people prepared to respond to ICT disruption, recovery plans approved by management, and runbooks that are executable under stress — including the dependency map nobody thinks about until restoration stalls: identity providers, DNS, secrets management, licensing services, third-party APIs. A restored application that cannot authenticate its users is not recovered, whatever the infrastructure dashboard says, so the recovery sequence restores foundations first.
Testing is the heart, because an untested DR plan is a hypothesis. The control expects a cadence — restore tests of backups, component failovers, periodic fuller exercises — with results documented and measured against the stated RTO and RPO, and misses treated as corrective actions. That trace is exactly what auditors follow: from BIA to objectives to architecture to test results. A claimed four-hour RTO sitting next to a test that took eleven hours, with no corrective action in sight, is the finding writing itself.
Why It Matters
The gap between assumed and actual recoverability is one of the most expensive surprises in technology, and it is usually discovered during the disaster itself: backups that never restored cleanly at scale, failover that was never exercised end to end, dependencies that appear in no plan. Ransomware turned this from an availability concern into an existential one — when an attacker encrypts production, tested and isolated recovery capability is the entire difference between restoring your data and negotiating for it.
Recoverability is also a commitment others are relying on. Customer SLAs, supplier obligations, and regulator expectations all assume your recovery objectives are real, and because A.5.30 is new in the 2022 revision, certification auditors probe it deliberately — organizations that transitioned from the 2013 standard often mapped it to an old backup policy and moved on, which the first request for test results exposes immediately.
Where ICT readiness is assumed rather than tested, organizations face:
- •Paper promises the architecture cannot keep – a four-hour RTO backed by nightly backups and no standby is a twenty-four-hour reality nobody has admitted to the business
- •Backups that fail their first real restore – corruption, missing scopes, and never-rehearsed procedures surface at the worst possible moment
- •Ransomware without a fallback – when recovery capability is absent, or encrypted along with production, the ransom becomes the recovery plan
- •Hidden dependencies that stall everything – restored applications that cannot authenticate, resolve names, or fetch secrets are not recovered, whatever the dashboard says
- •Breached SLAs and regulatory exposure – missed recovery commitments cascade into customer penalties and, for regulated entities, supervisory findings
Regional Compliance Context
For regulated financial entities in India, recovery capability is supervised, not voluntary: RBI master directions treat documented recovery objectives and regular DR drills for critical systems as standing expectations, and SEBI's CSCRF carries comparable resilience and testing requirements for market intermediaries. Align the ISO 27001 evidence with what the sector regulator already demands — one BIA, one set of RTO/RPO commitments, one testing calendar — so a single body of work serves both the certification audit and the supervisory inspection.
Implementation Guidance
Start from the Business Impact Analysis
Identify critical business processes, map the ICT services each one stands on, and capture from process owners how much downtime and data loss the business can actually tolerate. If no BIA exists, run a lightweight one — a structured set of interviews and a prioritized service list is enough to start. The control's numbers have no other legitimate source; RTOs invented inside IT are guesses wearing a suit.
Set an RTO and RPO for Every Critical ICT Service
Translate business tolerances into per-service recovery time and recovery point objectives, recorded in a recovery requirements register or service catalog and approved by management. Tier the estate rather than gold-plating it — for example Tier 1 in minutes-to-hours, Tier 2 in hours-to-a-day, Tier 3 in days — so investment lands where downtime genuinely hurts.
Map the Dependencies That Recovery Will Stand On
For each Tier 1 service, document the hidden prerequisites: identity provider, DNS, secrets management, networking, licensing servers, message queues, and third-party APIs. Sequence the recovery so foundations restore and verify first — applications cannot come back before the things they authenticate against. Capture critical suppliers' recovery commitments too, because your RTO silently inherits theirs.
Architect Each Tier to Meet Its Numbers
Choose recovery patterns per tier: plain backup-and-restore, pilot light, warm standby, or active-active across sites or regions. Verify the arithmetic honestly — backup frequency and replication lag must beat the RPO (A.8.13), and the failover mechanism must beat the RTO (A.8.14) including detection and decision time, not just the technical switchover. Document the expected recovery profile per service and put the gaps in front of management.
Write Executable Recovery Runbooks and Staff Them
Produce management-approved ICT continuity plans containing step-level runbooks: actions, owners, decision points, verification checks, and the capacity and performance the recovered state must deliver. Name recovery roles with deputies and train them — recovery at 3 a.m. is performed by whoever is on call, not by the architect who designed it. Keep offline copies; the plan must survive the outage it exists for.
Test on a Cadence and Measure Against the Objectives
Run a standing test program: restore tests of critical backups (quarterly is a common cadence), component failovers in maintenance windows, and at least an annual fuller exercise for Tier 1 services. Record actual recovery time and data loss against the stated RTO and RPO every time, and treat misses as corrective actions with owners and dates — a missed objective quietly tolerated is a commitment silently withdrawn.
Keep Readiness Current Through Change
Make recovery impact a mandatory consideration in change management for in-scope systems, so RTO/RPO values, runbooks, and dependency maps get reviewed when the architecture moves. Reassess after major changes, supplier switches, and shifts in business priority, and report readiness metrics — test results, coverage, open gaps — into management review. If you operate a formal BCMS under ISO 22301, run this control as its ICT chapter rather than a parallel universe.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.30:
Documentation
- Business impact analysis identifying critical processes and the ICT services that support them
- Recovery requirements register or service catalog recording RTO and RPO per ICT service, approved by management
- ICT continuity and DR plans with runbooks, dependency maps, recovery sequences, and required capacity information
- DR test, failover, and restore-test reports showing measured recovery times and data loss against the stated objectives
- Corrective action records for tests that missed their objectives, traced to architecture or procedure changes
Interviews
- CISO or head of infrastructure on how RTO and RPO values were derived from business requirements and what the last test demonstrated
- Platform or operations engineers on executing a failover or restore — probing whether the runbooks match what they actually do
- A business process owner on whether the stated recovery objectives reflect real tolerance for downtime and data loss
Observations
- The recovery architecture inspected live: replication status, standby environments, and backup job health against the stated RPOs
- A restore test or component failover demonstrated, or its recorded execution walked through step by step against the runbook
- The most recent DR exercise results compared with the declared RTO/RPO and the closure of the actions it raised
Practitioner Insights
A.5.30 is where 2013-to-2022 transitions show their seams: organizations mapped the new control to their old backup policy, ticked the Statement of Applicability, and moved on. A certification auditor does something very simple here — asks for your stated RTO and RPO, then asks for the last test results, and lays them side by side. Objectives that have never been tested are a finding; a test that missed with no corrective action behind it is a worse one. Run that comparison on yourself before the audit, and where a gap is not yet funded, have management formally accept it — an honest, risk-accepted gap defends far better than a number nobody can support.
Cloud-native teams routinely tell me their provider is the DR plan. Multi-zone resilience is real, but it does not restore the database your own migration script just dropped, undo a deleted storage bucket, or save you from ransomware that encrypted with valid credentials — the provider keeps the infrastructure alive; your data and configuration remain your problem. The credible minimum for a small team fits on a few pages: honest RTO/RPO numbers per critical service, a quarterly restore test of the crown-jewel data with the duration written down, and one failover runbook that somebody other than its author has executed. Small scale shrinks the evidence, not the need for it.
Common Challenges & Solutions
Challenge
RTO and RPO numbers were invented inside IT — or set to "zero downtime" — without the business ever weighing cost against tolerance.
Solution
Run a lightweight BIA conversation with each process owner: what does an hour, a day, a week of outage cost, and how much rework is survivable? Tier services from those answers, price the architecture per tier, and put the trade-off to management explicitly. A signed-off four-hour RTO beats an aspirational zero that no budget supports.
Challenge
Backups run nightly and report green, but a full-system restore has never been attempted.
Solution
Schedule restore testing as a standing control: file-level restores frequently, full-system restores of Tier 1 services at least annually, with measured duration compared against the RTO. Keep at least one backup copy isolated or immutable so ransomware cannot encrypt the recovery path along with production, and treat any failed or slow restore as a corrective action with an owner.
Challenge
Full DR exercises keep being deferred because nobody will risk breaking production to run one.
Solution
Use a graduated ladder: tabletop walkthroughs first, then component failovers in maintenance windows, then full recovery into an isolated environment — cloud tooling makes parallel-environment testing cheap enough to remove the excuse. Book the exercise into the ISMS annual calendar with an executive sponsor, and report completion or slippage at management review.
Challenge
Recovery stalls on hidden dependencies — restored applications cannot authenticate, resolve DNS, or reach the secrets vault.
Solution
Map dependencies for every Tier 1 service before the architecture is tested: identity, DNS, secrets management, networking, licensing, and third-party APIs, each with its own position in the recovery sequence. Restore foundations first and verify them before applications. Include critical suppliers' recovery commitments in due diligence — their outage is your outage.
Challenge
The DR plan was accurate two years ago, and the architecture has changed beyond recognition since.
Solution
Make recovery impact a mandatory field on change requests for in-scope systems, so objectives and runbooks get reviewed when the architecture moves. Define the recovery environment as infrastructure-as-code so it tracks production by construction rather than by memory. Review the full plan at least annually and after major changes, and track plan currency as a readiness metric at management review.
