ISO/IEC 27031: Making ICT Ready to Support Business Continuity

Most business continuity plans assume that IT will be available, or recoverable within a number someone wrote down years ago, and nobody has proved that the systems, people and suppliers behind that number can actually deliver it. ISO/IEC 27031 closes that gap. It describes ICT readiness for business continuity (IRBC): the methods and processes an ICT function uses to plan, prepare and prove that it can keep supporting critical activities through a disruption. This guide explains what the 2025 second edition covers, how it sits beside ISO 22301 and ISO/IEC 27001, the identity and machine credential dependencies that most recovery plans miss, and how to implement and evidence it. It is written for IT continuity and disaster recovery leads, ISMS managers, infrastructure and cloud architects, and auditors. It describes the standard from its official catalogue entries and does not reproduce its text.

Key takeaways

• The current edition is ISO/IEC 27031:2025. Edition 2, published in May 2025 by ISO/IEC JTC 1/SC 27, titled "Cybersecurity, Information and communication technology readiness for business continuity". It replaced the 2011 first edition.
• It is guidance, not a certifiable standard. You certify a management system against ISO 22301 or ISO/IEC 27001; ISO/IEC 27031 explains how the ICT side of continuity should be planned and proven.
• Three objectives drive everything. The catalogue abstract names the minimum business continuity objective (MBCO), recovery point objective (RPO) and recovery time objective (RTO) as the business continuity objectives for ICT.
• All causes, not only cyber attacks. The scope covers deliberate and accidental disruption, from ransomware to a failed data centre cooling system or a cloud region outage, and dependencies on third parties such as cloud providers.
• Identity is the hidden single point of failure. If the identity provider, the secrets vault or the certificates that services use to authenticate cannot be recovered first, every other RTO in the plan is fiction.

What it is and who it applies to

According to the ISO and IEC catalogue entries (checked 8 November 2026), ISO/IEC 27031:2025 explains the concepts and principles of IRBC and provides a framework of methods and processes to identify and specify how an organisation improves its ICT readiness so that business continuity is maintained. It applies to organisations of any type and size and describes how ICT departments plan and prepare to support organisational resilience objectives.

• Who should use it: organisations that run or depend on ICT for critical activities and already have, or are building, a business continuity management system (BCMS) under ISO 22301 or an ISMS under ISO/IEC 27001.
• Who it helps most: the ICT team that must translate business recovery expectations into architecture, runbooks and tests, and the auditor who must decide whether those expectations are realistic.
• What it is not: it does not replace a BCMS, and it is not a technical disaster recovery manual for any platform. Pair it with the ISO 22301 Business Continuity Guide for the management system and the Business Continuity and Disaster Recovery Guide for practice.

Structure and key requirements

The independent ISO27k summary at iso27001security.com outlines the standard's main clauses as integration of IRBC into business continuity management, business expectations for IRBC, prerequisites, IRBC strategies, the ICT continuity plan, testing, exercise and auditing, the final MBCO, and top management responsibilities for evaluating IRBC, with annexes comparing RTO and RPO with business objectives and on risk reporting using failure mode and effects analysis (FMEA). The same summary notes that the approach follows a Plan-Do-Check-Act cycle. Confirm clause numbering against your purchased copy before citing it in audit findings.

The three ICT continuity objectives

The definitions above are the widely used business continuity meanings; the standard's own definitions should be checked in the text. The useful discipline is the comparison the standard asks for: what the business expects against what ICT can demonstrably deliver, with the gap either funded or formally accepted.

From expectation to proven capability

• Business expectations: take critical activities, MBCO, RTO and RPO from the business impact analysis. See the Business Impact Analysis Template.
• Prerequisites: know the ICT services, components and dependencies that support each critical activity, including suppliers, facilities, people and skills.
• Strategies: choose resilience options per service (redundancy, alternate sites, cloud region failover, immutable backup, manual workarounds) that close the gap at an acceptable cost.
• ICT continuity plan: document who invokes recovery, in what order services return, and how each step is verified.
• Test, exercise and audit: prove the plan against the objectives and record measured recovery times, not planned ones.
• Top management evaluation: leadership reviews IRBC performance and accepts residual gaps explicitly.

Identity and NHI requirements

ISO/IEC 27031 is technology-neutral, but the dependency analysis it requires exposes identity as the service everything else waits for. Recovery order matters: applications cannot start if they cannot authenticate to their database, fetch a secret or present a valid certificate.

• Put identity first in recovery order: the ICT continuity plan should restore directory, MFA, vault and PKI before line-of-business applications, and the RTOs of those core services must be shorter than any RTO that depends on them.
• Prove break-glass works without the IdP: see the Break-Glass Account Guide and the IdP configuration backup and restore for Entra ID and Okta.
• Isolate backup identities: see the Backup Identity Isolation Guide.
• Know what each machine credential unlocks: the Service Account Inventory Template gives the dependency fields a continuity plan needs.
• After a cyber incident, restore is not enough: credentials that were valid before the attack may be in the attacker's hands. Recovery steps should include rotating service account passwords, API keys and signing keys before reconnecting restored systems. See the Secrets Management Guide.

Implementation steps

1. Anchor in the BCMS. Agree with the business continuity owner that IRBC is the ICT stream of the BCMS, using the same impact analysis, risk scale and governance. Do not create a parallel programme.
2. Collect business expectations. For each critical activity, record MBCO, RTO and RPO from the business impact analysis. Where the analysis is missing or stale, refresh it before designing anything.
3. Map ICT dependencies. Build a service map per critical activity: applications, data stores, network, identity, secrets, certificates, facilities, cloud services and suppliers. Mark shared services, which carry the shortest RTO of anything that depends on them.
4. Assess capability and gap. For each service, record current recovery capability as measured in the last test. Compare with the objective. Use FMEA or an equivalent method to rank failure modes by likelihood, impact and detectability.
5. Select strategies. Choose per service: active-active, warm standby, cold standby, backup and restore, or manual workaround. Include supplier commitments and exit options for cloud and SaaS dependencies.
6. Write the ICT continuity plan. Invocation criteria and authority, recovery order, runbooks per service, verification steps, communication, and the decision to return to normal operations. See the Disaster Recovery Plan Template.
7. Test in rings. Start with walkthroughs and tabletops, then component restores, then full service failover in a maintenance window, then unannounced exercises. Keep a rollback path for every failover test: a documented failback with its own success criteria. See the Cyber Incident Exercises Beyond Tabletop Guide.
8. Report and accept. Present measured results against objectives to top management; fund the gaps or record formal acceptance of residual risk with an owner and review date.
9. Maintain. Re-test after major changes (new cloud region, IdP migration, data centre exit) and at least annually; feed results into the next impact analysis cycle.

Decision guidance

• Small organisations: focus on a short list of critical services, the IdP and backups. Cloud and SaaS reduce infrastructure work but move the dependency to suppliers: record each provider's documented resilience commitments and your own workaround if they fail.
• Large organisations: the hard part is shared services and change. Make dependency mapping part of architecture review so new systems inherit recovery requirements, and run recovery tests by service chain, not by application.
• Regulated financial entities in the EU: DORA sets binding ICT business continuity and testing duties; ISO/IEC 27031 is a useful method for meeting them but is not a substitute. See the DORA Guide.
• Warm standby or backup and restore: choose standby where the RTO is shorter than a realistic restore time measured in tests; choose restore where cost matters more and the RTO allows hours or days. Measure restore time with production data volumes.

Evidence and assessment

There is no ISO/IEC 27031 certificate. Assessors look for IRBC evidence during ISO 22301 or ISO/IEC 27001 audits (ISO/IEC 27001:2022 Annex A control 5.30, ICT readiness for business continuity, is the direct hook), regulator reviews and customer due diligence.

Metrics

• Objective coverage: percentage of critical activities with a tested recovery capability that meets RTO and RPO.
• Measured against planned RTO: ratio of actual recovery time in the latest test to the objective, per service.
• Restore success rate: share of test restores that produced usable, verified data at the expected recovery point.
• Dependency map currency: percentage of critical services whose dependency map was reviewed in the last 12 months.
• Identity recovery time: time to restore directory, MFA, vault and PKI in the latest exercise.
• Action closure: percentage of test findings closed by their due date.

Mapping to other frameworks

ISO/IEC 27031 supplements, and does not replace, a BCMS. The table shows where IRBC activities land in common frameworks. CSF 2.0 and SP 800-53 identifiers were checked against the official NIST datasets.

NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems (final, 2010), covers similar ground for system-level contingency plans and supplies a business impact analysis template; it is older but still useful for runbook structure. CIS Controls v8.1 Control 11 (Data Recovery) covers the backup portion. See the ISO 27001 Certification Guide and the Cyber Resilience Guide.

Common pitfalls

• RTOs nobody has measured. Objectives copied from a template, with no test that shows the service can return in time. The first real outage becomes the test.
• Application-level plans that ignore shared services. Every application has a four-hour RTO, but the directory, DNS and vault they all need have no plan at all.
• Backups that share an identity plane with production. Ransomware operators who reach domain admin routinely target backup consoles. Restores fail exactly when they are needed.
• Cloud treated as automatically resilient. A single-region deployment, or a SaaS supplier with no tested exit, carries the same continuity risk as a single data centre, with less visibility.
• Restoring compromised credentials. After a cyber incident, systems restored from backup come back with the same service account passwords and keys the attacker stole.
• No MBCO. Without an agreed minimum service level, ICT plans full restoration and misses the chance to bring back the essential subset quickly.

Practitioner checklist

• Confirm you are working from ISO/IEC 27031:2025 (edition 2), not the 2011 edition, and update policy references.
• Obtain MBCO, RTO and RPO per critical activity from a current, signed business impact analysis.
• Build a dependency map per critical service that includes IdP, MFA, secrets vault, PKI and suppliers.
• Set RTOs for shared identity and infrastructure services shorter than any RTO that depends on them.
• Test break-glass access that works when the primary IdP is down, at least twice a year.
• Run backup restores with production volumes and record measured recovery times and recovery points.
• Add credential and key rotation to cyber recovery runbooks before restored systems reconnect.
• Report measured capability against objectives to top management and record decisions on every gap.
• Re-test after any major change to identity, cloud region, data centre or critical supplier.

Standards and references

• ISO: ISO/IEC 27031:2025 Cybersecurity, Information and communication technology readiness for business continuity
• IEC: ISO/IEC 27031:2025 publication record
• NIST: SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• ISO27k Infosec Management Standards: ISO/IEC 27031 summary

Related NHI Mgmt Group resources: ISO 22301 Business Continuity Guide · Business Continuity and Disaster Recovery Guide · Backup Identity Isolation Guide · Break-Glass Account Guide