ISO/IEC 27031 (ICT Continuity)

1. Introduction: ISO/IEC 27031 and the Discipline of ICT Continuity

ISO/IEC 27031 is the international standard that gives structure to a deceptively simple business truth: modern organisations do not survive disruption unless their Information and Communication Technology (ICT) survives with them. Formally titled 'Information technology - Security techniques - Guidelines for information and communication technology readiness for business continuity' (the 2011 edition), and revised in 2025 as 'Information security, cybersecurity and privacy protection - Information and communication technology (ICT) readiness for business continuity', the standard describes the concepts, principles and methods by which an organisation prepares its ICT to underpin overall business continuity. It sits at the junction of three worlds that are frequently managed in isolation: business continuity management (the ISO 22301 world), information security management (the ISO/IEC 27001 world), and IT service management and disaster recovery (the ITIL and DR-plan world).

The core construct ISO 27031 introduces is IRBC - ICT Readiness for Business Continuity. IRBC is the state of an organisation's ICT being prepared to support its business operations should an incident or disruption (and its consequential changes) occur. Where classic disaster recovery answers the question 'how do we rebuild the data centre after it burns down?', IRBC answers a broader and more strategic question: 'how do we ensure that the ICT services underpinning our prioritised business activities remain available, or can be resumed within agreed timeframes, across the full spectrum of disruptive events?' IRBC therefore spans prevention (stopping incidents), detection (spotting them early), response (containing and recovering), and recovery and improvement (returning to normal and learning). It is explicitly built around the Plan-Do-Check-Act (PDCA) cycle, mirroring the management-system logic of ISO/IEC 27001 and ISO 22301 so the three can be integrated rather than run as competing programmes.

This guide is written for two audiences at once. For the auditor or assessor, it enumerates every element of the standard that must be examined, the questions to ask, and the evidence that demonstrates conformity or readiness. For the implementer or product and infrastructure team, it lays out a phased path to build IRBC capability, the deliverables at each stage, and the maturity model against which progress is measured. Because ISO 27031 is a guidance standard (it uses 'should', not 'shall', and is not, on its own, a certifiable standard), assessment against it is a readiness or gap assessment rather than a pass/fail certification audit - a distinction we return to repeatedly.

Why does IRBC deserve its own standard rather than being folded into generic disaster recovery? The answer lies in how disruption actually behaves in modern estates. Contemporary ICT is a mesh of interdependent services: an application depends on a database, which depends on storage, which depends on a storage network, which depends on power and cooling; the same application depends on an identity provider, a DNS resolver, TLS certificates, an API gateway and one or more third-party SaaS integrations. A single failure rarely stays contained - it cascades. Classic DR planning, built around rebuilding named servers, struggles to reason about these cascades because it lacks the business-priority lens that tells you which services to recover first and by when. IRBC supplies that lens. By anchoring every recovery decision to a prioritised business activity and an agreed recovery objective, it turns a sprawling technical problem into a bounded, sequenced, testable one. This is why regulators in banking, critical infrastructure and the emerging EU digital-operational-resilience regime increasingly expect organisations to demonstrate IRBC-style capability - tested recovery of prioritised ICT services within stated timeframes - rather than merely the existence of a DR document.

2. What is ISO/IEC 27031?

ISO/IEC 27031 is a guidance standard within the ISO/IEC 27000 family (the information security management system family) that focuses specifically on ICT readiness for business continuity. It was first published in March 2011 and was revised in 2025 to align with the modernised structure and terminology of the wider 27000 series and to reflect the growth of cloud, hybrid infrastructure and cyber-resilience thinking. The standard is deliberately generic: it applies to any organisation - public or private, large or small, in any sector - that wishes to understand and enhance its ICT's ability to support business continuity.

Crucially, ISO 27031 does not stand alone. It is a bridge document. ISO 22301 (business continuity management systems) sets the top-level requirements for a Business Continuity Management System (BCMS) and defines prioritised activities, Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) through Business Impact Analysis (BIA). ISO 27031 takes those business-level requirements and translates them into ICT terms: which ICT services support each prioritised activity, what continuity those services need, and how the ICT function must be organised, resourced and operated to deliver it. ISO/IEC 27001 (and its control catalogue in ISO/IEC 27002) provides the security controls that protect the ICT that IRBC depends on. In practice, a mature organisation runs an integrated management system where these three standards reinforce each other. The 2011 edition articulated IRBC around prevention, detection, response, recovery and improvement; the 2025 revision retained this spine while modernising terminology to reflect cyber-resilience, cloud dependency and privacy considerations, and re-aligning clause structure with the harmonised ISO management-system format. Both editions share the same operating philosophy: ICT continuity must be planned, resourced, tested and continually improved as a managed capability, never assumed.

The value proposition of ISO 27031 is that it closes a well-known gap. Business continuity plans are often written by business teams who assume ICT 'will be there', while DR plans are often written by infrastructure teams who focus on rebuilding systems without a clear line of sight to which business processes truly depend on them and by when they must be back. IRBC forces that alignment: every ICT continuity decision is traceable back to a prioritised business activity and its agreed recovery objectives.

There is also a strategic, board-level reason to adopt ISO 27031 rather than leave ICT continuity to informal practice. Continuity capability is expensive - redundant infrastructure, alternate sites, cloud failover capacity and testing all cost money - and without a business-priority framework those investments are hard to justify or optimise. IRBC provides the economic logic: it tells you which services warrant a hot, active-active posture (because their MTPD is measured in minutes and downtime is measured in lost revenue or regulatory breach) and which can tolerate a slower, cheaper recovery. This lets an organisation spend its continuity budget where it actually reduces risk, and lets leadership defend that spend with a clear line from investment to protected business outcome. Adopting the standard therefore delivers not only resilience but cost discipline and a credible narrative for regulators, insurers and customers who increasingly ask to see it.

Key terms you must know

3. Who Must Comply (and Who Should Adopt It)?

Because ISO 27031 is guidance rather than a certifiable requirements standard, no organisation is legally 'required to comply' with ISO 27031 in the way one complies with a law or a certifiable standard. Instead, organisations adopt it because a regulator, customer, board, or parent standard expects demonstrable ICT continuity capability, and ISO 27031 is the recognised blueprint for achieving it. The following groups have the strongest drivers.

• Boards and audit committees seeking assurance that ICT can survive foreseeable disruption.
• CIOs / CISOs needing a defensible, standards-based ICT resilience programme.
• IT service management and DR teams wanting to align technical recovery with business priorities.
• Risk and compliance functions integrating continuity into an enterprise risk framework.
• Procurement and vendor-management teams assessing third-party resilience.

4. Structure of ISO/IEC 27031

ISO 27031 is organised around the PDCA management cycle and a set of guidance clauses that walk an organisation from establishing an IRBC programme through to continual improvement. Unlike a control-catalogue standard, it does not present numbered 'controls' in the ISO 27002 sense; instead it defines elements and activities within each PDCA phase. The table below sets out the standard's principal building blocks as families of guidance, which we then decompose into an auditable checklist in Section 5. Clause numbering is indicative of the standard's logical structure and should be confirmed against your licensed copy of the current edition.

5. Master Assessment Checklist - Every IRBC Element Enumerated

This is the operational heart of the guide. For every element group in ISO 27031 we set out, in a dedicated table, what an auditor must verify and the typical evidence that demonstrates conformity or readiness. Nothing is skipped. Assessors should score each line (for example against the maturity model in Section 8) and record findings against it. Implementers can read the same tables as a build specification: every 'What to verify' line is something you must be able to demonstrate.

A word on how to use these tables in practice. During an assessment, do not treat the 'Typical evidence' column as a tick-box wish-list to be waved through on sight of a document title. The discipline of an auditor-grade review is to open the artefact, confirm it is current, confirm it is owned, and - most importantly - confirm it corresponds to what actually happens. A backup policy that mandates daily immutable backups means nothing if the backup job has been silently failing for six weeks; a runbook is worthless if the person named in it left the organisation last quarter and no deputy exists. Wherever the evidence is a claim of capability (recovery, restore, failover, notification), the assessor should seek proof that the capability was exercised, not merely designed. This principle - design plus demonstrated operation - runs through every table below.

5.1 IRBC Programme Governance and Management Commitment (Plan)

5.2 Context, Legal and Interested-Party Requirements

5.3 Business Impact Analysis and ICT Dependency Mapping (Plan)

5.4 ICT Continuity Risk Assessment (Plan)

5.5 IRBC Strategy Determination and Selection (Plan)

5.6 Prevention and Protection Controls

5.7 Incident Detection, Triggers and Activation (Do)

5.8 IRBC Response Structure and Plans (Do)

5.9 Resource Provisioning (People, Facilities, Technology, Data, Processes, Suppliers)

5.10 Awareness, Training and Competence

5.11 Testing, Exercising and Validation (Check)

5.12 Monitoring, Measurement and Management Review (Check)

5.13 Improvement, Corrective Action and Lessons Learned (Act)

5.14 Documentation and Records Control

6. Scoping the IRBC Programme

Scope defines what the IRBC programme covers and, just as importantly, what it does not. A well-defined scope prevents both over-engineering (protecting low-value systems to the same standard as revenue-critical ones) and dangerous under-coverage (leaving a dependency such as DNS, identity or a single telecom link outside the boundary). Scope in ISO 27031 is derived top-down from the BCMS: you start with the prioritised business activities and their recovery objectives, then include the ICT services and their dependencies that support them. This top-down derivation is what distinguishes a defensible IRBC scope from an arbitrary one. If you scope bottom-up ('let us protect the systems we happen to think are important'), you will inevitably over-invest in some systems and leave others - often the quiet, invisible dependencies - dangerously exposed. Scoping top-down forces a chain of reasoning that an auditor can follow and challenge: this business activity is prioritised because its loss causes unacceptable impact within its MTPD; it depends on these ICT services; those services depend on this infrastructure and these suppliers; therefore all of the above are in scope, at recovery objectives inherited from the business activity.

• Start from the BIA: include only the ICT services that support prioritised business activities, but include ALL of their dependencies.
• Define boundaries explicitly by site, business unit, service, system and data - and state exclusions with a documented rationale.
• Include upstream infrastructure often forgotten: identity/authentication, DNS, network, power, cloud control planes and internet egress.
• Include third-party and cloud services in scope even though you do not operate them - your recovery still depends on them.
• Decide the treatment of non-prioritised systems (may be recovered on a best-effort basis after prioritised services).
• Revisit scope whenever the business changes: new products, cloud migration, mergers, or new regulatory obligations.
• Document scope in a statement approved by the accountable executive, mirroring the ISMS/BCMS scope where they overlap.

7. Implementation Approach - A Phased Programme

IRBC is best delivered as a phased programme aligned to the PDCA cycle. Each phase below lists the core activities and the concrete deliverables an auditor will expect to see and an implementer must produce.

Phase 1 - Initiation and Governance (Plan)

• Activities: secure executive sponsorship; define IRBC policy, objectives and scope; assign roles (RACI); establish steering governance; integrate with existing BCMS/ISMS.
• Deliverables: approved IRBC policy, scope statement, objectives register, RACI matrix, programme charter, resource/budget plan.

Phase 2 - Analysis: BIA, Dependency Mapping and Risk (Plan)

• Activities: obtain/validate BIA outputs; map business activities to ICT services; derive ICT RTO/RPO; map dependencies and single points of failure; perform ICT continuity risk assessment.
• Deliverables: ICT dependency map, recovery objective register, SPOF analysis, ICT continuity risk assessment and treatment plan.

Phase 3 - Strategy Design (Plan)

• Activities: identify and evaluate strategy options per service (redundancy, failover, alternate site, cloud DR, manual workaround); select strategies meeting RTO/RPO within budget; secure supplier/cloud continuity contractually.
• Deliverables: IRBC strategy document, strategy decision records, updated DR/cloud contracts and SLAs/OLAs.

Phase 4 - Implementation and Operationalisation (Do)

• Activities: build preventive/protective controls and redundancy; implement backups/replication to meet RPO; establish response structure and teams; author DR runbooks; provision people, facilities, technology; deliver awareness and training; stand up detection, triggers and escalation.
• Deliverables: recovery runbooks per service, response team structure, escalation matrix, backup/replication implementation, training records, monitoring/alerting configuration.

Phase 5 - Validation: Testing and Exercising (Check)

• Activities: build a graduated exercise programme (walkthrough to full failover); execute restore and failover tests; measure actual RTO/RPO; capture findings.
• Deliverables: exercise calendar, test plans and scripts, test reports with measured RTO/RPO, corrective action log.

Phase 6 - Review and Continual Improvement (Check/Act)

• Activities: define and report KPIs; conduct internal review/audit; hold management reviews; drive corrective actions and lessons learned; reassess on change.
• Deliverables: KPI dashboard, internal audit report, management review minutes, corrective action register, updated policy/strategy/plans.

8. IRBC Maturity / Capability Model

Because ISO 27031 is guidance, assessment is best expressed as a maturity or capability rating per element rather than a binary pass/fail. The five-level model below (aligned to common capability-maturity thinking) lets assessors score each Section 5 line and lets programmes set target maturity by service criticality. Scoring at the element level rather than the programme level is deliberate: an organisation may be optimising in backup and replication (Level 5) yet initial in supplier continuity (Level 1). A single aggregate score would hide that imbalance, whereas an element-by-element maturity profile exposes exactly where the weakest links are - and in continuity, capability is only as strong as the weakest link in the recovery chain. Present results as a heat-mapped profile across the Section 5 elements so leadership can see at a glance which areas are ready and which threaten the whole recovery.

9. Assessment and Audit Approach

An ISO 27031 assessment is a readiness/gap assessment against the guidance, typically to prepare for or complement an ISO 22301 certification audit or to satisfy a regulator/customer. It is worth being precise about what such an assessment can and cannot conclude. It cannot award an 'ISO 27031 certificate', because the standard is not certifiable in its own right - there is no accredited certification scheme for it as there is for ISO 22301 or ISO/IEC 27001. What it can and should conclude is a maturity profile, a set of prioritised gaps, and a defensible statement of ICT continuity readiness that regulators, customers and certification bodies for the parent standards will accept as evidence of a well-run IRBC capability. The following ordered steps describe a rigorous engagement that produces exactly that.

1. Define assessment objectives, scope and the edition of ISO 27031 to assess against; confirm relationship to any BCMS/ISMS certification.
2. Review documentation: IRBC policy, scope, BIA, dependency maps, risk assessment, strategies, runbooks, test reports and review records.
3. Conduct stakeholder interviews across executive, IRBC team, IT operations, security and key suppliers to test understanding and ownership.
4. Walk through the Section 5 checklist element by element, scoring each against the maturity model and recording evidence or gaps.
5. Validate recovery capability by examining test/exercise evidence and, where possible, observing or sampling a restore or failover test.
6. Trace at least one prioritised business activity end-to-end: from BIA target, through ICT dependency, strategy, runbook, to a tested recovery meeting RTO/RPO.
7. Assess third-party/cloud continuity evidence and contractual continuity terms.
8. Identify nonconformities/gaps, rate severity, and produce prioritised, costed remediation recommendations.
9. Report findings with an overall maturity profile, per-element scores and a remediation roadmap; agree corrective-action ownership and timelines.
10. Schedule re-assessment/surveillance and integrate findings into the continual-improvement cycle.

10. Evidence Request List

Assemble the following, categorised, before an assessment. Availability and quality of this evidence is itself a strong readiness indicator.

• Governance: IRBC policy, objectives register, scope statement, RACI, steering minutes, budget approval.
• Analysis: BIA report, business-to-ICT dependency maps, recovery objective (RTO/RPO) register, SPOF analysis.
• Risk: ICT continuity risk assessment, risk treatment plan, links to ISMS risk register.
• Strategy: IRBC strategy document, strategy decision records, DR/cloud contracts, SLAs/OLAs.
• Prevention: backup and replication policies/configs, redundancy/architecture diagrams, patching and hardening evidence, immutable-backup evidence.
• Response: DR/IRBC runbooks per service, response team structure, escalation matrix, communication templates, offline-plan storage evidence.
• Detection: monitoring/alerting configuration, SIEM/NOC coverage, documented triggers and thresholds.
• People: skills matrix, on-call rotas, training and competence records, awareness campaign evidence.
• Testing: exercise calendar, test plans/scripts, test reports with measured RTO/RPO, restore-test logs.
• Review & improvement: KPI dashboards, internal audit reports, management review minutes, corrective action register, lessons-learned log.
• Suppliers: third-party BCP attestations, supplier test results, contractual continuity clauses.
• Documentation control: version-controlled document register and records retention evidence.

11. Roles and Responsibilities

12. KPIs to Track

• RTO adherence: percentage of prioritised ICT services whose tested recovery time meets its RTO.
• RPO adherence: percentage of datasets whose recoverable point meets its RPO (measured via restore tests).
• Backup success rate and restore success rate (distinct - a successful backup that cannot restore is a failure).
• Test/exercise coverage: percentage of prioritised services exercised within the defined cycle.
• Test pass rate: percentage of exercises meeting their objectives without critical findings.
• Mean time to detect and mean time to recover for real ICT disruptions.
• Number of open single points of failure and time-to-closure.
• Corrective action closure rate and average age of open actions.
• Percentage of critical suppliers with validated continuity capability.
• IRBC maturity score trend per service tier over successive assessment cycles.
• Currency of runbooks (percentage reviewed within the required period).

13. Readiness Checklist

• IRBC policy approved by top management, communicated and current.
• IRBC scope defined from the BIA and includes all dependencies (identity, DNS, network, cloud, power).
• Prioritised ICT services identified with derived RTO/RPO traceable to business activities.
• ICT dependency map and single-point-of-failure analysis complete and maintained.
• ICT continuity risk assessment and treatment plan in place and aligned to ISMS risk.
• IRBC strategies selected per service and demonstrably meet RTO/RPO within budget.
• Backups and replication implemented and restore-tested against RPO.
• Recovery runbooks written per prioritised service and stored accessibly offline.
• Response team, escalation matrix and activation triggers defined and tested.
• Monitoring and detection in place to trigger IRBC response.
• Awareness and role-based training delivered and recorded.
• Graduated exercise programme executed with measured RTO/RPO results.
• KPIs defined, measured and reported to management.
• Internal review and management review conducted at planned intervals.
• Corrective actions and lessons learned tracked to closure.
• Critical suppliers' continuity contractually assured and tested.
• IRBC integrated with ISO 22301 BCMS and ISO/IEC 27001 ISMS.

14. Common Gaps

• DR plans exist but are never restore-tested, so RTO/RPO are theoretical and fail on the day.
• ICT recovery objectives are set by IT guesswork rather than derived from a business-driven BIA.
• Hidden dependencies (identity, DNS, certificates, single telecom link, cloud control plane) omitted from scope.
• Backups complete successfully but restores are never validated; ransomware exposes non-recoverable or non-immutable backups.
• Cloud and SaaS providers assumed to be resilient with no contractual continuity terms or shared-responsibility clarity.
• Runbooks are stale, unversioned, or stored only online where a disruption makes them inaccessible.
• IRBC treated as a one-off project rather than a continually improving programme; no management review.
• No graduated testing - jumping straight to (or never reaching) full failover exercises.
• IRBC, BCMS and ISMS run as three disconnected silos with conflicting assumptions.
• Single points of failure known but never remediated due to cost, with no formal risk acceptance.
• Communication plans missing, so recovery is technically successful but stakeholders are uninformed.
• Supplier continuity never validated - the weakest link in the recovery chain is the one you do not control.

15. ISO 27031 Mapped to Other Frameworks

Frequently asked questions

Need help with ISO 27031?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.