ISO/IEC 27031:2025: ISO/IEC 27031:2025 – Tutorial (about 60 minutes)

ISO/IEC 27031 is the international guidance standard on ICT readiness for business continuity, usually shortened to IRBC. It explains how the people who run an organisation's information and communication technology can plan, build, test and improve their services so that, when a disruption strikes, the technology the business depends on comes back in time, with enough data, and at an acceptable level of service. IT and cloud operations teams, business continuity managers, information security managers, risk managers and auditors use it. After this tutorial you will be able to explain what IRBC is, set ICT continuity objectives from business needs, choose and test readiness strategies, and connect the work to ISO 22301 and ISO/IEC 27001.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is ISO/IEC 27031:2025, Cybersecurity — Information and communication technology readiness for business continuity, the second edition (edition 2.0), published in May 2025 (the IEC Webstore lists 2025-05-16; the Standards Council of Canada record lists 2025-05-15). It was prepared by the joint ISO and IEC committee ISO/IEC JTC 1/SC 27 (Information security, cybersecurity and privacy protection) and runs to 33 pages. It replaced the first edition, ISO/IEC 27031:2011, Guidelines for information and communication technology readiness for business continuity, which is withdrawn. The 2025 text is a guidance document, not a set of certifiable requirements. The IEC Webstore, the Standards Council of Canada and BSI (which publishes the identical BS ISO/IEC 27031:2025) all list it as the current published edition; no newer edition had been published when this tutorial was checked. Verified 2026-10-29. The full text is sold by ISO, IEC and national standards bodies; this tutorial explains its ideas in its own words and describes the content by topic rather than reproducing the clause layout.

Who this is for: infrastructure, cloud, network and platform engineers; site reliability and operations teams; IT service managers; business continuity coordinators who need to talk to IT; information security and compliance staff preparing for ISO 22301, ISO/IEC 27001 or regulatory audits; and anyone who has been asked "how quickly can IT bring this back, and how much data would we lose?" and wants a structured answer.

Prerequisites: none. A rough idea of how an organisation uses IT systems, networks and suppliers helps. Every continuity term is explained when it first appears. Familiarity with ISO 22301 or ISO/IEC 27001 makes some links easier to see but is not required.

By the end of this tutorial:

You will be able to explain why ICT readiness matters to business continuity and what ISO/IEC 27031 does and does not cover.
You will be able to define the core vocabulary, including IRBC, business impact analysis, MBCO, RTO, RPO and maximum tolerable period of disruption.
You will be able to describe the main building blocks of the guidance and the changes made in the 2025 edition.
You will be able to derive ICT continuity objectives from business requirements and turn them into readiness strategies and plans.
You will be able to plan exercises and tests that produce evidence of readiness, and feed the results back to management.
You will be able to explain how IRBC is assessed in practice, given that there is no certificate for ISO/IEC 27031 itself.
You will be able to relate ISO/IEC 27031 to ISO 22301, ISO/IEC 27001, incident management guidance and NIST contingency planning.

Lesson 1 – Origins, purpose and scope

Why ICT readiness needs its own guidance

Almost every important business activity now runs on technology. Orders arrive through a web shop, warehouses are steered by a management system, payments flow through banking interfaces, staff sign in through a central identity service and talk to customers by email, chat and phone systems that are themselves software. When that technology fails, the business stops, often within minutes. A storage array dies, a cloud region has an outage, a contractor deletes the wrong database, a ransomware gang encrypts servers and backups, or a fibre cut isolates a site.

Business continuity management, the discipline of preparing an organisation to keep delivering its key products and services during disruption, has long been described in standards such as ISO 22301. Those standards work at the level of the whole organisation: which activities matter most, how fast they must resume, which resources they need. They say that ICT is one of those resources, but they do not explain in detail how an IT department should design, run and prove its own readiness. In many organisations this leaves a gap. The continuity team writes a plan that assumes "IT will restore the systems within four hours", and the IT team has never been told that number, has no design that could meet it, and has never tested it.

ISO/IEC 27031 exists to close that gap. It gives the ICT function a method for understanding what the business needs from it during a disruption, comparing that with what the technology can actually do, choosing ways to close the difference, and showing through testing that the result works. The term the standard uses for this capability is ICT readiness for business continuity, or IRBC.

A short history

The first edition appeared in 2011 as part of the ISO/IEC 27000 family of information security standards, under the title Information technology — Security techniques — Guidelines for information and communication technology readiness for business continuity. It was developed by SC 27, the same committee that maintains ISO/IEC 27001. It described IRBC as a set of principles and elements, explained how IRBC supports business continuity management, and organised the work around the familiar Plan-Do-Check-Act cycle.

Fourteen years later, the second edition was published in 2025 with a new title that starts with "Cybersecurity" and no longer contains the word "Guidelines" (it remains guidance, as its abstract and "should" wording show). According to the publisher summary from BSI, the 2025 edition restructures the document, clarifies its scope, moves technical content into dedicated clauses, and updates the material on risk management, incident management, business continuity strategies, IRBC strategy options and technological solutions. It also extends information security incident management into ICT readiness planning, training and operations, recognising that many modern disruptions begin as security incidents. The abstract of the new edition explicitly names three ICT continuity objectives that planning must address: the minimum business continuity objective (MBCO), the recovery point objective (RPO) and the recovery time objective (RTO).

Scope in plain words

According to its abstract, the standard does four things. It describes the concepts and principles of IRBC. It provides a framework of methods and processes for identifying and specifying ways to improve an organisation's ICT readiness so that business continuity is ensured. It addresses the three objectives above as part of ICT continuity planning. And it explains how ICT departments plan and prepare to support the organisation's resilience objectives. It applies to any type and size of organisation, private or public, whether the ICT is run in-house, in a colocation data centre, in public cloud or by outsourcing partners.

It is just as important to know what the standard is not. It is not a requirements standard: it uses "should" language and gives guidance, so nobody is certified "to ISO/IEC 27031". It is not a detailed disaster recovery runbook for any particular product or cloud. It does not replace the organisation-wide business continuity management system described in ISO 22301 or the information security management system of ISO/IEC 27001; it is designed to sit between and alongside them, so that the ICT part of both is done properly and without duplicated effort.

Lesson 2 – Key concepts and vocabulary

Continuity work goes wrong when people use the same words with different meanings. Many of the terms below come from the business continuity vocabulary in ISO 22300 and are used consistently across ISO 22301 and ISO/IEC 27031. The definitions here are paraphrased.

ICT (information and communication technology) – the hardware, software, networks, data, cloud services, telephony and supporting facilities that process, store and transmit information for the organisation.
Business continuity – the ability of an organisation to keep delivering products and services within acceptable time frames and at a predefined capacity during a disruption.
Business continuity management (BCM) – the overall process of identifying what must continue, preparing to keep it going and recovering it. When it is run as a formal management system, it is called a BCMS (business continuity management system), the subject of ISO 22301.
IRBC (ICT readiness for business continuity) – the capability of an organisation's ICT to support business continuity: preventing disruption where possible, detecting it quickly, responding, recovering within agreed objectives and improving afterwards.
Disruption – an event, expected or not, that interrupts or degrades the planned delivery of products, services or ICT services. An incident is a situation that might become, or already is, a disruption, loss, emergency or crisis.
Business impact analysis (BIA) – the analysis of how the impacts of a disruption on the organisation grow over time. It identifies the prioritized activities, the time frames within which they must resume and the resources, including ICT, they depend on.
Prioritized activity – an activity that must be given priority after a disruption because stopping it for too long would cause unacceptable impact.
Maximum tolerable period of disruption (MTPD) – the time after which the impact of not resuming an activity, or of not providing a product or service, becomes unacceptable. It is a business limit, not a technical target.
Recovery time objective (RTO) – the period, after an incident, within which a product, service or activity must be resumed or a resource such as an ICT service must be recovered. An RTO must be shorter than the MTPD it protects.
Recovery point objective (RPO) – the point to which data used by an activity must be restored so that the activity can operate again. It is usually expressed as a maximum age of data, for example "no more than 15 minutes of transactions may be lost".
Minimum business continuity objective (MBCO) – the minimum level of service or output the organisation accepts during a disruption to still meet its business objectives. For ICT it answers "how much of the service must work, for whom, during recovery?"
ICT service – a service that ICT provides to users or to other services, such as email, the order database, single sign-on or the network link to a warehouse. ICT services depend on each other and on suppliers; these chains are called dependencies.
IRBC strategy – the chosen approach for making an ICT service ready, for example redundancy, replication, backup and restore, an alternate site, a cloud region, a manual workaround or a supplier arrangement.
Exercise and test – an exercise is an activity that trains people and validates plans (a discussion, simulation or live rehearsal); a test is an exercise with a measurable pass or fail outcome, such as restoring a database and timing it.
Invocation – the formal decision to put a continuity or recovery plan into action, taken by a named authority using agreed criteria.

How the time objectives fit together

The three objectives named in the standard's abstract answer three different questions. The RTO answers "how fast must it come back?". The RPO answers "how much recent data may we lose?". The MBCO answers "how much of the service must be available while we are still recovering?". A service can have a tight RTO and a relaxed RPO (a public information website that can be republished from last week's content) or the reverse (an accounting ledger that may be down for a day but must not lose a single posted entry).

It helps to picture a disruption as a timeline, shown in Figure 1. Before the incident, normal operations run and data is regularly copied; the last good copy marks how far back the organisation would have to go, which is what the RPO limits. The incident happens, and it is not always noticed at once: detection time is part of the outage. People then assess the situation and decide whether to invoke the plan. Recovery work brings ICT services back to at least the MBCO level, and that must happen within the RTO. Later the organisation restores full capacity and finally returns to normal operations, which may mean moving back from an alternate site (often called failback). All of this has to sit inside the business limit, the MTPD.

Figure 1 – A disruption timeline: data loss is limited by the RPO, minimum service must return within the RTO, and everything must finish inside the business limit.

Two lessons follow from the timeline. First, the RTO clock starts at the incident, not at the moment someone presses a failover button, so slow detection and slow decisions consume recovery time. Second, the MBCO is what makes many objectives affordable: bringing back a reduced service first (for example, only the order entry screens, for only the dispatch team) is often far cheaper than restoring everything at once.

Lesson 3 – Structure of the standard

The building blocks

ISO/IEC 27031:2025 follows the usual layout of an ISO/IEC document: a scope clause, normative references and a clause of terms and definitions, followed by the technical clauses. The 2025 edition was restructured compared with 2011, so clause numbers in older articles and training material no longer match. Rather than list numbers that you would need to check against your own copy, it is more useful to understand the topics the guidance covers. The list below is drawn from the official abstract, the BSI summary of the 2025 changes and the first edition; check the exact grouping in your own copy.

Concepts and principles of IRBC – what ICT readiness is, why it matters, and how it relates to business continuity management and to information security.
Understanding requirements – using the organisation's business impact analysis and risk assessment to learn what the business needs from ICT during disruption.
ICT continuity objectives – setting MBCO, RTO and RPO for ICT services and checking them against what the current technology can deliver.
Risk management and incident management – identifying threats and weaknesses in ICT, reducing them, and linking incident detection and response to readiness so that security incidents can escalate into continuity responses.
Strategies and technological solutions – the options for making ICT services ready, from redundancy and backup to alternate sites and supplier arrangements, and how to choose among them.
Plans, competence and awareness – documenting how ICT will respond and recover, who does what, and making sure people are trained.
Exercising, testing, monitoring and review – proving that the arrangements work, measuring performance against criteria, and reporting results to management for decisions.
Improvement – learning from tests, real incidents and changes, and updating the arrangements.

Principles of IRBC

Since its first edition the standard has described IRBC as more than recovery. Readiness covers the whole life of a disruption, and the 2011 edition expressed this as a set of principles that are still a good way to organise the work. In paraphrase:

Prevention – reduce the chance that ICT incidents happen at all, through resilient design, good change control, patching and security controls.
Detection – notice incidents as early as possible, through monitoring, alerting and security event analysis.
Response – react in a planned, appropriate way: contain, assess, decide and communicate.
Recovery – restore ICT services to the agreed level within the agreed time and with the agreed data.
Improvement – learn from every incident, exercise and change, and update the arrangements.

The first edition also listed the elements, or kinds of resource, that readiness must consider: people (skills, availability, succession), facilities (data centres, offices, power and cooling), technology (hardware, software, networks), data (its availability, integrity and backups), processes (operating procedures, runbooks, change and incident handling) and suppliers (cloud providers, telecom carriers, outsourcers, software vendors). A readiness strategy that covers technology but forgets that only one person knows how to run the restore, or that the backup tapes are stored in the same building, is not readiness. The 2025 edition reorganises and updates the material, so read your copy for its current wording, but these principles and elements remain a sound checklist.

Where IRBC sits

Figure 2 shows the relationships that the standard is built around. Business continuity management decides what the organisation must keep doing and how fast. Information security management protects the confidentiality, integrity and availability of information. Incident management detects and handles events as they happen. IRBC is where these meet for the ICT function: it takes continuity requirements, uses security and incident processes, and delivers ICT services that are ready.

Figure 2 – IRBC takes requirements from business continuity, uses security, incident and risk processes, and returns tested evidence to management.

Notice the loop at the end. The output of IRBC is not just working technology but evidence that management can use. If tests show that a service cannot meet its RTO, management must either approve investment to close the gap or formally accept the risk. The publisher summary highlights exactly this step: results are fed back to management for approval or for risk treatment decisions.

Lesson 4 – How it works in practice

The guidance describes a framework rather than a rigid procedure, but in practice most organisations follow a cycle that looks like Figure 3. The first edition framed it explicitly as Plan-Do-Check-Act; whatever labels you use, the sequence is the same: understand, decide, build, prove, improve.

Figure 3 – The IRBC cycle: understand business needs, set objectives, build and document solutions, prove them by testing and feed the results back.

Step 1 – Mandate, scope and roles

Readiness costs money and competes with new features for engineering time, so it needs a clear mandate from top management. The scope says which business areas, sites and ICT services are covered; it should follow the scope of the business continuity programme where one exists. Typical roles are an executive sponsor who owns the risk decisions, a business continuity manager who owns the BIA, an IRBC coordinator or ICT continuity manager inside IT, service owners for each important ICT service, technical recovery teams, the security incident response team and supplier managers. Write down who may invoke an ICT recovery plan and who may approve spending during a disruption.

Step 2 – Take requirements from the business

IRBC does not invent its own priorities. It starts from the business impact analysis: which activities are prioritized, how quickly each must resume, and what minimum level of output is acceptable. If no BIA exists, ICT should not guess. It is better to run a simple BIA with the business owners than to set objectives that reflect only what IT believes is important. A common finding is that the business has never been asked to put numbers on these things, and the first conversation is the most valuable outcome of the whole programme.

Step 3 – Map ICT services and dependencies

For each prioritized activity, list the ICT services it uses and then follow the dependencies down: application, database, servers or cloud resources, storage, network, identity and access, DNS, certificates, monitoring, and the external suppliers behind each. A configuration management database or service catalogue helps, but a whiteboard session with engineers is often more accurate. Dependency mapping exposes hidden single points of failure, such as one identity service that every system needs, a licence server, or a shared storage platform that holds both production data and its backups.

Step 4 – Assess risks and current capability

Next, look at what could disrupt those services and how well the current set-up would cope. Threats include hardware and software failure, human error, cyber-attacks such as ransomware, supplier and cloud outages, loss of a site, loss of key staff and failure of utilities. For each important service, find out its real recovery capability: how long a restore actually takes, how old the newest usable backup is, and what happens if a dependency is missing. Measured values from past incidents and tests are worth far more than vendor data sheets.

Step 5 – Set ICT continuity objectives

Translate business time frames into ICT objectives for each service: an MBCO (what minimum service is needed, for whom), an RTO (recovery deadline measured from the incident, so detection and the invocation decision are counted inside it; it must be shorter than the activity's limit, leaving time for business checks after ICT recovery) and an RPO (maximum tolerable data loss). Compare them with the measured capability from step 4. The differences are your readiness gaps. Remember that a service inherits the strictest objectives of the activities that depend on it, and that a dependency, such as identity or networking, must usually recover before the services that rely on it.

Step 6 – Choose strategies and solutions

For each gap, choose an IRBC strategy. Options exist for every element:

Technology – redundant components and clusters, replication to a second site or cloud region, standby environments that are cold (built on demand), warm (partly running) or hot (running and synchronised), and infrastructure defined as code so that environments can be rebuilt quickly.
Data – backups whose frequency matches the RPO, copies kept isolated or immutable so that an attacker or a faulty script cannot delete them, replication for very small RPOs, and regular restore tests to prove the copies are usable. Replication alone is not enough, because corruption and deletions replicate too.
Facilities – alternate data centres or cloud regions, alternate work locations, resilient power and cooling.
People – cross-training, documented runbooks, on-call rotas, and contact lists available when systems are down.
Processes – manual workarounds the business can use while ICT is degraded, emergency change procedures and clear invocation criteria.
Suppliers – contracts and service levels that match your objectives, evidence of the supplier's own readiness, and exit or substitution plans.

Strategy choice is a cost and risk decision. A hot standby gives a small RTO but costs nearly as much as production; a cold standby is cheap but slow. The MBCO often unlocks a middle path, recovering a reduced service first. Security must be part of the design: recovery environments need the same protection as production, and recovery credentials should not depend on the systems that may be compromised.

Step 7 – Implement, document and train

Build the chosen solutions and document how to use them. An ICT continuity or recovery plan typically states its scope and objectives, invocation criteria and authority, roles and contacts, the order of recovery (dependencies first), step-by-step procedures or links to runbooks, communication arrangements, and how to return to normal. Plans should be stored where they can be reached when the main systems are down. Train the people who will use them, including deputies, and include readiness in onboarding for new engineers. Link the plans to the incident management process so that a security or operational incident can escalate cleanly into a continuity response; the 2025 edition puts particular weight on this connection.

Step 8 – Exercise and test

An untested plan is a hope, not a capability. Build an exercise programme that grows in realism: document reviews and walkthroughs, tabletop discussions of a scenario, simulations, component tests such as restoring a single database, partial failovers, and, for the most critical services, full failover to the alternate environment and back. Each test needs defined performance criteria in advance, such as "order service usable by dispatch within 3 hours, with no more than 15 minutes of data loss". Record what actually happened, including the time taken by detection and decision-making, not only the technical steps.

Step 9 – Measure, report and improve

Monitor readiness continuously, not once a year: track backup success and restore tests, replication lag against RPO, test results against RTO, the number of prioritized services with tested plans, and actions still open. Report to management, who decide whether to fund improvements or accept remaining risk. Update the arrangements after every significant change (a migration to the cloud, a new supplier, a reorganisation), after real incidents and after tests. Readiness decays quickly if nobody owns it.

Lesson 5 – Assessment, certification and compliance

No certificate for ISO/IEC 27031

Because ISO/IEC 27031 is a guidance document written with recommendations, there is no accredited certification to it. A supplier that claims to be "ISO/IEC 27031 certified" is either using loose language or describing something else, and it is worth asking what was actually audited and against which standard.

How readiness is assessed in practice

Organisations use the standard in four main ways:

Self-assessment and gap analysis – comparing current practice with the guidance, service by service, and producing an improvement plan.
Internal audit – the internal audit function or a second-line risk team checks that objectives are set, plans exist, tests are performed and results reach management.
Supporting certification to other standards – ISO 22301 (business continuity management systems) and ISO/IEC 27001 (information security management systems) are certifiable. ISO/IEC 27001:2022 includes Annex A controls on information security during disruption and on ICT readiness for business continuity, with related controls on backup and redundancy. An organisation that follows ISO/IEC 27031 has a strong basis for showing that these controls, and the ICT side of an ISO 22301 programme, are effective.
Regulatory and customer assurance – regulators and large customers increasingly ask for evidence of ICT continuity. In the European Union, for example, the Digital Operational Resilience Act (DORA) requires financial entities to have ICT business continuity and response and recovery plans and to test them. ISO/IEC 27031 does not equal compliance with any law, but its method produces the kind of evidence such reviews look for.

What good evidence looks like

Auditors and assessors generally look for a traceable chain: business requirements from a BIA, ICT continuity objectives derived from them, strategies and solutions that are designed to meet those objectives, documented and accessible plans, records of competence and training, an exercise programme with test reports that compare achieved results with the criteria, corrective actions that were followed up, and management review records showing decisions about gaps. A beautifully formatted plan without test records is weak evidence; a modest plan with honest test reports and closed actions is strong evidence.

Performance criteria matter here. The first edition already asked organisations to define performance criteria for IRBC, and measurable criteria are the only way to tell whether readiness is improving. Useful measures include achieved recovery times compared with RTOs, actual data loss in restore tests compared with RPOs, the proportion of prioritized services tested in the last cycle, the age of the oldest open corrective action, and the time from incident detection to invocation decision.

Lesson 6 – Worked example

Northbay Freight is a fictional regional logistics company with 600 staff, three warehouses and about 200 delivery vans. It is preparing for ISO 22301 certification because two large retail customers asked for it, and its IT manager has been told to "make IT ready". She decides to use ISO/IEC 27031 as the method.

Mandate and requirements

The operations director sponsors the work and the business continuity manager shares the BIA. It identifies dispatch (assigning orders to vans and printing route sheets) as the most time-critical activity: after about six hours without dispatch, deliveries miss their slots and contractual penalties begin, so the business limit is six hours. During a disruption the business will accept handling only next-day priority orders, roughly 60 percent of normal volume. Customer invoicing can wait three days. Payroll can wait until its monthly run, provided data is not lost.

Dependency mapping

In a workshop the IT team traces what dispatch needs, shown in Figure 4. The dispatch screens are part of the warehouse management system, which runs on virtual machines in the single company data centre and uses a database on shared storage. Route planning is a software-as-a-service product. Every user signs in through the company directory service, and warehouses connect over one internet link per site.

Figure 4 – Northbay Freight's dependency map for dispatch, revealing a single data centre, a shared sign-in service and backups stored next to production.

Risk and capability

The map makes the weak points obvious. The backups are taken nightly and stored on the same storage platform as production, so a storage failure or ransomware attack could destroy both, and up to 24 hours of orders could be lost. The directory service runs on two servers in the same room. Each warehouse has a single internet link. The team runs a restore test of the order database into a spare environment and measures nine hours from start to usable system, plus about an hour to notice a problem and decide to invoke.

Objectives and gaps

ICT service	MBCO	RTO	RPO	Measured today
Warehouse management (dispatch screens)	Dispatch team at all sites, priority orders	4 hours	15 minutes	About 10 hours, up to 24 hours of data lost
Directory and sign-in	All staff can sign in	2 hours	1 hour	Unknown, never tested away from the data centre
Warehouse connectivity	Dispatch terminals and printers	1 hour	Not applicable	Hours to days, carrier dependent
Invoicing	Finance team	3 days	24 hours	Within objective

The four-hour RTO for dispatch is counted from the incident, so detection and the invocation decision (about an hour, as the restore test showed) must fit inside it, leaving roughly three hours for the technical recovery. The remaining two hours of the six-hour business limit are kept for checks by the dispatch team and as a safety margin. Sign-in has a tighter RTO because dispatch cannot start until people can sign in.

Strategies

The team proposes, and management approves, a set of strategies across the elements. For technology and data, the order database is replicated continuously to a warm environment in a public cloud region, with point-in-time copies so that corruption can be rolled back, and backups are also written to immutable storage in a separate account that production administrators cannot alter. A directory replica runs in the cloud environment. For connectivity, each warehouse receives a second link from a different carrier, using mobile data as a fallback. For processes, dispatch gets a printed manual procedure for the first hours, using a daily export of the next day's priority orders. For people, two more engineers are trained on the failover runbook, and emergency sign-in accounts are kept sealed for use if the directory is unavailable. For suppliers, the route planning contract is reviewed: the provider's stated recovery objectives fit, and the company asks for its continuity test summary each year.

Plans, tests and results

The IT team writes an ICT recovery plan for dispatch with invocation criteria (for example, the warehouse system is unavailable for 30 minutes with no repair estimate), named decision makers, recovery order (network, sign-in, database, application) and contacts, and stores copies outside the main systems. The first exercise is a tabletop session based on a ransomware scenario; it reveals that nobody knew who could authorise taking the data centre offline, which is then written into the plan. The second is a live failover of the order database and dispatch screens to the cloud environment on a Sunday. Timed from the simulated incident, including the invocation call, it achieves usable dispatch in five hours instead of four: the delay came from DNS changes and firewall rules that had not been prepared. The team pre-stages these changes and a retest two months later achieves three hours and ten minutes, with eight minutes of data loss.

Management decisions

The results go to the quarterly management review. Management accepts the remaining risk that payroll could be rebuilt only from the nightly backup, funds the second warehouse links, and asks for a full failover test every year and restore tests every quarter. When the ISO 22301 auditor later visits, the IT manager can show the chain from BIA to objectives to tests to decisions. The work also serves the company's ISO/IEC 27001 controls on ICT readiness and backup, so one body of evidence supports both systems.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 27031 is deliberately a bridge. It is most useful when read alongside the documents it connects, and it does not try to repeat them.

Standard or framework	What it is	Relationship to ISO/IEC 27031
ISO 22301:2019 (amended 2024)	Certifiable requirements for a business continuity management system	Sets the organisation-wide programme, BIA and strategy requirements; ISO/IEC 27031 explains how the ICT function meets its part of them.
ISO 22313 and ISO/TS 22317	Guidance on implementing ISO 22301, and detailed guidance on business impact analysis	Provide the business requirements (prioritized activities and time frames) that IRBC takes as its starting point.
ISO/IEC 27001:2022 and ISO/IEC 27002:2022	Certifiable information security management system requirements, and the guidance on its controls	Annex A includes ICT readiness for business continuity, information security during disruption, backup and redundancy; ISO/IEC 27031 gives the deeper method behind those controls.
ISO/IEC 27035 series	Guidance on information security incident management	Covers detecting and handling security incidents; IRBC links that process to continuity so that serious incidents escalate into recovery.
NIST SP 800-34 Rev. 1	US federal contingency planning guide for information systems	Free, detailed system-level guidance on contingency plans, BIA and recovery objectives; complements ISO/IEC 27031 with practical templates.
EU Digital Operational Resilience Act (DORA)	EU regulation on ICT risk and resilience for financial entities	A legal obligation that includes ICT continuity and recovery plans and testing; ISO/IEC 27031 offers a method for meeting the technical side.

A useful way to remember the relationships: ISO 22301 asks "what must the business keep doing?", ISO/IEC 27001 asks "is our information protected, including during disruption?", the incident management guidance asks "how do we handle what is happening now?", and ISO/IEC 27031 asks "is our technology ready to deliver what the business needs when something goes wrong, and can we prove it?". Organisations that run more than one of these systems benefit from shared artefacts: one service catalogue, one dependency map, one set of objectives, one exercise programme and one management review that covers continuity and security together.

It is also worth knowing what IRBC is not the same as. High availability, such as clustering within one data centre, reduces small failures but is not readiness for the loss of the data centre. IT disaster recovery, meaning the technical restoration of systems after a major failure, is one part of IRBC, but IRBC also covers prevention, detection, response, reduced service levels, people, suppliers and management decisions.

Common pitfalls and best practices

Pitfalls

Objectives set by IT alone. Recovery targets chosen by engineers without a BIA either waste money on services nobody needs quickly or leave critical activities unprotected.
Counting only technical time. Teams measure the failover script but forget detection, decision and verification time, so the real outage exceeds the RTO.
Treating replication as backup. Replicated systems copy deletions, corruption and encryption by ransomware; without isolated point-in-time copies, the RPO cannot be met after such events.
Backups stored with production. Copies on the same platform, in the same account or with the same administrator credentials can be lost in the same incident.
Hidden dependencies. Identity, DNS, certificates, licence servers and monitoring are forgotten until the recovered application cannot start.
Plans that are never tested, or only on paper. Walkthroughs are useful, but readiness is proven only when a restore or failover is actually performed and timed.
Ignoring suppliers. Assuming a cloud or software provider will meet your objectives without checking contracts or evidence leaves a gap you do not control.
Plans locked inside the systems that fail. A recovery plan kept only on the file server or wiki that has just been encrypted cannot be used.

Best practices

Start from the business. Derive MBCO, RTO and RPO from the BIA and keep the link visible so that every objective can be explained.
Use the minimum objective. Plan a reduced first service level to make tight time objectives affordable.
Map dependencies and recover them in order. Keep a living dependency map and put foundation services first in the recovery sequence.
Isolate and test backups. Keep immutable or offline copies under separate credentials, and restore them on a schedule.
Integrate with incident management. Define the triggers that turn an operational or security incident into an invocation, and rehearse the handover.
Increase test realism step by step. Move from walkthroughs to component tests to full failovers, with criteria agreed beforehand.
Report honestly to management. Present measured results and gaps so that leaders make explicit decisions to invest or accept risk.
Review after every change. Update objectives, maps and plans after migrations, new suppliers, reorganisations and real incidents.

Summary and key takeaways

ISO/IEC 27031:2025 (second edition, ISO/IEC JTC 1/SC 27) is guidance on ICT readiness for business continuity; it replaced the 2011 edition and is not itself certifiable.
IRBC means ICT can prevent, detect, respond to, recover from and learn from disruptions in a way that meets business needs.
The three ICT continuity objectives are MBCO (minimum service), RTO (time to recover) and RPO (tolerable data loss), all derived from the business impact analysis and inside the business limit.
Readiness covers people, facilities, technology, data, processes and suppliers, not only servers and backups.
The working cycle is: requirements, dependency mapping, risk and capability assessment, objectives, strategies, plans and training, testing, management decisions, improvement.
The 2025 edition was restructured and updated on risk management, incident management, strategies and technological solutions, with closer links to security incident handling.
Evidence of readiness comes from tests measured against criteria and from management decisions, and it supports ISO 22301, ISO/IEC 27001 and regulatory reviews.

Reflection questions

Choose one important activity in your organisation. Which ICT services and hidden dependencies does it rely on, and which of them would have to be recovered first?
For a service you know well, what would sensible MBCO, RTO and RPO values be, and how would you justify each to a business owner?
When did your organisation last restore a critical system from backup under realistic conditions, and how did the achieved time compare with what the business expects?
How would a ransomware attack that also targets backups change your current recovery strategy, and what would you change first?
Which of your critical suppliers could stop your prioritized activities, and what evidence do you have that their readiness matches your objectives?