ISO 27031 ICT Recovery Readiness for an ISO 27001 ISMS

A recovery plan can be complete on paper and still fail when a real disruption removes people, access, suppliers or infrastructure that the plan assumes will be available. ICT recovery readiness is the demonstrated ability to restore the technology services that critical activities depend on, within approved conditions and timeframes.

ISO/IEC 27001 establishes risk-based information-security and continuity expectations. ISO/IEC 27031 provides focused guidance for information and communication technology readiness. The standards are complementary: one governs the ISMS; the other helps design, operate and improve the ICT capability that supports continuity.

Direct answer: Use ISO 27031 to connect business continuity needs to ICT services, dependencies, recovery strategies, exercises and improvement. For audit evidence, show not only a plan but also approved objectives, realistic tests, results, exceptions and closed corrective actions.

Use the current edition

The current edition is ISO/IEC 27031:2025, published in May 2025. ISO’s official ISO 27031 page says it supports ICT readiness aligned with business continuity objectives and covers dependencies on external services, including cloud providers. It replaced the 2011 edition.

This matters when older procedures or training still cite withdrawn clause structures. Do not claim compliance with text you have not licensed or reproduce the standard. Record the edition used, assess the effect of change and update the organisation’s method where necessary.

ISO 27031 is guidance, not a substitute for ISO 27001 or an enterprise-wide business continuity management system. The business continuity, information security and disaster recovery comparison explains their distinct scopes.

Begin with business requirements

Recovery priorities should originate from critical activities, not from whichever system has the most vocal owner. Use business impact analysis, contractual commitments, safety needs, regulatory deadlines and risk assessment to identify:

• maximum tolerable disruption for an activity;
• recovery time objectives for supporting services;
• recovery point objectives for data;
• minimum acceptable capacity during recovery;
• sequence and dependencies between services;
• manual workarounds and their limits; and
• internal and external communication needs.

An RTO is not a promise that every component will return simultaneously. Translate the service objective into component and dependency targets. A customer portal may require identity, network, database, secrets, monitoring and a payment provider before it becomes usable.

The RTO and RPO evidence guide provides a method for defining and testing these objectives.

Map the recovery service, not just servers

Create an end-to-end dependency view for each critical ICT service. Include:

• applications, platforms and data stores;
• identity, keys, certificates and privileged access;
• networks, name resolution and connectivity;
• facilities, power and environmental dependencies;
• cloud, telecom and managed-service suppliers;
• recovery media, replicas and alternate environments;
• people, knowledge and decision authority;
• monitoring, logging and communication channels; and
• upstream inputs and downstream consumers.

Record assumptions such as internet availability, staff location, vendor access and the integrity of administration devices. A dependency map is useful only if owners validate it after architecture and supplier changes.

Select strategies by failure mode

One recovery strategy rarely covers every scenario. Design for credible loss conditions, including corruption, destructive attack, regional outage, supplier failure, unavailable premises, loss of key staff and failure of the recovery mechanism itself.

Possible strategies include redundant capacity, alternate processing, isolated recovery environments, immutable copies, manual workarounds, replacement services or an orderly degradation of features. Evaluate each against:

• the recovery objective it supports;
• activation authority and decision time;
• data currency and integrity validation;
• capacity and performance;
• geographic or supplier concentration;
• security controls during degraded operation;
• return-to-normal steps; and
• cost and residual risk.

The recovery-site selection guide covers distance, shared dependencies, access and evidence for alternate locations. For cloud services, avoid assuming that high availability automatically provides recoverability from corruption or account compromise.

Write executable procedures

Procedures should help authorised people act under pressure. For each scenario or service, state:

1. detection and declaration criteria;
2. activation authority and contacts;
3. safety and evidence-preservation considerations;
4. containment or isolation steps;
5. recovery sequence and dependencies;
6. access, credentials and break-glass controls;
7. data restoration and integrity checks;
8. functional and security acceptance criteria;
9. stakeholder communications;
10. return-to-normal and reconciliation; and
11. record capture and post-event review.

Avoid embedding rapidly changing details in an uncontrolled document. Link to maintained inventories, contact sources and automation repositories, but confirm those sources are available during the disruption.

Protect recovery capability

Recovery mechanisms are themselves security assets. Restrict and monitor administrative access, separate recovery credentials where appropriate, protect copies from alteration, test restore paths and ensure logging remains available.

Consider whether an attacker who compromises production can also delete replicas, change infrastructure code, disable monitoring or obtain the recovery credentials. Separate failure domains and approval paths according to risk.

The free Annex A Control Lookup can help teams review related ISO 27001 controls. Control selection must still follow the organisation’s risk-treatment process and Statement of Applicability.

Exercise progressively

Use an exercise programme that increases realism without creating uncontrolled business risk.

Exercise type	Primary purpose	Evidence
Walkthrough	Validate roles, sequence and assumptions	Scenario, attendance, decisions, issues
Component restore	Prove data or a component can be recovered	Logs, timing, integrity checks
Service recovery	Validate an end-to-end service	Dependency results, functional tests
Supplier exercise	Test coordination and external commitments	Notices, response times, joint actions
Failover and return	Prove alternate operation and controlled restoration	Capacity, security, reconciliation, approval

Set pass criteria before execution. Record actual start time, declaration delay, recovery milestones, achieved data point, capacity, defects and deviations. A successful test with undocumented results provides weak assurance.

The business continuity plan activation guide helps distinguish an exercise from a controlled response to a real event.

Sample operating evidence

An auditor can select two or three critical services with different architectures and examine:

• approval of business and ICT recovery objectives;
• dependency mapping and recent change history;
• current recovery strategy and residual-risk approval;
• latest restore or recovery exercise;
• achieved timing and data integrity;
• failed steps, workarounds and exceptions;
• supplier participation where relevant;
• action ownership, due dates and closure; and
• evidence that lessons changed plans, architecture or training.

Then trace one infrastructure change into recovery documentation and testing. This tests whether readiness is maintained, not merely demonstrated once.

Judge pass, partial and fail conditions

Pass: Objectives derive from business needs, dependencies are current, strategies cover credible failure modes, exercises use defined criteria, and corrective actions close with verification.

Partial: Plans and backups exist, but tests cover isolated components, supplier assumptions are untested or exercise findings remain open beyond agreed dates.

Fail: Recovery targets have no business approval, critical credentials or copies share the same failure domain, or the organisation cannot show that a critical service has been recovered.

Treat readiness as an operating capability

Review ICT readiness after significant architecture, supplier, threat or business change—not only at the annual exercise. Use incidents, near misses, monitoring and exercises as evidence for improvement.

The goal is not a perfect document. It is a controlled capability that can make decisions, restore trustworthy services and demonstrate that recovery remains aligned with business need.