Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Organisational Control

A.5.30 — ICT Readiness for Business Continuity

Updated on 4 min Reviewed by: Cenedril Editorial
A.5.30 ISO 27001ISO 27002BSI DER.4BSI-Standard 200-4

The business continuity plan promises recovery of the ERP system within four hours. When the storage array fails, the IT team discovers that the last successful backup is three days old and the restore procedure has never been tested on the current hardware. The four-hour target becomes four days. A.5.30 prevents this mismatch by requiring that ICT readiness is planned, implemented and tested against defined recovery objectives.

Business continuity plans are only as good as the technology that supports them. A.5.30 focuses specifically on ensuring that ICT infrastructure, systems and services can be recovered within the timeframes the business requires — and that this capability is verified through regular testing.

What does the standard require?

  • Conduct a business impact analysis (BIA). Identify which ICT services support critical business processes and determine the recovery time objectives (RTO) and recovery point objectives (RPO) for each.
  • Plan ICT continuity. Develop continuity plans that describe how each critical ICT service will be recovered within its RTO and RPO. Plans must cover infrastructure, applications, data and the personnel needed for recovery.
  • Implement recovery capabilities. Ensure that the technical infrastructure (backups, redundancy, failover mechanisms) is in place to meet the defined recovery objectives.
  • Test and exercise. Regularly test ICT continuity plans under realistic conditions. Verify that systems can actually be restored within the target timeframes.
  • Review and update. Plans are reviewed after significant changes to infrastructure, applications or business requirements and after every test or actual disruption.

In practice

Start with the BIA. The business impact analysis identifies which processes are critical and which ICT services they depend on. For each critical service, the business defines how long it can tolerate an outage (RTO) and how much data loss is acceptable (RPO). These numbers drive all subsequent technical decisions.

Build a recovery architecture that matches the targets. If the RTO for the ERP system is four hours, the recovery mechanism must demonstrably achieve four hours. This might require hot-standby systems, automated failover or pre-staged replacement hardware. Document the architecture and its relationship to the recovery targets.

Maintain a disaster recovery register. List every critical ICT system, its RTO, its RPO, the recovery mechanism in place, the last test date and the test result. This register is a central steering tool and a key audit artefact.

Test under realistic conditions. A restore test in a lab environment validates the procedure. A failover test under production-like load validates the capacity. An integrated exercise with business users validates the end-to-end process. Conduct all three types over the annual cycle.

Typical audit evidence

Auditors typically expect the following evidence for A.5.30:

  • Business impact analysis — documented analysis of critical processes, their ICT dependencies, and defined RTO/RPO values
  • ICT continuity plans — detailed recovery procedures for each critical system
  • Disaster recovery register — overview of critical systems, recovery targets, mechanisms and test status
  • Test reports — evidence of regular recovery tests with measured recovery times and identified improvements
  • Infrastructure documentation — architecture diagrams showing redundancy, failover mechanisms and backup infrastructure

KPI

% of critical ICT systems with documented and tested continuity plans

This KPI measures operational readiness. A system counts as covered only if it has both a documented continuity plan and a successful test within the defined interval (typically 12 months). Target: 100% of critical systems.

Supplementary KPIs:

  • Percentage of systems meeting their RTO in the last recovery test
  • Percentage of systems meeting their RPO in the last recovery test
  • Average age of the most recent successful restore test per critical system

BSI IT-Grundschutz

A.5.30 maps to the BSI framework for business continuity management:

  • DER.4 (Business continuity management) — requires business impact analysis, continuity planning and regular testing for critical IT services.
  • BSI-Standard 200-4 — provides comprehensive guidance on BCM including ICT continuity, BIA methodology and exercise planning.

A.5.30 provides the technical foundation for business continuity:

Sources

Frequently asked questions

What is the difference between RTO and RPO?

Recovery Time Objective (RTO) defines the maximum acceptable downtime before a system must be restored. Recovery Point Objective (RPO) defines the maximum acceptable data loss measured in time -- e.g. an RPO of 4 hours means the organisation accepts losing up to 4 hours of data. Both values are derived from the business impact analysis.

How often should ICT continuity plans be tested?

At least annually for critical systems. Tests should include both technical recovery tests (actually restoring systems from backups) and integrated exercises (combining ICT recovery with business continuity scenarios). After significant infrastructure changes, additional tests are advisable.

Does A.5.30 require a separate data centre?

The standard does not prescribe a specific architecture. It requires that ICT readiness meets the recovery objectives defined by the business. For some organisations, a second data centre is necessary; for others, cloud-based failover or a well-tested backup restoration procedure is sufficient. The deciding factor is whether recovery targets can be met.