Comparison GuideEU

DORA vs ISO 22301 ICT resilience and business continuity

DORA and ISO 22301 overlap around resilience, disruption response, testing, suppliers, and evidence, but they are not substitutes.

Use this comparison to separate DORA's legal ICT operational resilience obligations for financial entities from ISO 22301's business continuity management system requirements and certification-oriented assurance.

Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Sections
4

Structured answer sets in this page tree.

Primary sources
6

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated May 9, 2026
Overview

DORA is an EU regulation for digital operational resilience in the financial sector. ISO 22301 is an international standard for business continuity management systems. A financial entity can use ISO 22301 evidence to support continuity discipline, but ISO 22301 certification does not supersede DORA obligations for ICT risk management, major ICT-related incident handling, operational resilience testing, ICT third-party risk, registers of information, or supervisory accountability.

Side-by-side comparison

DORA vs ISO 22301: practical differences

Use these rows to decide what is a DORA legal obligation, what is ISO 22301 continuity management evidence, and where the same record can support both without blurring the distinction.

Review all sources
First framework
DORA

Binding EU digital operational resilience regime for covered financial entities, focused on ICT risk, incidents, testing, ICT third-party risk, registers, and supervision.

Second framework
ISO 22301

International business continuity management system standard for organizations that need a documented, maintained, reviewed, and improved continuity capability.

Comparison row 1

Scope boundary

DORA

DORA targets digital operational resilience in the financial sector. Its scope is tied to financial entities, ICT risk, ICT-supported functions, major ICT-related incidents, resilience testing, and ICT third-party services.

ISO 22301

ISO 22301 targets business continuity management systems. Its scope is set by the organization and covers the management system used to prepare for, respond to, and recover from disruptive incidents.

Operational implication

An ISO 22301 BCMS can support DORA continuity evidence, but it does not decide whether a financial entity is in DORA scope or whether a DORA ICT obligation applies.

Comparison row 2

Covered actors

DORA

DORA work includes ICT risk governance, ICT-related incident management and classification, operational resilience testing, ICT third-party risk management, register-of-information maintenance, and management accountability.

ISO 22301

ISO 22301 work includes BCMS context and scope, leadership, policy, objectives, resources, documented information, BIA and risk assessment, continuity strategies, plans, exercises, internal audit, management review, and improvement.

Operational implication

Map controls at the requirement level. A continuity plan is useful for both, but DORA also needs ICT-specific governance, incident, testing, provider, and register evidence.

Comparison row 3

Trigger

DORA

DORA focuses on ICT-related incidents, including classification of major incidents and cyber threats under DORA technical standards.

ISO 22301

ISO 22301 focuses on disruptive incidents through continuity response, warning and communication, business continuity plans, recovery, exercises, evaluation, and improvement.

Operational implication

A major ICT-related incident record should include DORA classification and reporting evidence. The same event may also create ISO 22301 evidence for plan activation, recovery performance, lessons learned, and corrective action.

Comparison row 4

Core obligations

DORA

DORA requires digital operational resilience testing and includes a specific threat-led penetration testing track for financial entities that meet the applicable criteria.

ISO 22301

ISO 22301 requires an exercise programme and evaluation of business continuity documentation and capabilities as part of the BCMS.

Operational implication

Use ISO 22301 exercises for continuity capability, but do not treat them as DORA TLPT or ICT resilience testing unless the DORA criteria, scope, evidence, and governance are also met.

Comparison row 5

Evidence record

DORA

DORA evidence should show ICT risk decisions, incident classification, testing scope and results, ICT service registers, third-party contract controls, remediation, and management oversight.

ISO 22301

ISO 22301 evidence should show the BCMS scope, policy, objectives, BIA, risk assessment, continuity strategies, plans, exercises, internal audits, management reviews, and improvement actions.

Operational implication

Build one evidence index with two labels per record: the DORA obligation supported and the ISO 22301 BCMS requirement supported. Leave blanks where a record supports only one side.

Comparison row 6

Supplier and third-party risk

DORA

DORA treats ICT third-party risk as a dedicated obligation, including policies for ICT services supporting critical or important functions and register evidence for ICT service arrangements.

ISO 22301

ISO 22301 treats suppliers through continuity dependencies, interested-party needs, resource requirements, continuity strategies, and documented continuity arrangements.

Operational implication

Supplier continuity assessments can be reused, but DORA needs ICT-provider classification, critical or important function linkage, contractual evidence, subcontracting awareness where relevant, and register-ready data.

Comparison row 7

Enforcement

DORA

DORA assurance is supervisory and legal. Covered entities need evidence that can be reviewed through financial-sector governance and supervisory channels.

ISO 22301

ISO 22301 assurance is management-system assurance. Organizations can use internal audits, management review, and external certification or customer assurance where that is part of their assurance model.

Operational implication

ISO 22301 certification may help demonstrate continuity discipline, but it is not a DORA certificate and should not be presented as proof that DORA obligations are complete.

Comparison row 8

Overlap and reuse

DORA

Use DORA when the question is whether a financial entity has met ICT operational resilience, incident, testing, ICT third-party, register, or supervisory evidence duties.

ISO 22301

Use ISO 22301 when the question is whether the organization has a functioning BCMS for disruption preparedness, continuity response, recovery, exercise, audit, review, and improvement.

Operational implication

For every shared control, write the DORA purpose and ISO 22301 purpose separately. If you cannot name both, the control is probably reusable evidence for only one side.

Comparison row 9

Practical decision rule

DORA

DORA targets digital operational resilience in the financial sector. Its scope is tied to financial entities, ICT risk, ICT-supported functions, major ICT-related incidents, resilience testing, and ICT third-party services.

ISO 22301

ISO 22301 targets business continuity management systems. Its scope is set by the organization and covers the management system used to prepare for, respond to, and recover from disruptive incidents.

Operational implication

An ISO 22301 BCMS can support DORA continuity evidence, but it does not decide whether a financial entity is in DORA scope or whether a DORA ICT obligation applies.

Practical decision rule

How should teams decide what to implement?

  • If the issue concerns a covered financial entity's ICT risk, ICT incident, ICT provider, register, testing, or supervisory evidence, start with DORA.
  • If the issue concerns organization-wide continuity capability, BIA, recovery strategy, continuity plans, exercises, internal audit, management review, or continual improvement, start with ISO 22301.
  • If both apply, reuse facts and evidence but keep separate requirement labels, owners, approvals, and review triggers.
  • If ISO 22301 certification is being used in a DORA programme, document exactly which DORA controls it supports and which DORA controls still need separate evidence.
Section 1

The practical takeaway

Treat DORA as the legal control set for covered financial entities and their ICT risk. Treat ISO 22301 as the management-system standard for maintaining business continuity capability across disruptive incidents.

The practical overlap is strongest in service impact analysis, recovery arrangements, exercises, lessons learned, supplier continuity, management review, and documented evidence. The gap is that DORA is ICT-specific and supervisory, while ISO 22301 is organization-wide continuity management and assurance.

  • Use DORA to decide what the financial entity must do for ICT systems, major ICT-related incidents, resilience testing, ICT third-party providers, and the register of information.
  • Use ISO 22301 to structure the business continuity management system: scope, leadership, planning, support, business impact analysis, continuity strategies, plans, exercises, audits, management review, and improvement.
  • Reuse continuity evidence only after tagging which DORA obligation and which ISO 22301 requirement it supports.
Section 2

Where teams usually confuse the two

The mistake is to call every resilience activity 'business continuity' and then assume an ISO 22301 programme covers DORA. DORA uses continuity evidence, but it also asks financial entities to govern ICT risk, classify and report major ICT-related incidents, test digital operational resilience, control ICT third-party risk, and keep prescribed ICT service information.

The reverse mistake is to make DORA the whole continuity programme. ISO 22301 covers a broader BCMS that includes organizational context, interested-party needs, continuity objectives, business impact analysis, continuity strategies and solutions, plans and procedures, exercises, internal audit, management review, and continual improvement.

  • Do not label a business impact analysis as DORA-complete unless it also maps ICT-supported critical or important functions and DORA evidence needs.
  • Do not label an ICT incident playbook as ISO 22301-complete unless it also connects to continuity plans, recovery, exercise results, management review, and corrective action.
  • Do not treat certification, customer questionnaires, or internal audits as a substitute for a DORA supervisory record.
Section 3

Evidence that can be reused

Some records can serve both programmes, especially when they describe service dependencies, recovery needs, exercises, incidents, lessons learned, and management decisions. Reuse works only when the record is specific enough for both reviewers.

A useful shared evidence pack separates the DORA view from the ISO 22301 view. For example, a payment service recovery exercise can show ISO 22301 exercise evidence and also support DORA resilience testing evidence, but the DORA record still needs ICT scope, affected critical or important functions, remediation, and governance accountability.

  • Reusable records: business impact analyses, recovery objectives, continuity strategies, exercise reports, incident lessons learned, management review minutes, supplier continuity assessments, and corrective-action logs.
  • DORA-specific records: ICT risk management policies, major ICT-related incident classification records, register-of-information templates, ICT provider contract evidence, TLPT scoping where applicable, and supervisory communications.
  • ISO 22301-specific records: BCMS scope, continuity policy, continuity objectives, competence and awareness records, documented-information controls, internal audit programme, and management review outputs.
Section 4

How to run the comparison in practice

Start from the service, not the framework name. Identify the business service, ICT assets, data flows, suppliers, outsourced services, continuity dependencies, and recovery expectations. Then mark which facts create a DORA obligation and which facts belong in the ISO 22301 BCMS.

The output should be a comparison record that is usable by ICT risk, business continuity, security operations, procurement, legal, audit, and accountable management. It should show the source, owner, evidence, review trigger, and unresolved gaps for each side.

  • For DORA: map ICT-supported business functions, critical or important functions, ICT third-party services, incident classification, testing coverage, register entries, contract obligations, and management approvals.
  • For ISO 22301: map BCMS scope, interested parties, continuity objectives, BIA outputs, continuity strategies, plans, exercises, audit findings, management review, and improvement actions.
  • For overlap: decide which continuity records can be reused, which need DORA-specific fields, and which cannot be reused because they answer different assurance questions.
Recommended next step

Turn this comparison into a DORA and BCMS evidence map

Sorena can help separate DORA ICT operational resilience duties from ISO 22301 continuity evidence, identify reusable records, and flag gaps that need legal, audit, or operational review.

Primary sources

References and citations

eur-lex.europa.eu
Referenced sections
  • Primary source for DORA's ICT operational resilience obligations.
"digital operational resilience"
Related guides

Explore more topics

DORA Critical or Important Functions: mapping ICT dependencies and evidence
How DORA critical or important functions affect ICT service mapping, third-party contracts, register-of-information records, incidents, testing, and evidence.
DORA deadlines and compliance calendar for financial entities
Calendar the grounded DORA dates and recurring evidence: 17 January 2025 application, incident reporting clocks, register updates, annual reporting, TLPT cadence, and CTPP oversight milestones.
DORA ICT Third-Party Contract Remediation Workflow
A DORA workflow for remediating ICT third-party contracts covering critical or important functions, subcontracting, audit rights, exits, register updates, and evidence.
DORA ICT Third-Party Contracts FAQ
What DORA requires in ICT third-party contracts, including critical or important functions, audit and access rights, termination, exit, subcontracting, register updates, and evidence.
DORA ICT third-party risk and contract clauses guide
Source-grounded DORA guide for financial entities in scope, ICT third-party risk, contract clauses, subcontracting controls, register evidence, audit rights, exit planning, and oversight.
DORA incident classification forms: criteria, fields, and reporting clocks
Grounded guide to DORA ICT incident classification forms: major-incident criteria, significant cyber-threat notifications, report fields, time limits, evidence, and reclassification records.
DORA incident clock workflow: classification, reports, deadlines, and evidence
Grounded DORA workflow for starting the major-incident reporting clock, classifying ICT incidents, submitting initial, intermediate, and final reports, and preserving authority evidence.
DORA major ICT incident reporting: classification, reports, and timing
Source-grounded DORA guide to major ICT-related incident classification, initial notifications, intermediate and final reports, competent authority routing, and significant cyber threat notifications.
DORA major ICT incident thresholds: what triggers reporting?
FAQ on DORA major ICT-related incident classification thresholds, recurring incidents, reporting triggers, and evidence inputs grounded in EU DORA RTS and ITS texts.
DORA Register of Information FAQ: ICT Third-Party Arrangements
FAQ on the DORA register of information: who maintains it, which ICT third-party arrangements it covers, template fields, critical functions, reporting, data quality, and evidence.
DORA Register of Information Import and Build Workflow
Build a DORA register of information from procurement, vendor, contract, service, function, and subcontractor data using the official register templates and validation checks.
DORA Register of Information Template: ICT Provider Fields and Evidence
A grounded DORA register of information template for ICT third-party contracts, provider hierarchy, critical functions, dates, statuses, reporting, and evidence.
DORA TLPT selection: who can be required to test?
FAQ on DORA threat-led penetration testing selection: who identifies financial entities, what criteria are used, what the TLPT authority validates, and what evidence to keep.
DORA vs EBA outsourcing guidelines: ICT third-party risk comparison
Compare binding DORA ICT third-party risk duties with the EBA/ESA outsourcing baseline for registers, critical functions, contracts, subcontracting, exit, incident reporting, and evidence.
DORA vs ISO/IEC 27001: legal ICT resilience obligations and ISMS controls
Compare EU DORA and ISO/IEC 27001 across scope, governance, incident reporting, testing, ICT third-party risk, certification, evidence, overlap, and gaps.
DORA vs NIS2: financial-sector obligations, overlap, and evidence
Compare DORA and NIS2 for financial entities, ICT providers, incident reporting, management accountability, third-party risk, supervisory routes, and reusable evidence.
DORA vs PSD2 incident reporting: major ICT and payment incidents
Compare DORA major ICT-related incident reporting with PSD2 major operational or security payment incident reporting, including scope, triggers, report stages, recipients, and evidence.
EU DORA Applicability Test for Financial Entities and ICT Providers
A source-grounded DORA applicability test for financial-entity scope, ICT third-party services, critical or important functions, exclusions, proportionality, and evidence.
EU DORA Compliance Checklist for Financial Entities
A source-grounded DORA checklist covering ICT risk governance, major incident reporting, resilience testing, TLPT, ICT third-party contracts, register-of-information records, and audit evidence.
EU DORA Compliance Obligations and Evidence Guide
A source-grounded DORA compliance guide covering ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, registers, governance, oversight, and evidence.
EU DORA FAQ: scope, incidents, ICT contracts, testing, and evidence
Concise DORA FAQ covering who is in scope, proportionality, ICT third-party contracts, register-of-information records, major ICT incident thresholds and reporting, TLPT, testing, enforcement, and evidence.
EU DORA ICT risk management control baseline
A source-grounded DORA control baseline for ICT risk governance, asset and dependency mapping, protection, detection, response, recovery, testing, third-party risk, and evidence.
EU DORA ICT subcontracting chain controls for critical functions
DORA guide to ICT subcontracting chains for critical or important functions: prior assessment, contract conditions, register fields, monitoring, exit rights, and evidence.
EU DORA penalties and fines: enforcement powers and limits
Grounded guide to DORA enforcement: competent-authority powers, administrative penalties, remedial measures, publication rules, and Lead Overseer penalty payments for critical ICT third-party providers.
EU DORA Register of Information Data Model: templates, fields, and evidence
Field-level guide to the EU DORA register of information data model: templates B_01 to B_07, provider identifiers, contract links, subcontracting chains, critical-function assessments, dates, and export evidence.
EU DORA Requirements Overview: ICT risk, incidents, testing, and third-party risk
A grounded overview of the main EU DORA requirements for financial entities: governance, ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, register of information, oversight, proportionality, and evidence.
EU DORA Scope and Covered Entities: financial entities and ICT providers
Classify whether DORA applies to a financial entity, ICT third-party provider, group arrangement, branch, or critical ICT service dependency.
EU DORA Scope and Proportionality Workflow
Classify DORA covered entities, simplified-framework status, critical or important functions, ICT dependencies, evidence records, and governance approvals.
EU DORA testing and TLPT readiness guide
A grounded DORA guide for resilience testing, TLPT eligibility, authority interaction, test evidence, remediation plans, and avoiding unsupported testing cadence.
EU DORA TLPT eligibility workflow for financial entities
Check how DORA TLPT authorities identify financial entities for threat-led penetration testing and what evidence supports scope, readiness, providers, and governance.
EU DORA TLPT Runbook: scope, providers, reports, and remediation
Build a DORA threat-led penetration testing runbook around authority coordination, scope validation, provider controls, active testing, closure reports, remediation, and attestation.
How does proportionality work under EU DORA?
A grounded FAQ on DORA proportionality: what can be scaled, who may use the simplified ICT risk framework, what evidence supports the decision, and which duties cannot be waived.
How to build a DORA register of information
Build a DORA register of information from contracts, ICT services, providers, functions, subcontractors, risk assessments, audit evidence, exit plans, and export checks.