Framework

ISO/IEC 27031
ICT readiness for business continuity (IRBC)

ISO/IEC 27031 (Guidelines for information and communication technology readiness for business continuity) is the international standard that defines what ICT readiness for business continuity looks like inside a broader business continuity programme. It sits beneath ISO 22301 as the ICT-specific operating companion, names the ten guiding principles IRBC reads against, organises the PIRBC operating model (plan, implement and operate, monitor and review, maintain and improve), and connects RTO, RPO, and MTPD across the business impact analysis and the ICT recovery design. This page covers the standard scope, the ten principles, the PIRBC phases, the RTO and RPO and MTPD alignment, the failure scenarios IRBC is designed for, the exercise cadence, the evidence pack, the failure modes, and the cross-walk to ISO 22301, NIST SP 800-34, NIST CSF 2.0 RC.RP, DORA Article 11 and 12, NIS2 Article 21(2)(c), ISO/IEC 27001 Annex A 5.29 and 5.30, and SOC 2 A1.2 and A1.3.

Get Started Free

No credit card required. Free plan available forever.

ISO/IEC 27031 explained for enterprise teams

ISO/IEC 27031 (Guidelines for information and communication technology readiness for business continuity) is the international standard that defines what ICT readiness for business continuity (IRBC) looks like inside a broader business continuity programme. It sits beneath ISO 22301 as the ICT-specific operating companion, names the ten guiding principles IRBC reads against, organises the PIRBC operating model (Plan, Implement and Operate, Monitor and Review, Maintain and Improve), and connects RTO, RPO, and MTPD across the business impact analysis and the ICT recovery design.

For internal security teams, GRC and compliance teams, security operations leaders, security engineering teams managing platform reliability, IT continuity owners, application owners accountable for service availability, AppSec leads where availability is a security property, cloud security teams managing region and provider exposure, and CISOs and security directors carrying the audit-committee read against the technology continuity posture, ISO/IEC 27031 is the operating standard the ICT-side continuity evidence reads against. The framework is dense; the value is the lifecycle discipline that turns ICT continuity from a quarterly DR plan refresh into a continuous operating record that survives audits, regulators, and incidents.

This page covers the standard scope, the ten guiding principles, the PIRBC operating model, the ICT readiness measures, the RTO and RPO and MTPD alignment, the failure scenarios IRBC is designed for, the exercise programme, the evidence pack, the failure modes, and where ISO/IEC 27031 sits alongside DORA Article 11 and 12, NIS2 Article 21(2)(c), ISO/IEC 27001 Annex A 5.29 and A 5.30, NIST CSF 2.0 Recover function, and SOC 2 A1 Availability criteria. Programmes that adopt ISO/IEC 27031 as the IRBC operating standard read cleanly into every adjacent regime without rebuilding the evidence pack per audit.

The ten guiding principles of IRBC

ISO/IEC 27031 opens with ten guiding principles that any IRBC programme reads against. The principles below are the orientation that distinguishes a managed IRBC programme from a one-off DR plan refresh. Programmes that adopt the principles as the operating posture produce evidence that survives contact with auditors, regulators, and incidents; programmes that treat them as text in a policy document produce a plan that ages out within the first cycle.

Top management commitment

IRBC is operated as a programme that has explicit sponsorship from the executive owner of the ICT function and is reviewed at the same management table the wider business continuity programme reads against. Without sponsorship, the recovery investment, the exercise calendar, and the cross-functional cooperation IRBC depends on all decay between incidents. The standard names this principle first because it carries the weight of every later principle.

Holistic approach

IRBC sits at the intersection of information security (ISO/IEC 27001), business continuity (ISO 22301), IT service continuity (ITIL Service Continuity), risk management (ISO 31000 and ISO/IEC 27005), and incident management (ISO/IEC 27035). Programmes that operate IRBC in isolation from these disciplines duplicate evidence, conflict on terminology, and produce recovery plans the rest of the organisation does not read. The holistic principle expects the four neighbouring disciplines to inherit from one shared programme record.

Risk-based prioritisation

IRBC investment is finite. The standard expects the readiness depth per ICT service to be set by the business criticality of the service, the data sensitivity, the dependency footprint, the recovery cost, and the regulator exposure. Programmes that apply uniform RTO and RPO commitments across every service over-invest in commodity systems and under-invest in critical ones. The risk-based principle pairs with the BIA outputs to set the per-service readiness posture.

Lifecycle approach (PIRBC)

IRBC is operated through the PIRBC lifecycle: Plan, Implement and Operate, Monitor and Review, Maintain and Improve. The lifecycle is a continuous cycle rather than a one-off project. Programmes that treat IRBC as a one-time documentation exercise produce a plan that ages out within the first contract cycle, the first cloud-provider change, or the first organisational restructure. The lifecycle principle is the structural commitment to continuity that distinguishes IRBC from a static DR runbook.

Continual improvement

Every PIRBC cycle is expected to feed the next: the exercise after-action records surface gaps, the incident post-mortems surface root causes, the change-management record surfaces drift, and the management review documents the disposition. Continual improvement is the operating discipline that turns IRBC from a snapshot of readiness into a programme that improves over time. Programmes that exercise without after-action review or document without revision lose this dimension within the first cycle.

Embedded culture

IRBC depends on behaviour the standard cannot legislate: the on-call engineer reaching for the documented procedure instead of improvising, the application owner refreshing the recovery test annually instead of the year of the audit, the change record naming the recovery impact instead of the change-window minutes. The standard expects training, awareness, and the routine reinforcement that make IRBC behaviour the default rather than the exception.

Defined roles and responsibilities

IRBC names the roles the operating record reads against: the IRBC programme owner (typically the head of ICT or a delegate), the IRBC coordinator (the day-to-day operating lead), the recovery owner per service (typically the application owner or service owner), the exercise lead per cycle, the crisis decision authority, and the regulator notification owner. Programmes that operate IRBC without a named owner per artefact produce shared accountability that becomes no accountability at the moment of need.

Demonstrable competence

The personnel operating IRBC are expected to be competent for the roles they hold. The standard does not name specific certifications; it expects the competence to be documented and refreshed (training records, qualification mapping, mentoring under named senior operators). Programmes that depend on the institutional memory of one senior engineer carry single-person continuity risk that contradicts the standard the personnel are operating.

Periodic review and testing

IRBC is not credible without testing. The standard expects a documented test programme that covers desk-based walkthroughs (low cost, frequent), simulation exercises (medium cost, periodic), partial failover tests (higher cost, annual or biennial), and full failover tests (highest cost, on a cadence proportionate to the service criticality). Each test produces an after-action record with named follow-up actions. Periodic review covers the per-cycle management review the BCMS auditor reads against.

Effective communication

IRBC depends on communication channels that work during disruption: internal channels (executive, technical, customer-facing, regulator-facing), supplier channels (cloud provider, managed service provider, key supplier), customer channels (notification, status page, support), and regulator channels (sectoral regulator, data protection authority, CSIRT). The standard expects the channels to be documented in the IRBC plan and exercised so the communication does not become the bottleneck during the first material disruption.

The PIRBC operating model

IRBC is operated through the four PIRBC phases. The cycle is continuous: each maintain-and- improve closure feeds the next plan refresh, and the operating record reads against the same evidence pack across years. Programmes that operate IRBC as a one-time documentation project lose the cycle dimension; the standard expects the lifecycle to be the structural commitment the rest of the principles read against.

  1. 1

    Plan

    Establish the IRBC strategy, the IRBC policy, the IRBC scope (which ICT services are in scope, which are explicitly out), the IRBC governance (decision authority, escalation route, management review cadence), and the IRBC dependencies (suppliers, cloud providers, sub-processors, internal teams). The Plan phase is the cheapest phase to invest in and the most expensive to skip. Programmes that under-invest in Plan rebuild the strategy at every audit and every regulator change.

  2. 2

    Implement and operate

    Deploy the ICT readiness measures (resilience, recovery, incident response, crisis management) per service, document the operating procedures, integrate the IRBC procedures with the incident management process and the crisis management plan, train the named operators, and produce the per-service recovery procedures the responder will follow. Implementation is the longest visible phase; operation is the longest continuous phase. The standard expects both to read against the same operating record.

  3. 3

    Monitor and review

    Exercise the recovery procedures on the documented cadence, measure the achieved recovery times against the target RTO and RPO, audit the operating record against the IRBC policy, surface deviations as findings, and document the corrective action plan. The monitor-and-review phase is where the difference between a documented plan and a tested capability becomes visible. Programmes that document well but exercise rarely discover the gap during the first material incident.

  4. 4

    Maintain and improve

    Refresh the IRBC programme on cycle (annual minimum), on event (post-incident, post-exercise, post-change), and on change (new service in scope, decommissioned service out of scope, supplier change, cloud-provider change, organisational change, regulator change). Document the management review minutes, file the lessons-learned record, and feed the improvements into the next Plan cycle. The maintain-and-improve phase is the closing artefact that completes one PIRBC cycle and opens the next.

ICT readiness measures

ISO/IEC 27031 names the categories of measures programmes deploy to meet the RTO, RPO, and MTPD per in-scope service. The measures span resilience (reduce the probability the disruption reaches the recovery process), recovery (restore the service after a disruption), incident response (operate the response from first signal to recovery declaration), crisis management (handle the business event when disruption exceeds the operational response), and the dependency and change disciplines that prevent drift between cycles. The measures read together as one operational posture rather than as five separate disciplines.

  • Resilience measures. Redundancy at component, service, and site level. Fault tolerance through clustering, replication, load balancing, and degraded-mode operation. Geographic diversity for site-affecting events (data centre failure, regional outage, natural disaster). Resilience reduces the probability of disruption reaching the recovery process; well-designed resilience absorbs the kind of failure that would otherwise trigger the recovery measures.
  • Recovery measures. Backup with documented retention, restoration with verified periodicity, failover from primary to secondary, fallback after the primary is restored, and the documented procedures the responder reads to execute each. Recovery measures are the discipline that converts a backup tape, a replicated database, or a failover cluster from a theoretical capability into a tested one. The standard expects recovery measures to be exercised, not assumed.
  • Incident response measures. Detection through monitoring, escalation through documented channels, containment through the response runbook, and communication through the named channels. Incident response measures cover the operational handling of a disruption from first signal to the decision point where IRBC recovery procedures activate. Pairs with the ISO/IEC 27035 incident management discipline so the handoff is unambiguous.
  • Crisis management measures. Decision authority for the recovery declaration, stakeholder communication through the named channels (executive, customer, supplier, regulator), regulator notification within the applicable clocks (GDPR Article 33 supervisory authority within 72 hours, NIS2 Article 23 CSIRT within 24 hours of significant incidents, DORA Article 19 ICT-related incident reporting, sectoral clocks), and the crisis-room operating model. Crisis management measures activate when the disruption exceeds the operational response and becomes a business event.
  • Dependency-mapping measures. Internal dependencies (which ICT service depends on which other ICT service), supplier dependencies (which third party provides which service component), cloud-provider dependencies (which workload runs on which region, which availability zone, which managed service), and sub-processor dependencies (where the dependency chain extends beyond the direct supplier). Dependency mapping is the artefact the recovery sequence reads against and the artefact the supplier-side IRBC inherits from.
  • Change management measures. Every change to an ICT service in scope reads against the IRBC impact: does the change affect the RTO, the RPO, the recovery procedure, the dependency footprint, or the exercise calendar. Change management measures are the operational discipline that prevents IRBC drift between cycles. Programmes that exercise annually but accept changes without IRBC review discover at the next exercise that the documented procedures no longer match the system they describe.

RTO, RPO, and MTPD aligned with the business impact analysis

IRBC reads RTO, RPO, and MTPD from the business impact analysis the wider business continuity programme produces. The three values are the per-service readiness targets the recovery design, the exercise programme, and the operating evidence read against. Programmes that set RTO and RPO without MTPD lose the outer boundary that makes the per-service commitments accountable to the business; programmes that set the targets without business owner agreement produce commitments nobody owns when the first material disruption tests them.

  • RTO (recovery time objective). The target time within which an ICT service must be restored after a disruption begins. RTO is set by the business owner against the business impact of disruption, agreed by ICT against the technical feasibility of the recovery design, and evidenced through exercise. Per-service RTOs typically tier by criticality (Tier 1 critical, Tier 2 important, Tier 3 standard, Tier 4 deferred). The standard expects each RTO to be the negotiated outcome of business and ICT rather than the unilateral choice of either.
  • RPO (recovery point objective). The target maximum age of data that can be lost when an ICT service is restored. RPO is set by the business owner against the data-loss tolerance of the affected process, agreed by ICT against the technical feasibility of the data protection design, and evidenced through restoration testing. Per-service RPOs typically tier by data sensitivity and process criticality (continuous replication for Tier 1, near-real-time for Tier 2, hourly for Tier 3, daily for Tier 4).
  • MTPD (maximum tolerable period of disruption). The point at which disruption of an ICT service becomes unacceptable to the business and triggers the crisis management response. MTPD reads against the wider business continuity programme (ISO 22301) and sets the outer boundary the RTO must sit comfortably inside. Programmes that set RTO and RPO without MTPD lose the structural anchor that makes the per-service commitments accountable to the business.
  • BIA inheritance. RTO, RPO, and MTPD per service are inherited from the business impact analysis the wider business continuity programme produces. ISO/IEC 27031 does not invent the BIA; it expects the BIA outputs to flow into the IRBC strategy as the per-service readiness targets. Programmes that operate IRBC without a current BIA produce per-service commitments that nobody owns. The IRBC operating record reads against the dated BIA version that produced the current targets.
  • Recovery design alignment. The technical recovery design (backup retention, replication topology, failover automation, restore runbook) reads against the per-service RTO and RPO so the design demonstrably meets the target. The standard expects the design alignment to be documented, exercised, and updated when the target changes or when the technology underpinning the design changes. Programmes that drift the design without refreshing the target produce gaps that surface at the first material exercise.
  • Exercise evidence. The achieved recovery time and the achieved recovery point per exercise are recorded against the per-service target so the gap (or the surplus) is visible. Programmes that exercise without recording the achieved versus target metrics lose the ability to evidence the per-service capability to a regulator, an auditor, or an audit committee. The standard expects the exercise record to be the durable artefact the BCMS audit reads against.

The exercise programme

ISO/IEC 27031 is unforgiving on the difference between a documented plan and a tested capability. The exercise programme below covers the spectrum from low-cost walkthroughs to full failover tests, with each exercise tier proportionate to the service criticality and producing an after-action record the corrective action follow-up reads against. Programmes that document well but exercise rarely discover the gap during the first material incident; programmes that exercise without after-action review lose the cycle that converts exercise activity into programme improvement.

  • Desk-based walkthrough. A facilitated walkthrough of the recovery procedure by the named operators against a stated scenario. Walkthroughs are low cost, can be run frequently (quarterly or semi-annually for critical services), and surface documentation gaps and role clarity issues before they appear in higher-stake exercises. The walkthrough record names the participants, the scenario, the gaps surfaced, and the corrective actions.
  • Simulation exercise. A facilitated simulation of the recovery procedure with the named operators executing notional actions against a stated scenario in real time. Simulations sit between walkthroughs and live tests and are the right vehicle for cross-functional rehearsal (ICT plus business plus crisis management plus communications) without committing to a live failover. Programmes commonly run an annual simulation for each Tier 1 and Tier 2 service.
  • Partial failover test. A live execution of one or more steps of the recovery procedure against a non-production or controlled portion of the service. Partial failover tests prove technical capability (the failover automation runs, the restore procedure completes, the secondary site activates) without the customer impact of a full failover. Annual partial tests are common for Tier 1 services with planned maintenance windows.
  • Full failover test. A live end-to-end failover of the production service to the secondary capability, operation of the service from the secondary, and a controlled fallback to the primary. Full failovers are the highest-fidelity test of IRBC and carry the highest operational risk. Cadence is proportionate to the service criticality and the operational risk tolerance (annual for Tier 1 in regulated sectors, biennial in many others, on-event after major architectural change for the rest).
  • Scenario-driven exercise. An exercise designed against a specific scenario the threat-and-disruption landscape names: regional cloud-provider outage, ransomware encryption of production storage, supply chain dependency failure, denial-of-service campaign sustained over days, insider misuse of administrator credentials, data centre power failure with generator failure, key personnel unavailable simultaneously. Scenario-driven exercises stress the dependency map and the crisis management measures rather than the steady-state recovery procedures.
  • After-action review. Every exercise produces an after-action record that names the scenario, the participants, the recovery objective, the achieved metrics versus target, the gaps surfaced, the root cause of each gap, the corrective action plan with named owner and due date, and the disposition (closed, accepted, scheduled). The after-action record is the artefact that converts exercise activity into programme improvement and the artefact the BCMS audit reads against.

The IRBC evidence pack

The minimum durable evidence pack the BCMS auditor, the regulator, the audit committee, and the executive sponsor each read against the IRBC programme is grouped below by artefact type. Each artefact carries a named owner, a refresh cadence, and a version history so reconstruction at audit time is replaced with a continuous operating trail. ISO/IEC 27031 does not invent these artefacts; it names what the IRBC operating record needs to contain to satisfy the discipline the standard reads against.

  • The IRBC policy. The signed policy that names the IRBC scope, the IRBC governance, the per-service tiering approach, the exercise commitment, the regulator notification commitments, and the review cycle. The policy is the load-bearing document the rest of the programme reads against and the artefact the executive review minutes are signed against.
  • The IRBC scope statement. The structured list of ICT services in scope with the service owner, the business owner, the tier, the RTO, the RPO, the dependency footprint, and the current recovery design. Services explicitly out of scope are named with the rationale. The scope statement is refreshed on cycle and on change so a service entering the production estate is also entering the IRBC scope.
  • The BIA outputs. The dated outputs of the business impact analysis the wider business continuity programme produces, with the per-service RTO, RPO, and MTPD; the dependency map per service; and the named business owner per service. The BIA outputs are inherited; IRBC does not produce them but reads against them.
  • The ICT continuity strategy. The strategy that names the resilience posture per tier, the recovery posture per tier, the backup retention and restoration commitments, the failover topology, the dependency-management approach, and the cloud-provider continuity assumptions. The strategy is the architectural commitment the per-service designs read against.
  • The recovery procedures per service. The documented procedures for restoring each in-scope service, with named operators, executable steps, expected duration, decision points, escalation triggers, communication requirements, and verification steps. The recovery procedures are the artefact the responder reads at 3 AM during a real incident; they are also the artefact the exercise programme tests.
  • The exercise programme and after-action records. The exercise calendar covering the next twelve months, the exercise records from the prior twelve months, and the after-action records with corrective action follow-up. The exercise evidence is the most-read artefact during a BCMS audit and one of the most-read during a regulator review.
  • The incident response playbooks. The playbooks that cover the IRBC-relevant incident types (ransomware, regional outage, supplier failure, key personnel unavailability, data corruption, denial-of-service). The playbooks read alongside the recovery procedures and the crisis management plan as the integrated operational response.
  • The crisis management plan. The plan that names the decision authority for recovery declaration, the crisis-room operating model, the stakeholder communication channels and templates, the regulator notification owners and clocks, the customer communication approach, and the public communication position. The crisis plan integrates IRBC with the wider crisis management discipline.
  • The dependency map. The structured map of internal dependencies, supplier dependencies, cloud-provider dependencies, and sub-processor dependencies for each in-scope service. The dependency map is the artefact the recovery sequence reads against and the artefact that surfaces the dependencies a per-service recovery plan would otherwise miss.
  • The training and awareness record. The training records for the named operators, the awareness materials for the wider population, the qualification mapping for IRBC roles, and the refresh cadence. The training record demonstrates the competence principle and the embedded-culture principle.
  • The change management record. Every change to an in-scope service with the IRBC impact assessment, the recovery procedure refresh (if needed), the exercise re-test trigger (if needed), and the disposition. The change record prevents drift between exercise cycles.
  • The management review minutes. The minutes of the periodic management review of the IRBC programme, with the per-service performance, the exercise outcomes, the incident learnings, the residual risk position, the resource requests, and the management decisions. The minutes are the artefact the BCMS audit reads to evidence the top-management commitment principle.

Failure scenarios IRBC is designed for

The scenarios below are the disruption patterns IRBC programmes prepare for. Each scenario is a stress test of a different combination of the resilience, recovery, incident response, crisis management, and dependency disciplines. Programmes that exercise across the scenario catalogue rather than only the single-site failover discover the dependency exposures, the sustained-availability gaps, and the supplier-side dependencies the standard expects the dependency map to surface.

  • Regional cloud-provider outage. A multi-hour outage of one region of a major cloud provider that affects every customer workload hosted in that region. IRBC programmes that depend on a single region without cross-region failover discover this scenario as a forced operational test. The standard expects the dependency map to surface the single-region exposure and the strategy to name the response (cross-region active-active, cross-region active-passive, cross-provider, accept and recover from backup).
  • Ransomware encryption of production storage. A ransomware event that encrypts production storage including the primary backup target. IRBC programmes with immutable backups, air-gapped retention copies, or offline copies recover; programmes that rely solely on online replication discover that the replication propagated the encryption to the secondary. The standard expects backup retention to include a recovery path that survives the ransomware scenario.
  • Supplier dependency failure. A material supplier (managed service provider, SaaS provider, key vendor) suffers an extended outage or insolvency. IRBC programmes with documented supplier dependencies and an exit plan recover by transition; programmes without exit planning carry the supplier outage as a direct service outage. The standard pairs with ISO/IEC 27036 supplier-relationship discipline so the supplier-side IRBC is visible to the acquirer.
  • Sustained denial-of-service campaign. A denial-of-service campaign that targets customer-facing services over days or weeks. IRBC programmes treat sustained DoS as an availability event the recovery posture must absorb (origin shielding, capacity headroom, traffic engineering) rather than a recovery event the failover process handles. The standard expects the resilience measures to address sustained-availability scenarios distinct from point-in-time disruption.
  • Insider misuse of administrator credentials. An insider with administrator credentials performs destructive actions against production systems. IRBC programmes recover through the backup retention strategy and the change-audit trail; the difficulty is detecting the destructive action quickly enough that the backup retention window covers the recovery point. The standard pairs with ISO/IEC 27001 Annex A 5.16 (identity management) and A 8.34 (protection during audit testing) so the operational controls support the recovery posture.
  • Data centre power failure with generator failure. A power failure at a data centre followed by failure of the generator that should have absorbed it. IRBC programmes with cross-site failover recover; programmes that depend on single-site resilience discover the dual-failure scenario as a direct outage. The standard expects the site resilience design to be tested at the dual-failure level rather than the single-failure level alone.
  • Key personnel unavailable simultaneously. A scenario where several key personnel (the senior engineer, the architect, the on-call lead) are simultaneously unavailable (pandemic event, scheduled holiday convergence, mass resignation). IRBC programmes with documented runbooks, cross-trained operators, and supplier-side support contracts recover; programmes that depend on institutional memory discover the personnel scenario as the most difficult to recover from.
  • Data corruption discovered after replication. A logical data corruption (silent bug, application-level miswrite) that replicates from primary to secondary before being detected. IRBC programmes with point-in-time recovery and integrity checking recover from a pre-corruption point; programmes that rely solely on the latest replica discover that both copies are corrupt. The standard expects the data protection design to include the integrity dimension and the point-in-time recovery capability.

Failure modes the standard is designed to surface

ISO/IEC 27031 is forgiving on the choice of tooling, the recovery architecture, and the depth of exercise per service. It is unforgiving about a small number of patterns that turn the IRBC programme cosmetic rather than operational. The patterns below recur across IRBC programmes and are the ones that erode the year-over-year continuity audits, regulators, and audit committees increasingly read against.

  • Documenting without testing. The most common IRBC failure mode. The plan reads well, the procedures are documented, the dependency map is current, and nothing has been exercised. The first material disruption is the first test. Programmes that file the IRBC plan as a one-time compliance artefact and never execute against it produce a paper readiness that does not survive contact with a real event.
  • Setting RTO and RPO without business owner agreement. The recovery commitments are set by ICT in isolation against the technical capability of the design rather than against the business impact of the disruption. The plan looks coherent until a real incident exceeds the RTO and the business owner discovers the commitment is not what they would have asked for. The standard expects the BIA-driven owner agreement rather than the ICT-only target.
  • Treating the IRBC plan as a static document. The plan is written once, signed, filed, and not refreshed when the production estate changes. Services enter and leave the estate, suppliers change, cloud providers add regions, organisational ownership shifts, regulator obligations change, and the plan no longer matches the system it describes. The maintain-and-improve phase is the discipline that prevents this drift.
  • Operating IRBC in isolation from incident management and crisis management. The IRBC plan documents the recovery procedures but the incident-response runbooks do not name the trigger to activate IRBC, the crisis management plan does not name the IRBC decision authority, and the operators do not know which document to read at which step. The holistic principle expects the three disciplines to read as one integrated operational response.
  • Ignoring the supplier-side IRBC. The acquirer-side IRBC plan assumes the supplier-side recovery posture without verifying it. The supplier-side incident affects the acquirer-side service and the acquirer discovers the supplier RTO is longer than the acquirer commitment to its own customers. The standard pairs with ISO/IEC 27036 so the supplier-side BCDR evidence reads into the acquirer-side IRBC.
  • Treating cloud-provider regions as guaranteed availability. The acquirer hosts a Tier 1 workload in a single cloud-provider region without cross-region failover and assumes the cloud provider absorbs the region-level failure modes. When the region experiences a multi-hour outage, the acquirer-side IRBC has no recovery posture beyond waiting. The dependency-mapping and strategy phases are expected to surface this exposure.
  • Skipping the after-action review. The exercise is executed, the achieved metrics are recorded, and no after-action review is produced. The exercise becomes a compliance artefact instead of a learning artefact, the gaps do not become corrective actions, and the next cycle repeats the same exercise without improvement. The continual improvement principle expects every exercise to feed the next cycle.
  • Letting the recovery procedures fall behind the system they describe. The application moves from a stateful database to a managed service, the storage migrates from one block-storage technology to another, the failover automation is rewritten, and the recovery procedure still references the prior design. The change management measure is the operational discipline that prevents the procedure from aging out between exercises.
  • Counting management review as a quarterly meeting. The management review cycle is expected to read the per-service performance, the exercise outcomes, the incident learnings, the residual risk position, the resource requests, and the management decisions against a documented agenda. Reviews that compress this into a status update lose the dimension that distinguishes a managed programme from a maintained document.
  • Confusing IRBC with disaster recovery planning. Disaster recovery planning is one input into IRBC, but IRBC is a broader programme covering resilience, recovery, incident response, crisis management, dependency mapping, change management, exercise, and continual improvement. Programmes that treat IRBC as a DR plan rename lose the structural breadth the standard depends on.

How ISO/IEC 27031 relates to adjacent regimes

ISO/IEC 27031 sits in a busy continuity, regulatory, and standards neighbourhood. The relationships below are the ones programmes encounter most often when they read the standard against the rest of the continuity regime. Programmes operating across regions and sectors use ISO/IEC 27031 as the ICT-readiness spine and read ISO 22301, NIST SP 800-34, NIST CSF 2.0 RC.RP, DORA, NIS2, ISO 27001 Annex A 5.29 and 5.30, SOC 2 A1, and ITIL service continuity as the framework-specific reads alongside.

ISO/IEC 27031 vs ISO 22301

ISO 22301 (Business continuity management systems) is the certifiable business continuity standard for the broader organisation: business impact analysis, business continuity strategy, business continuity plans and procedures, exercising and testing, performance evaluation, and continual improvement. ISO/IEC 27031 is the ICT-readiness companion that operates beneath ISO 22301 clauses 8.2 to 8.5 for the ICT scope. Programmes certifying against ISO 22301 typically operate IRBC against ISO/IEC 27031 so the BCMS auditor reads the ICT-side evidence against an international ICT-readiness standard rather than against a programme-specific plan.

ISO/IEC 27031 vs NIST SP 800-34r1

NIST SP 800-34r1 (Contingency Planning Guide for Federal Information Systems) is the US federal contingency planning guide that covers business impact analysis, contingency strategy, plan documentation, testing, training, plan maintenance, and the relationships between the various continuity disciplines (BCP, DRP, COOP, ISCP, OEP, CRP). ISO/IEC 27031 is the international ICT-readiness standard. The two are complementary rather than competing: 800-34r1 supplies the federal-grade contingency planning vocabulary and the integration model across the continuity-plan family; ISO/IEC 27031 supplies the international ICT-readiness operating standard. Programmes operating across both regimes use 800-34r1 as the integration spine and ISO/IEC 27031 as the ICT-readiness companion.

ISO/IEC 27031 vs NIST CSF 2.0 Recover function

NIST CSF 2.0 Recover function (RC.RP recovery planning, RC.CO communications, RC.IM improvement) covers the framework-level outcome statements for recovery. ISO/IEC 27031 reads beneath the Recover function as the operating standard the RC.RP outcomes are evidenced through. Programmes operating against the CSF 2.0 outcome model use ISO/IEC 27031 as the implementation companion that supplies the operating depth the framework-level outcomes are achieved through.

ISO/IEC 27031 vs DORA Articles 11 and 12

DORA Article 11 (ICT business continuity policy) and Article 12 (backup, restoration, and recovery procedures and methods) impose detailed ICT continuity obligations on EU financial entities. Article 11 expects a documented ICT business continuity policy and an ICT response and recovery plan with periodic testing. Article 12 expects backup policies and procedures, restoration and recovery procedures, and the recovery infrastructure design. ISO/IEC 27031 reads as the operating standard the DORA Article 11 policy, the recovery procedures, the testing programme, and the backup and restoration discipline read against. Financial entities subject to DORA build the ICT continuity evidence pack against the same IRBC operating record the standard expects.

ISO/IEC 27031 vs NIS2 Article 21(2)(c)

NIS2 Article 21(2)(c) requires essential and important entities to manage business continuity, including backup management, disaster recovery, and crisis management. ISO/IEC 27031 reads as the operating standard for the ICT-readiness scope of this requirement. The directive does not name a specific standard; ISO/IEC 27031 is the recognised international ICT-readiness reference programmes operating across the NIS2 sectors typically adopt to demonstrate the technical depth of the management measures.

ISO/IEC 27031 vs ISO/IEC 27001 Annex A 5.29 and A 5.30

ISO/IEC 27001:2022 Annex A 5.29 (information security during disruption) and A 5.30 (ICT readiness for business continuity) are the certifiable controls in the ISMS that read directly against ISO/IEC 27031. A 5.30 explicitly names ICT readiness for business continuity as a required control. Programmes operating against ISO 27001 use ISO/IEC 27031 as the implementation companion that supplies the operating depth Annex A 5.30 references. The Statement of Applicability documents whether A 5.30 is in scope; almost every ISMS retains it.

ISO/IEC 27031 vs SOC 2 Availability criteria

SOC 2 Trust Services Criteria A1.1 (capacity), A1.2 (environmental protections and recovery infrastructure), and A1.3 (recovery plan testing) cover availability commitments service organisations evidence to user entities and auditors. ISO/IEC 27031 reads beneath the A1 criteria as the operating standard the recovery infrastructure, the recovery procedures, and the testing record read against. Service organisations operating against SOC 2 use IRBC discipline to produce the A1 evidence pack continuously rather than reconstructing it at examination time.

ISO/IEC 27031 vs ITIL Service Continuity Management

ITIL Service Continuity Management is the IT service management discipline that covers continuity planning, risk assessment, and recovery option selection for IT services. ISO/IEC 27031 is the international ICT-readiness standard. The two read as compatible disciplines: ITIL supplies the service management vocabulary and the integration with the wider IT operating model; ISO/IEC 27031 supplies the international standard the BCMS audit reads against. Programmes operating ITIL service continuity adopt ISO/IEC 27031 as the standards reference the audit reads against.

Where ISO/IEC 27031 sits next to other framework pages

ISO/IEC 27031 is the ICT-readiness operating standard; the adjacent framework pages cover the regimes the IRBC programme reads alongside. The pages below are the ones IRBC programmes most often read together.

  • The ISO/IEC 27001 framework page covers the certifiable ISMS standard. Annex A 5.29 (information security during disruption) and A 5.30 (ICT readiness for business continuity) are the certifiable controls that read directly against ISO/IEC 27031.
  • The DORA framework page covers the EU Digital Operational Resilience Act for financial entities. Article 11 (ICT business continuity policy) and Article 12 (backup, restoration, and recovery procedures) read against the same IRBC operating record ISO/IEC 27031 expects.
  • The NIS2 framework page covers the EU directive on cybersecurity for essential and important entities. Article 21(2)(c) requires business continuity management for which ISO/IEC 27031 is the ICT-readiness operating standard.
  • The NIST CSF 2.0 framework page covers the framework-level outcome model. The Recover function (RC.RP recovery planning, RC.CO communications, RC.IM improvement) reads against ISO/IEC 27031 as the implementation companion that supplies the operating depth the outcome statements are achieved through.
  • The SOC 2 framework page covers the AICPA Trust Services Criteria. A1.2 (environmental protections and recovery infrastructure) and A1.3 (recovery plan testing) read against the same recovery infrastructure, recovery procedures, and testing record ISO/IEC 27031 expects.
  • The ISO/IEC 27036 framework page covers the supplier-relationship security standard. The supplier-side BCDR clause in ISO/IEC 27036-2 reads alongside IRBC so the acquirer-side recovery posture does not assume supplier-side readiness without evidence.
  • The ISO/IEC 27035 framework page covers the incident management standard. IRBC reads incident response measures from ISO/IEC 27035; the handoff between operational incident response and IRBC recovery declaration is the integration the holistic principle expects.
  • The ISO/IEC 27005 framework page covers the information security risk management standard. The risk inputs feeding the per-service tiering, the recovery design, and the residual risk acceptance read against ISO/IEC 27005 risk discipline.
  • The APRA CPS 234 framework page covers the Australian prudential standard for information security. The information security capability requirements include resilience and recovery expectations that ISO/IEC 27031 reads beneath as the operating standard.

Where SecPortal fits in an IRBC programme

SecPortal is the operating layer for the IRBC programme record, not a replacement for the standard itself, not an IT service management platform, not a business continuity management system, and not a backup and recovery infrastructure controller. The platform handles the workstreams that produce the ISO/IEC 27031 evidence (engagement structure for the per-cycle IRBC work, finding intake from after-action reviews and audits and incident post-mortems, severity scoring under CVSS 3.1 where availability is the impact axis, retest evidence paired to the corrective action follow-up, exception register with named owner and expiry, document management for the policy and procedures and exercise records, the activity log BCMS auditors and regulators read against). The same workspace that hosts the IRBC programme record hosts the technical assessment evidence the recovery design depends on, so the line from policy to evidence stays traceable.

  • Engagement management dedicated to the IRBC operating cycle, with per-cycle engagements for the IRBC review, the exercise programme, the management review, and the change-impact reviews so the PIRBC cadence reads as scheduled work rather than as reactive triage
  • Findings management with CVSS 3.1 scoring, CWE tags, and structured fields so the gaps surfaced by exercises, after-action reviews, audits, and incident post-mortems read as the same finding record the rest of the security programme uses, and the corrective action follow-up does not bifurcate into an IRBC-only track and a security-only track
  • Bulk finding import that converts the after-action records, the audit findings, the regulator review observations, and the third-party assessment outputs (cloud-provider compliance reports, supplier BCDR attestations, sector-regulator findings) into structured findings on the workspace, so the IRBC evidence pack reads against the same finding ledger the operational security programme uses
  • Document management for the IRBC policy, the IRBC scope statement, the BIA outputs snapshot, the ICT continuity strategy, the recovery procedures per service with version history, the exercise calendar, the after-action records, the incident response playbooks, the crisis management plan, the dependency map snapshots, the training records, and the management review minutes, with version history per artefact and named custodian per file
  • Activity log with CSV export that captures every state change to an IRBC engagement, an exercise record, a recovery procedure update, a dependency-map refresh, a finding from after-action review, a corrective action, a change-impact assessment, or a management review outcome, so an internal auditor, an external auditor, a regulator, or an audit committee can reconstruct the IRBC operating record without a multi-team excavation
  • Compliance tracking that reads the same IRBC evidence pack across ISO/IEC 27031, ISO 22301, NIST SP 800-34, NIST CSF 2.0 RC.RP, DORA Article 11 and 12, NIS2 Article 21(2)(c), ISO/IEC 27001 Annex A 5.29 and 5.30, SOC 2 A1.2 and A1.3, and the sector-regulator reads (FFIEC, EBA, MAS TRM, APRA CPS 234, RBI, HKMA)
  • Continuous monitoring schedules (daily, weekly, biweekly, monthly) that run the external-scan and authenticated-scan baselines against the in-scope ICT services on cadence, so the operational availability exposure surface reads alongside the IRBC evidence pack rather than as a separate track
  • Retesting workflows that pair each exercise after-action finding to a verification step so the corrective action is evidenced as closed against the same record the exercise produced, and the follow-up cycle is not lost between PIRBC iterations
  • AI report generation that turns the operating IRBC record into an audit-committee narrative, a regulator pack (DORA ICT continuity policy summary, NIS2 management measures evidence, SOC 2 A1 evidence summary), and an executive sponsor briefing without rewriting the underlying record
  • Team management with role-based access (owner, admin, member, viewer, billing) that keeps ICT operators, application owners, business owners, the IRBC coordinator, the crisis decision authority, GRC and compliance, internal audit, and the executive sponsor on the same workspace with appropriate scoping per service tier and per business line
  • Multi-factor authentication enforcement at workspace level for the IRBC operating records, so the identity assurance the standard expects for the operating record applies at access time as well as evidence time
  • Finding overrides with the eight-field decision chain (rationale, scope, named approver, expiry, compensating control, residual risk acceptance, refresh trigger, audit annotation) for the residual gaps that cannot be closed within one PIRBC cycle, so the deferral is evidenced rather than silent

What SecPortal does not do

ISO/IEC 27031 is a lifecycle standard that depends on the organisation operating ICT, business continuity, incident management, and crisis management as coordinated functions. SecPortal is the operating record for the IRBC slice, not the business continuity management system, not the IT service management platform, not the backup and recovery infrastructure, and not the third-party audit firm. The honest scope below reads against the ISO/IEC 27031 boundary so the platform commitment is unambiguous.

  • SecPortal is not a business continuity management system. The platform does not run the wider ISO 22301 programme (the BIA workshops, the strategy workshops, the BCMS-wide policy authoring, the executive crisis simulations). The BCMS lives where the wider continuity programme is operated; SecPortal carries the IRBC-specific operating record that reads into the BCMS evidence pack.
  • SecPortal is not an IT service management platform. The change management, incident management, and problem management workflows that ITSM platforms (ServiceNow, Jira Service Management, BMC Helix, ManageEngine ServiceDesk Plus, Cherwell, Freshservice) run for the wider ICT operation continue to live there. SecPortal carries the IRBC-side operating record alongside the ITSM record rather than replacing it.
  • SecPortal does not execute the failover, the restoration, the disaster recovery automation, or the live recovery procedure. The recovery action is executed by the responsible ICT operator against the documented procedure on the platforms the service actually runs on. SecPortal carries the procedure, the exercise record, the after-action review, the corrective action follow-up, and the evidence the BCMS audit reads against.
  • SecPortal does not connect to AWS Resilience Hub, Azure Site Recovery, Google Cloud Disaster Recovery, VMware Site Recovery Manager, Veeam, Commvault, Rubrik, Cohesity, Zerto, or any other backup and recovery infrastructure. The infrastructure controls the technical recovery; SecPortal carries the IRBC programme record the infrastructure operates against.
  • SecPortal does not run the BIA. The BIA is the wider business continuity discipline owned by the business continuity function. SecPortal accepts the BIA outputs (per-service RTO, RPO, MTPD; dependency footprint; business owner) and reads against them; the BIA workshops happen where the wider continuity programme runs them.
  • SecPortal does not issue or verify ISO 22301, ISO/IEC 27031, or SOC 2 certifications. Certification is performed by an accredited certification body or CPA firm. SecPortal carries the operating record the auditors and the regulators read against, with the artefact pack the audit fieldwork reads continuously rather than reconstructed at examination time.
  • SecPortal does not replace the named IRBC programme owner, the IRBC coordinator, the recovery owner per service, the crisis decision authority, or the regulator notification owner. The platform carries the operating record so the programme is durable rather than tribal; the named owner runs the programme, the coordinator operates the cadence, the recovery owner exercises the procedure, the crisis authority decides, and the regulator owner notifies.

The operational workstreams the IRBC programme reads against already exist as named use cases on SecPortal. The security leadership reporting workflow covers the executive and audit-committee read against the IRBC programme posture. The audit fieldwork evidence request fulfillment workflow covers the BCMS audit liaison the IRBC evidence pack reads against. The cross-framework control mapping workflow reads the same IRBC evidence pack across ISO/IEC 27031, ISO 22301, NIST CSF 2.0 RC.RP, DORA Article 11 and 12, NIS2 Article 21(2)(c), ISO/IEC 27001 Annex A 5.29 and 5.30, and SOC 2 A1 so the cross-regime read is reconcilable rather than reconciled per audit. The control gap remediation workflow carries the corrective action follow-up the exercise after-action records feed. The cyber insurance security evidence workflow bundles the IRBC evidence pack into the underwriter and broker read at renewal.

For GRC and compliance teams running the IRBC programme alongside the wider BCMS, the GRC and compliance teams workspace bundles the platform with the engagement structure the IRBC audit cadence reads against. For security operations leaders carrying the operational continuity posture into the management review, the security operations leaders workspace covers the per-cycle exercise programme, the after-action review, and the incident-driven improvement loop. For CISOs and security leaders carrying the audit-committee read against the ICT continuity posture, the CISOs and security leaders workspace covers the board-side reporting model that sits on top of the IRBC operating record.

For deeper reading on the disciplines this standard reads against, the DORA ICT third-party risk management implementation guide covers the financial-services-specific ICT continuity expectations DORA Article 11 and 12 read against. The incident response plan guide covers the incident-response discipline that hands off into the IRBC recovery declaration. The ransomware readiness program guide covers the ransomware-specific scenario the IRBC backup and recovery posture is most often tested against. The incident response tabletop exercise guide covers the desk-based exercise format the IRBC walkthrough cadence uses. The continuous control monitoring cadence research covers the cadence economics the IRBC exercise programme inherits from when balancing test cost against capability assurance.

Key control areas

SecPortal helps you track and manage compliance across these domains.

Scope: ICT readiness inside business continuity

ISO/IEC 27031 is the ICT-readiness companion to ISO 22301 (business continuity management). The standard does not replace ISO 22301; it specifies how ICT services are made ready to support the business continuity objectives ISO 22301 expects. Programmes that conflate the two end up either with ICT recovery plans no business owner reads or business continuity plans the ICT team cannot operate against. ISO/IEC 27031 names the ICT-specific scope so the two disciplines read into one programme.

The ten guiding principles of IRBC

The standard names ten guiding principles that any IRBC programme reads against: top management commitment, holistic approach (information security, business continuity, IT service continuity), risk-based prioritisation, lifecycle approach (PIRBC), continual improvement, embedded culture, defined roles and responsibilities, demonstrable competence, periodic review and testing, and effective communication. The principles are the orientation that distinguishes an IRBC programme from a one-off DR plan refresh.

The PIRBC operating model

IRBC is operated through four phases: Plan (establish IRBC strategy, policy, scope, and governance), Implement and Operate (deploy ICT readiness measures, document procedures, integrate with incident and crisis management), Monitor and Review (exercise, measure, audit, surface deviations), and Maintain and Improve (refresh per cycle, on event, and on change). The PIRBC cycle is the operating spine the evidence pack reads against.

RTO, RPO, and MTPD alignment with the BIA

IRBC reads RTO (recovery time objective), RPO (recovery point objective), and MTPD (maximum tolerable period of disruption) from the business impact analysis ISO 22301 expects. RTO is the target time within which ICT services must be restored. RPO is the target maximum age of data that can be lost. MTPD is the point at which disruption becomes unacceptable to the business. ISO/IEC 27031 expects the three values to be set by the business owner, agreed by ICT, evidenced in the recovery design, and validated through exercise.

ICT readiness measures

The standard names the categories of measures programmes deploy to meet the RTO, RPO, and MTPD per service: resilience measures (redundancy, fault tolerance, geographic diversity), recovery measures (backup, restore, failover, fallback), incident response measures (detection, escalation, containment, communication), and crisis management measures (decision authority, stakeholder communication, regulator notification). Each measure carries documented procedures, named operators, and exercise evidence.

Exercise and testing cadence

IRBC is unforgiving on the difference between a documented plan and a tested capability. The standard expects an exercise programme that covers desk-based walkthroughs, simulation exercises, partial failover tests, and full failover tests on a cadence proportionate to the criticality of the service. Each exercise produces an after-action record, the gaps surface as findings, and the corrective actions feed the maintain-and-improve phase. Programmes that never test discover the gap at the first incident.

The IRBC evidence pack

The evidence pack the auditor, the regulator, and the audit committee read against the IRBC programme covers the IRBC policy, the IRBC scope statement, the BIA outputs (RTO, RPO, MTPD per critical service), the ICT continuity strategy, the ICT recovery procedures per service, the exercise programme and after-action records, the incident response playbooks, the crisis management plan, the dependency map (internal, supplier, cloud), the training and awareness record, the change management record, and the management review minutes.

Cross-walk to ISO 22301

ISO 22301 is the certifiable business continuity management standard. ISO/IEC 27031 is the ICT-readiness operating companion that sits beneath ISO 22301 clauses 8.2 to 8.5 (business impact analysis, risk assessment, business continuity strategies and solutions, business continuity plans and procedures). Programmes certifying against ISO 22301 typically operate IRBC under ISO/IEC 27031 for the ICT-side evidence the BCMS auditor reads.

Cross-walk to DORA Article 11 and 12

DORA Article 11 (ICT business continuity policy) and Article 12 (backup, restoration, and recovery procedures and methods) impose detailed ICT continuity obligations on EU financial entities. ISO/IEC 27031 reads as the operating standard the DORA Article 11 policy, the recovery procedures, the testing programme, and the backup and restoration discipline read against. Financial entities subject to DORA build the ICT continuity evidence pack against the same IRBC operating record the standard expects.

Cross-walk to NIS2 Article 21(2)(c) and NIST SP 800-34

NIS2 Article 21(2)(c) requires essential and important entities to manage business continuity, including backup management, disaster recovery, and crisis management. NIST SP 800-34r1 is the US federal contingency planning guide for federal information systems. ISO/IEC 27031 sits across both as the international ICT-readiness standard, and reads alongside the NIST CSF 2.0 Recover function (RC.RP recovery planning) for the framework-level read.

Cross-walk to ISO 27001 Annex A 5.29 and 5.30

ISO/IEC 27001:2022 Annex A 5.29 (information security during disruption) and A 5.30 (ICT readiness for business continuity) are the certifiable controls in the ISMS that read directly against ISO/IEC 27031. A 5.30 explicitly names ICT readiness for business continuity as a required control. Programmes operating against ISO 27001 use ISO/IEC 27031 as the implementation companion that supplies the operating depth Annex A 5.30 references.

Cross-walk to SOC 2 A1.2 and A1.3

SOC 2 Trust Services Criteria A1.2 (environmental protections and recovery infrastructure) and A1.3 (recovery plan testing) cover availability commitments service organisations evidence to user entities and auditors. ISO/IEC 27031 reads beneath the A1 criteria as the operating standard the recovery infrastructure, the recovery procedures, and the testing record read against. Service organisations operating against SOC 2 use IRBC discipline to produce the A1 evidence pack continuously.

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Compliance tracking without a full GRC platform

Document management for every security engagement

Every action recorded across the workspace

Collaborate across your entire team

Monitor continuously catch regressions early

AI-powered reports in seconds, not days

Verify fixes and track reopens on the same finding record

Finding overrides that survive every scan cycle

Bulk finding import bring your scanner data with you

Multi-factor authentication on every workspace

Run the IRBC programme on one operating workspace

Hold the IRBC policy, the BIA outputs, the ICT recovery procedures per service, the exercise programme and after-action records, the dependency map, the training record, the change management record, and the management review minutes on one workspace. Carry the same record into ISO 22301, DORA Article 11 and 12, NIS2 Article 21(2)(c), NIST CSF 2.0 RC.RP, ISO/IEC 27001 Annex A 5.29 and 5.30, and SOC 2 A1.2 and A1.3 without rebuilding the evidence pack. Start free.

Get Started Free

No credit card required. Free plan available forever.