ISO/IEC 27031: ICT Readiness for Business Continuity Explained

ISO/IEC 27031 is the international guidance standard for ICT readiness for business continuity, often shortened to IRBC. Its premise is simple: almost every critical business activity depends on information and communication technology, so business continuity only works if the systems, data, networks and suppliers behind those activities can withstand disruption and recover within agreed times.

The second edition, ISO/IEC 27031:2025, was published in May 2025 and replaced the 2011 original. It restructured the guidance, clarified the scope, and added content on governance links, risk management, incident management, strategy options and technology solutions. This guide explains the IRBC approach, how it connects with ISO 22301 and ISO/IEC 27001, how to set ICT recovery objectives, choose strategies, write plans and test them, with practical notes for cloud and SaaS environments.

What is ISO/IEC 27031?

ISO/IEC 27031 is published by ISO and IEC through joint technical committee JTC 1/SC 27, the same group responsible for ISO/IEC 27001. It describes the concepts and principles of ICT readiness for business continuity and how ICT functions can plan and prepare to support the organisation's resilience objectives. It is guidance, not a set of requirements, so it is not certifiable on its own.

IRBC sits between two disciplines. Business continuity management, defined by ISO 22301, decides which activities matter and how quickly they must resume. Information security management, defined by ISO/IEC 27001, protects information and systems. IRBC makes sure the ICT services that support critical activities can be recovered to predetermined levels within the timescales the business needs, and that ICT incidents, including cyberattacks, are prevented, detected and managed with continuity in mind.

What changed in the 2025 edition?

The 2025 edition cancels and replaces ISO/IEC 27031:2011. According to its foreword, the structure of the document changed, the scope was clarified, and technical content was added on risk management and applicable controls, incident management, BCM strategies and their alignment with IRBC, IRBC strategy options, and technological solutions. It also reflects how cloud services have shifted preparedness from internal processes to reliance on suppliers' services and relationships.

Who should use it?

• IT operations, infrastructure and cloud teams responsible for keeping systems available and recoverable.
• Business continuity managers who need ICT recovery capabilities to match business requirements.
• Security teams handling incidents such as ransomware that cause outages.
• SaaS, hosting and managed service providers whose customers rely on their recovery capabilities.
• Organisations implementing ISO 22301 or ISO/IEC 27001, where control 5.30 of ISO/IEC 27001:2022 requires ICT readiness for business continuity.
• Regulated firms facing resilience rules such as DORA in the EU or Indian regulators' DR drill requirements.

Is it mandatory or voluntary?

Voluntary. It becomes relevant to compliance when ISO/IEC 27001 control 5.30, ISO 22301, contracts or regulations require tested ICT recovery. Auditors often accept an IRBC approach based on ISO/IEC 27031 as evidence for those requirements.

Integrating IRBC into business continuity management

The standard emphasises that IRBC should not be a separate silo. It should connect with:

• Governance: top management sets policy, roles and resources for ICT continuity as part of business continuity.
• Business continuity objectives: ICT recovery supports the objectives agreed in the BCM programme.
• Risk management: ICT risks and applicable controls feed both security and continuity planning.
• Incident management: ICT incidents, including security incidents, may escalate into continuity events, so response and recovery processes must be linked.
• BCM strategies: business continuity strategies must be supported by matching ICT strategies.

If an organisation already runs ISO 22301 and ISO/IEC 27001 processes, IRBC should reuse them rather than duplicate them.

Business expectations: risk review and BIA inputs

IRBC starts from what the business needs:

• Risk review: understand threats and events that could disrupt ICT services, with monitoring, detection and analysis of emerging threats.
• Business impact analysis (BIA): identify critical activities, how long they can be disrupted and how much data loss is tolerable. From this, identify the critical ICT services that support them.
• Assess current readiness: compare existing ICT recovery capabilities against business continuity requirements to find gaps.
• Coverage and interfaces: map ICT dependencies within scope, including networks, identity, shared platforms and external services, and the contractual aspects of those dependencies.

Setting ICT recovery objectives

The business sets a maximum tolerable period of disruption and recovery time objective (RTO) for each critical activity, and a recovery point objective (RPO) for tolerable data loss. ICT must then set its own targets that fit within those limits. ICT RTOs are usually shorter than business RTOs, because the business also needs time after systems are restored to resume work, verify data and catch up. ICT RPOs determine backup and replication frequency. The standard also discusses the minimum business continuity objective, the minimum level of service acceptable during disruption, and an annex comparing RTO and RPO with business objectives.

Term	Meaning	Example
Business RTO	Time within which an activity must resume	Order processing within 8 hours
ICT RTO	Time within which ICT services must be restored to support it	Order system restored within 4 hours
RPO	Maximum tolerable data loss	No more than 15 minutes of orders lost
Minimum business continuity objective	Minimum acceptable service level during disruption	Accept orders, delay non-urgent reports

IRBC strategy options

The standard groups recovery strategies by resource type:

• Skills and knowledge: cross-training, documented procedures, access to external experts.
• Facilities: alternate sites, data centre diversity, remote working capability.
• Technology: redundancy, high availability, failover, standby environments, cloud regions.
• Data: backups, replication, immutable and offline copies, integrity checks.
• Processes: manual workarounds, prioritised restoration, change control during recovery.
• Suppliers: contractual recovery commitments, alternative suppliers, exit plans.

Strategies are chosen by comparing cost and complexity with the recovery objectives. A system with a four-hour RTO and near-zero RPO might need active replication to a second region, while a system with a three-day RTO might rely on restoring from backups.

ICT continuity and recovery plans

Plans translate strategies into action. The standard covers:

• Prerequisites: the recovery organisation, timeframes for plan development and testing, resources, staff competence and technological solutions.
• Activation and escalation: when and by whom ICT continuity plans are invoked, and how incidents escalate.
• ICT recovery plans for meeting RTO and RPO across facilities, technology, data and people, with step-by-step response and recovery procedures.
• Temporary workaround plans to keep critical activities running while ICT is restored.
• External contacts and procedures with suppliers, authorities and customers.

Recovery capabilities and redundancy

Before an incident occurs, the standard expects the organisation to establish its ICT recovery capabilities: what it can restore, how quickly, and with what resources. That includes planning equipment and component redundancy so that single points of failure are removed or consciously accepted, determining which ICT services are in scope for each objective, and understanding the outcomes and benefits the investment will bring. For many organisations, this exercise exposes hidden single points of failure such as one database server, one network link, one administrator with the passwords, or one supplier with no alternative.

Testing, exercises and audit

Untested plans fail. The standard describes performance criteria, a test and exercise programme covering dependencies, scope and planning of exercises, alert-based and staged recovery scenarios, managing exercises safely, learning from results, auditing IRBC, and control of documented information. Exercises range from walkthroughs and tabletop scenarios to component restores, full failovers and simulated cyberattacks. Results feed into improvements and management review.

Top management responsibilities

Management must evaluate whether IRBC remains effective, provide resources, review test and audit results, and ensure ICT continuity keeps pace with business change. This aligns with the management review requirements of ISO 22301 and ISO/IEC 27001.

How to implement IRBC, step by step

1. Link to the BIA: list critical activities and their RTO, RPO and minimum service levels.
2. Map critical ICT services and their dependencies, including cloud and third parties.
3. Assess current recovery capability against requirements.
4. Set ICT RTO and RPO for each critical service.
5. Choose strategies for people, facilities, technology, data, processes and suppliers.
6. Implement redundancy, backups, failover and supplier commitments.
7. Write ICT continuity plans with activation, escalation and recovery procedures.
8. Test and exercise regularly, including realistic cyber scenarios.
9. Audit, review and improve.

Planning for ransomware and destructive attacks

Traditional disaster recovery planned for fires, floods and hardware failure, where the backup site was clean. Ransomware and destructive cyberattacks change the assumptions: attackers may encrypt production and replicas, delete backups, steal administrator credentials and remain inside the network. IRBC planning should therefore include scenarios where the primary environment cannot be trusted. Useful measures include immutable or offline backups that administrators cannot delete, separate credentials and accounts for backup systems, the ability to rebuild systems from clean images or code, a forensic step to identify the point of compromise before restoring, and an RPO that accounts for the time an attacker may have been present. Exercises should test this scenario explicitly, since it is often the hardest one.

Applying it to cloud and SaaS

For cloud-native systems, IRBC focuses less on hardware and more on regions, accounts, identity, data and suppliers. Practical points include deploying across availability zones and, for critical services, across regions; using infrastructure as code so environments can be rebuilt; keeping immutable or logically separated backups that ransomware cannot reach; protecting and backing up identity provider configuration; documenting dependencies on third-party APIs; and testing restoration regularly, not just backup success. SaaS providers should publish recovery commitments their customers can rely on and evidence them through tests.

Documentation you will need

• IRBC policy and scope.
• BIA outputs and critical ICT service list.
• Dependency maps.
• ICT RTO and RPO targets.
• Strategy decisions and implemented capabilities.
• ICT continuity and recovery plans.
• Test and exercise plans, results and improvement actions.
• Audit reports and management review records.

Timeline and cost considerations

A first IRBC assessment for a mid-sized organisation, covering BIA links, dependency mapping and gap analysis, usually takes a few weeks. Implementing new recovery capabilities can take months, especially for cross-region replication or rebuilding systems as code. Costs depend mainly on the recovery objectives: near-zero RPO and short RTO require continuous replication and standby capacity, while longer targets can rely on cheaper backup-based recovery. Testing has a cost too, but untested recovery has a far higher one.

Benefits

• Recovery objectives tied to real business needs rather than guesses.
• Clear evidence for ISO 22301, ISO/IEC 27001 control 5.30, customer audits and regulators.
• Faster, calmer recovery because plans and roles are known and rehearsed.
• Better decisions on where to spend on resilience.

Common mistakes

• Backups never restored in a test.
• ICT RTOs that exceed business RTOs.
• Ignoring identity, DNS and network dependencies that block recovery.
• Backups reachable by ransomware.
• Supplier recovery assumed without contractual commitments.
• Plans written once and never updated after architecture changes.

Best practices, tools and technologies

• Automate infrastructure and configuration with code.
• Use immutable, separate-account backups with regular restore testing.
• Monitor replication lag against RPO targets.
• Run game days and chaos experiments for critical services.
• Keep runbooks in version control and accessible offline.
• Align with NIST SP 800-34 templates where useful.

We set up multi-region deployments, infrastructure as code, tested backups and recovery runbooks through our maintenance and support and migration and modernisation services.

How it relates to other frameworks

Framework	Relationship
ISO 22301	Certifiable business continuity management system that IRBC supports.
ISO/IEC 27001	Control 5.30 requires ICT readiness for business continuity.
NIST SP 800-34	US federal contingency planning guide with templates.
IT disaster recovery planning	Practical synthesis of RTO, RPO and testing expectations across standards and laws.
DORA	EU regulation requiring ICT business continuity and recovery testing for financial entities.

Real-world example

A B2B SaaS company with an Indian operations team runs its platform on one cloud region. Its BIA shows customers expect recovery within four hours and no more than 15 minutes of data loss. Applying ISO/IEC 27031, it maps dependencies including its identity provider, payment gateway and email service, sets ICT RTO at two hours, adds cross-region database replication and immutable backups in a separate account, writes runbooks for regional failover and ransomware recovery, and runs a full failover exercise twice a year. Results go to management review and its ISO/IEC 27001 auditor accepts the evidence for control 5.30.

Next steps

1. Pull RTO and RPO from your BIA.
2. Map critical ICT services and dependencies.
3. Set ICT objectives and close gaps.
4. Write and test recovery plans.
5. Review results with management.

Frequently asked questions

What is ISO/IEC 27031?

International guidance on ICT readiness for business continuity, ensuring the technology behind critical activities can withstand and recover from disruption.

What is the current version?

ISO/IEC 27031:2025, the second edition, published in May 2025.

Is ISO/IEC 27031 certifiable?

No. Organisations certify to ISO 22301 or ISO/IEC 27001 and use ISO/IEC 27031 as guidance.

What is IRBC?

ICT readiness for business continuity: the processes and capabilities that prevent, detect, respond to and recover from ICT disruptions.

How does ISO 27031 relate to ISO 22301?

ISO 22301 sets business continuity requirements; ISO 27031 guides the ICT side so technology recovery meets them.

How does it relate to ISO 27001?

It helps meet ISO/IEC 27001 control 5.30 on ICT readiness for business continuity.

Why should ICT RTO be shorter than business RTO?

Because the business needs time after systems are restored to verify data and resume work.

What strategy areas does it cover?

Skills and knowledge, facilities, technology, data, processes and suppliers.

How often should ICT recovery be tested?

Regularly, based on risk and change; critical systems are commonly tested at least annually, and some regulators require half-yearly drills.

Does it cover cyberattacks?

Yes. It links ICT continuity with incident management, including security incidents such as ransomware that can disable both production and backup systems.