ISO/IEC 27001:2022 · derived mapping target
A.5.30ICT readiness for business continuity
Make sure your IT systems can recover and keep running to meet business continuity goals, with tested plans and adequate capacity. Continuity targets are only credible if the technology can deliver them.
Mapping at a glance
A.5.30ICT readiness for business continuityISO/IEC 27001:2022
A.5.30 is covered by 27 Sekit CSF controls. +22 more in the table below. Open in the full graph →
Mapped from the Sekit CSF
The Sekit controls that cover this requirement, lens by lens.
RCF-0250RTO/RPO definitions · PolicysupportsDefining maximum tolerable downtime and data loss for each critical system is the business continuity target that ICT readiness must be built to meet, not the delivery capability itself.RCF-0251RTO/RPO definitions · ProcesssupportsUsing agreed recovery time and data-loss targets to drive backup schedules keeps ICT recovery planning tied to real business needs.RCF-0252RTO/RPO definitions · TechnicalsupportsBuilding backup and recovery architecture that demonstrably hits documented RTO and RPO targets covers the technical layer this control needs, but not the continuity plans and capacity management it also requires.RCF-0253DR exercises · PolicysupportsA written commitment to exercise disaster recovery on a fixed schedule is how the ICT readiness this control requires gets tested rather than assumed.RCF-0254DR exercises · ProcesssupportsRunning disaster recovery exercises on schedule and feeding failures back into the plan tests part of ICT readiness, but exercising alone does not prove the underlying architecture or capacity can meet the recovery targets.RCF-0255DR exercises · TechnicalsupportsA technical means to rehearse recovery in an isolated environment lets DR exercises run realistically without risking production systems.RCF-0256Runbooks for recovery · PolicysupportsDocumented step-by-step recovery procedures for every critical system failure are the operational detail this control needs underneath a high-level continuity plan.RCF-0257Runbooks for recovery · ProcesssupportsKeeping recovery runbooks current with system changes and following them during incidents is what turns documented ICT readiness into recovery capability.RCF-0274Tabletop exercises · PolicyrelatedA written commitment to run simulated incident exercises overlaps with ICT readiness testing, though its primary scope is incident response rather than recovery capability.RCF-0280Business impact analysis · PolicysupportsNaming which systems matter most and how fast each must be restored gives ICT readiness planning its priorities.RCF-0281Business impact analysis · ProcesssupportsRefreshing the business impact analysis as systems change keeps ICT recovery priorities matched to what the business depends on.RCF-0282Business impact analysis · TechnicalenablesDependency mapping tooling such as an asset inventory or lightweight CMDB gives the impact analysis behind ICT readiness a factual basis instead of memory.RCF-0283Continuity plans · PolicysupportsApproved plans for maintaining critical operations during a disruption set the scope that the ICT recovery capability in this control must be able to support.RCF-0284Continuity plans · ProcesssupportsReviewing continuity plans after every significant change keeps the ICT recovery targets in those plans from drifting out of date.RCF-0285Continuity plans · TechnicalsupportsKeeping continuity plans reachable when primary systems are down, through offline copies or a separate tenant, is part of the ICT readiness this control expects.RCF-0286Crisis management · PolicyrelatedA crisis management framework naming who leads during a disruption supports ICT recovery decisions but is broader than the technical readiness this control covers.RCF-0288Crisis management · TechnicalrelatedAn out-of-band communication channel for the crisis team is adjacent infrastructure that keeps coordination possible while ICT systems are being recovered.RCF-0289Alternate work sites · PolicyrelatedA policy on where staff work if the office is unavailable depends on the ICT systems this control covers being reachable from those alternate locations.RCF-0290Alternate work sites · ProcessrelatedExercising alternate work site arrangements tests whether the ICT infrastructure this control covers supports staff working from elsewhere.RCF-0291Alternate work sites · TechnicalsupportsSecure remote access sized for the whole company to work off-site at once is ICT infrastructure that must hold up as part of this control's readiness requirement.RCF-0292BCP exercises · PolicyrelatedA recurring schedule of continuity exercises with named scenarios overlaps with the DR testing this control requires, viewed at the wider business level.RCF-0293BCP exercises · ProcessrelatedRunning planned continuity exercises and feeding lessons back into the plan reinforces the same tested-readiness principle this control applies specifically to ICT.RCF-0294BCP exercises · TechnicalsupportsBackup restore sandboxes and cloud failover test features are technical means that let this control's readiness be rehearsed realistically.RCF-0406SRE/Resilience practices · PolicysupportsA written commitment to reliability engineering practices, with defined service level objectives, gives ICT readiness a standard to be measured against beyond disaster scenarios alone.RCF-0407SRE/Resilience practices · ProcesssupportsTracking reliability targets and error budgets so they genuinely steer priorities keeps day-to-day ICT resilience work funded, not only the disaster recovery plan.RCF-0409Availability management · PolicysupportsWritten availability targets for every critical service, agreed with management, define what this control's ICT readiness is trying to protect.RCF-0412Capacity & performance mgmt · PolicysupportsDocumented capacity planning for compute, storage and connectivity keeps ICT systems from failing under load, a form of readiness this control expects alongside disaster recovery.
NIST CSF 2.0 counterparts
Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.
Cyber Essentials counterparts
Evidence that proves this control
What an auditor, or Sekit's evidence engine, asks for.
Backup configuration and restore-test record
How backups are made (what is backed up, how often, where they are stored) and the proof that a restore has been tested successfully.
Disaster recovery plan and runbooks
The plan defining how long each critical system can be down (RTO/RPO) and the step-by-step guides to recover it after a serious failure.
Availability and capacity management
How the company ensures its critical services are available as expected, plans their capacity, and prevents problems from recurring.
From the Sekit evidence catalog
In practice
ICT readiness is the plumbing behind a continuity plan: a backup that has never been restored, or a failover architecture nobody has tested end to end, is a paper promise. Recovery runbooks that get followed step by step during an outage, not read for the first time under pressure, are what separates a recovery that finishes on schedule from one that drags on for days. Auditors look for a restore test record with a date, not a policy stating tests should happen. Reliability targets and error budgets that genuinely influence whether the team ships new features or fixes stability issues show the recovery capability is a live priority, not a document.
Common gaps
Backups run every night, but nobody has restored from one recently to confirm the data comes back intact.
The disaster recovery plan states a target recovery time, but the last failover test took far longer than that target allowed.
Recovery runbooks reference systems that were decommissioned last year and have not been updated since.
Questions your auditor will ask
When was disaster recovery last tested end to end?
The most recent DR exercise report names the date, scope and outcome, including whether the recovery time target was met.
How do you know the recovery runbooks still match the current systems?
Runbooks are reviewed and updated whenever the underlying systems change, not on a fixed calendar alone.
What happens when reliability targets are missed?
Error budget tracking triggers a documented shift toward stability work over new features when targets slip.
Is there enough capacity to handle expected growth without an outage?
Capacity planning documents current usage against forecast demand for compute, storage and connectivity, reviewed on a recurring cycle.
Where regulation demands it
NIS2 4.2 requires backup and redundancy management, which is the technical foundation this control's recovery capability depends on.
ENS op.pl.4 requires capacity management, matching this control's expectation that ICT systems are sized to meet business continuity targets.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.5.30?”
Also via MCP, free with account