ICT Readiness for Business Continuity - ISO 27001 Annex A Control

ISO 27001 Annex A 5.30

An untested recovery arrangement is a hope, not a control.

ISO 27001 Annex A 5.30 - ICT Readiness for Business Continuity

Most modern business continuity scenarios have an ICT component. The control sits at the intersection of business continuity and ICT, asking the organisation to make sure its technology services can support the continuity objectives. That means the right systems are in place, the recovery times match the business need and the arrangements have been tested often enough to know they work.

The starting point is the business impact analysis. For each business activity, what ICT services support it, how quickly do they need to be restored after disruption, and how much data loss is tolerable. Those answers become the recovery time and recovery point objectives that drive the technical arrangements - failover, backups, alternative working arrangements, redundant suppliers.

Testing is non-negotiable. An untested recovery plan is a hope, not a plan. The depth of testing scales with the criticality - critical services may warrant full failover testing, less critical services may need only periodic restore testing or walk-through. Whatever the depth, the test outcomes need to be recorded and gaps fed back into the plan.

We test backups by restoring them, not just by checking that the backup job ran. A successful backup job that cannot be restored is a backup that does not exist. Quarterly restore tests catch the issues that pure backup monitoring misses, and they give us confidence the recovery would actually work.

For cloud services we rely on the provider's continuity arrangements but we test the bits we control - data extraction, alternative access routes and the exit plans we hold in the cloud register.

Practical Compliance Guidance

ICT readiness for business continuity is described in the IMS1 manual at section 8.2 on information security arrangements and section 8.3 on IT equipment. The business continuity register and the cloud register hold the practical record.

alphaZ document How to use it
ISO 27001 Toolkit The full alphaZ ISO 27001 toolkit covering manual, policies, procedures, registers and audit checklists.
F-Q108 Cloud Emergency Exit Planning The exit planning form for cloud services. Use to document data extraction routes, transition arrangements and continuity provisions for each cloud service in scope.

Note - all the above files can be downloaded with an alphaZ subscription.

Frequently Asked Questions

RTO is recovery time objective - how long after disruption a service must be restored. RPO is recovery point objective - how much data loss is tolerable, expressed as the maximum gap between the most recent restorable backup and the point of failure. Both come from the business impact analysis and drive the technical recovery arrangements.
At a frequency proportionate to the criticality. Critical systems should typically have a full failover or restore test at least annually. Less critical systems may need only basic restore verification on a defined schedule. Cloud services with provider-managed continuity may rely on supplier evidence rather than direct testing.
Backup arrangements should follow good practice for separation - copies in different locations, copies on different media, copies that are not online and therefore protected from ransomware. The exact pattern depends on the data and the threats, but the principle is that no single failure should remove access to all recovery options.

Further Resources

payment logos