Learn
ISO 22301 is a voluntary standard for a business continuity management system (BCMS) that an accredited body can certify. DORA, Regulation (EU) 2022/2554, has applied to financial entities since 17 January 2025, and its business continuity duties sit in Articles 11 and 12, detailed by Articles 24 to 26 of Commission Delegated Regulation (EU) 2024/1774. DORA never names ISO 22301 and a certificate does not discharge it, but Article 11(1) makes the ICT business continuity policy part of an overall business continuity policy, which is exactly what a BCMS supplies. A working BCMS already produces much of what Article 11 asks for: a business impact analysis, plans for critical activities, a crisis structure and a record of what happened. DORA then adds a firmer layer on top: ICT response and recovery plans under independent internal audit, tests at least yearly with cyber-attack and switchover scenarios, recovery time and recovery point objectives for each function, restoration onto segregated systems, and a list of scenarios the plans must cover.
This guide is for the operational resilience lead, business continuity manager or CISO at a bank, insurer, payment or e-money institution, investment firm or crypto-asset service provider who runs, or plans, an ISO 22301 BCMS and has to show a supervisor that DORA's continuity duties are met. It sets the two side by side from the Official Journal texts, shows article by article which DORA duties the BCMS file already answers and what to add, separates the three kinds of testing that get confused, and ends with an evidence table you can fill in. For DORA as a whole, start with DORA requirements explained; for the standard, clause by clause, read our guide to the ISO 22301 requirements.
| ISO 22301:2019 | DORA | |
|---|---|---|
| What it is | An international standard for a business continuity management system | An EU regulation, directly applicable in every Member State |
| Who it applies to | Any organisation that adopts it | Twenty types of financial entity in Article 2(1)(a) to (t), and ICT third-party service providers in (u) |
| Scope | Set by the organisation, clause 4.3 | The entity's ICT risk, with continuity in Articles 11 and 12 |
| Who checks | An accredited certification body, by audit | The competent authority, by supervision |
| Testing cadence | Planned intervals and on significant change | At least yearly, and after substantive ICT change, Article 11(6) |
| Recovery objectives | Time frames from the business impact analysis | Recovery time and recovery point objectives for each function, Article 12(6) |
| Outcome | A certificate valid for three years, with yearly surveillance | No certificate; compliance is supervised |
| Mentions the other | No | No |
Does DORA require ISO 22301 certification?
No. We searched the Official Journal texts of DORA, its ICT risk management RTS (Delegated Regulation (EU) 2024/1774), NIS2 and the NIS2 Implementing Regulation (EU) 2024/2690, and none of them names ISO 22301. DORA mentions international standards only in general terms, for example the G7 fundamental elements for threat-led penetration testing. What DORA does is assume a continuity capability it does not itself build. Article 11(1) requires financial entities to put in place "a comprehensive ICT business continuity policy, which may be adopted as a dedicated specific policy, forming an integral part of the overall business continuity policy of the financial entity". An entity without an overall policy has nothing for the ICT policy to form part of.
So the question a supervisor asks is whether the DORA artefacts exist and work, whatever certificate hangs on the wall. A certified BCMS is strong evidence that the overall policy, the business impact analysis and the exercise discipline exist. It does not show that the ICT-specific duties below are met, because the standard does not ask for them. The management body's role is also written into DORA: Article 5(2)(e) makes it approve and periodically review the ICT business continuity policy and the ICT response and recovery plans.
Which DORA continuity duties does a BCMS already answer?
Article by article, this is how the DORA continuity text lines up against the ISO 22301 clauses, and what an ISO 22301 BCMS file still needs before it answers each provision. This is our reading of the texts; take legal advice before relying on it for a specific entity.
| DORA provision | What it requires | ISO 22301 clause | What to add for DORA |
|---|---|---|---|
| Article 11(1) | An ICT business continuity policy forming part of the overall business continuity policy | 5.2, the overall policy | The ICT policy content in RTS Article 24(1): objectives that reflect the BIA results, scope and exclusions, timeframe, activation and deactivation criteria, governance, and alignment with the overall plans on scenarios and recovery objectives |
| Article 11(2) | Arrangements and plans to keep critical or important functions running, respond to ICT incidents, contain damage, estimate impacts and communicate | 8.4.1 to 8.4.4 | Containment plans for each type of ICT-related incident, and the estimation of impacts, damages and losses |
| Article 11(3) | ICT response and recovery plans, subject to independent internal audit review except in microenterprises | 8.4.4, 8.4.5 and 9.2 | Plans with the content of RTS Article 26, named in the internal audit scope |
| Article 11(4) | ICT business continuity plans maintained and periodically tested, notably for functions outsourced to ICT third-party service providers | 8.1, 8.4.4 and 8.5 | Supplier scenarios in the tests, RTS Article 25(2)(b) |
| Article 11(5) | A BIA of exposure to severe business disruptions, with quantitative and qualitative criteria, internal and external data and scenario analysis; ICT designed in line with it, with redundancy of critical components | 8.2.2 and 8.3 | Severe-disruption scenarios, and a reconciliation with the critical or important functions |
| Article 11(6) | Tests at least yearly and after substantive ICT change; crisis communication plans tested; cyber-attack and switchover scenarios except in microenterprises; plans reviewed in the light of tests and audits | 8.5 and 8.6 | A fixed yearly cadence covering ICT systems supporting all functions, and the mandatory scenarios |
| Article 11(7) | A crisis management function with clear internal and external communication procedures, except in microenterprises | 8.4.2 and 8.4.3 | A link to the Article 14 communication policies |
| Article 11(8) | Readily accessible records of activities before and during disruptions | 8.4.3 | Little: the standard already asks you to record details, actions and decisions |
| Article 11(9) and (10) | Test results sent to the authority by central securities depositories; estimates of annual costs and losses from major ICT-related incidents on request | None | DORA-specific reporting |
| Article 12(1) and (2) | Backup policies with scope and minimum frequency set by criticality; restoration and recovery procedures; periodic testing | 8.3 and 8.4.5 | Backup frequency tied to data criticality, and documented restore tests |
| Article 12(3) | Restoration onto ICT systems physically and logically segregated from the source | 8.3 | A segregated restore environment |
| Article 12(4) and (5) | Redundant ICT capacity, which microenterprises assess against their risk profile; a secondary processing site for central securities depositories | 8.3 | Evidence that the capacity is adequate to business needs |
| Article 12(6) | Recovery time and recovery point objectives for each function, reflecting criticality and impact on market efficiency, meeting agreed service levels in extreme scenarios | 8.2.2 | An RPO for each function, and market efficiency in the impact criteria |
| Article 12(7) | Integrity checks and reconciliations when recovering, including data reconstructed from external stakeholders | 8.4.5 | Reconciliation steps written into the recovery procedure |
| Article 14 | Crisis communication plans for responsible disclosure of major ICT-related incidents or vulnerabilities; communication policies; at least one person for the public and media function | 8.4.3 and 7.4 | Disclosure of vulnerabilities as well as incidents, and the named media role |
What do Articles 24 to 26 of the RTS add?
Commission Delegated Regulation (EU) 2024/1774, adopted on 13 March 2024 and published on 25 June 2024, fills in the detail Article 15 of DORA asked for. Three of its articles do the continuity work.
Article 24, the policy. The ICT business continuity policy has to describe its objectives (including how ICT continuity relates to overall business continuity, in the light of the BIA), its scope with limitations and exclusions, the timeframe it covers, and the criteria for activating and deactivating the ICT continuity plans, the response and recovery plans and the crisis communication plans. It has to set governance and escalation, align the ICT plans with the overall business continuity plans on failure scenarios and on recovery time and recovery point objectives, and provide for testing, review and effectiveness checks. For three kinds of entity it fixes the recovery time.
Article 25, testing. Tests of the ICT continuity plans have to take the BIA and the ICT risk assessment into account; use an adequate set of severe but plausible scenarios, always including the scenarios the plans were built on; test the services of ICT third-party providers where applicable, with scenarios for their insolvency or failure and for political risk in their jurisdiction; include switchover from the primary ICT infrastructure to redundant capacity for entities other than microenterprises; and challenge the assumptions the plans rest on, governance and crisis communication included. Results are documented, and deficiencies are analysed, addressed and reported to the management body.
Article 26, response and recovery plans. They take the BIA results into account, state the conditions for activation and deactivation, describe the actions that keep ICT systems supporting critical or important functions available and recoverable, are designed to meet the recovery objectives, provide short-term and long-term recovery options including partial recovery, and define what successful execution looks like. They must consider nine scenarios, which map onto the disruption risk assessment of ISO 22301 clause 8.2.3:
| RTS Article 26(2) scenario | Where an ISO 22301 BCMS covers it |
|---|---|
| (a) Cyber-attacks, and switchovers between primary infrastructure and redundant capacity | Risk assessment 8.2.3; technical recovery tests under 8.5 |
| (b) A critical or important function deteriorating or failing, including the insolvency or failure of an ICT third-party provider | Supplier dependencies in 8.2.2 and 8.1; supplier scenarios |
| (c) Partial or total failure of premises, including offices and data centres | Site loss scenarios and alternative workplaces under 8.3 |
| (d) Substantial failure of ICT assets or communication infrastructure | ICT recovery solutions under 8.3 |
| (e) A critical number of staff unavailable | People as a resource type under 8.3; deputies under 8.4.2 |
| (f) Climate change and environmental degradation, natural disasters, pandemics, physical attacks | Context under 4.1, including the climate question added by Amendment 1:2024 |
| (g) Insider attacks | Risk assessment 8.2.3 |
| (h) Political and social instability, including in a provider's jurisdiction and where data is stored and processed | Context under 4.1; supplier location in 8.1 |
| (i) Widespread power outages | Utilities as a resource under 8.3 |
How is DORA testing different from ISO 22301 exercising?
Three kinds of testing meet here, and two of them can share one programme. Clause 8.5 of ISO 22301 asks for an exercise programme that validates strategies, solutions and teams over time. DORA Article 11(6) asks for the ICT continuity plans and the ICT response and recovery plans to be tested at least yearly and after substantive changes, with the RTS Article 25 requirements on top. A well-designed scenario test of the continuity plans can serve both at once, provided it meets the RTS: severe but plausible scenarios, third-party services, switchover where required, a challenge to assumptions, documented results and deficiencies reported to the management body.
The third kind is separate. DORA Articles 24 to 27 set a digital operational resilience testing programme that looks for security weaknesses: vulnerability assessments, scenario-based tests, penetration tests and, for entities identified by their authority, threat-led penetration testing at least every three years. Article 24(6) requires entities other than microenterprises to test all ICT systems and applications supporting critical or important functions at least yearly. Our guide to the DORA operational resilience testing programme covers that side.
How do the BIA and DORA's critical or important functions fit together?
DORA Article 3(22) defines a critical or important function as one whose disruption would materially impair the entity's financial performance, the soundness or continuity of its services and activities, or its continuing compliance with the conditions of its authorisation or its other obligations under financial services law. Article 8(1) requires entities to identify, classify and document their ICT supported business functions and the assets behind them, and to review that classification at least yearly. The register of information then flags which ICT services support critical or important functions.
The ISO 22301 business impact analysis and that classification must agree. If the BIA prioritises an activity that the register does not treat as supporting a critical or important function, or the other way round, a supervisor will ask which one is wrong. Reconcile them on the same yearly cycle. Our ISO 22301 business impact analysis worked example shows how to derive the recovery objectives, and our guide to the DORA register of information covers the classification side.
What changes for smaller entities?
Microenterprises are spared several continuity duties: the independent internal audit of the response and recovery plans in Article 11(3), the cyber-attack and switchover scenarios in Article 11(6), the crisis management function in Article 11(7), and redundant ICT capacity, which under Article 12(4) they assess against their risk profile instead. They still need the policy, the plans, the BIA and the yearly tests.
The entities in Article 16(1) (small and non-interconnected investment firms, exempted payment and electronic money institutions, and small institutions for occupational retirement provision, among others) are outside Articles 5 to 15 and follow the simplified framework of Article 16. They must still ensure the continuity of critical or important functions through business continuity plans and response and recovery measures that include backup and restoration, and test them regularly. RTS Article 39 lists what those plans contain, and Article 40 requires them to be tested at least once every year for the backup and restore procedures, or upon every major change of the plan. Our guide to DORA for payment institutions explains who falls where.
Where does a BCMS stop short of DORA altogether?
Several DORA duties have no ISO 22301 counterpart at all, and a BCMS should not be stretched to pretend otherwise: the ICT risk management framework of Article 6, the classification and reporting of major ICT-related incidents under Articles 17 to 19, the register of information and the contractual provisions of Articles 28 to 30, the resilience testing programme of Articles 24 to 27, and information sharing under Article 45. The reporting clock is the one continuity teams most need to know: under Article 5 of Delegated Regulation (EU) 2025/301 the initial notification is due within 4 hours of classifying an incident as major and no later than 24 hours after becoming aware of it. Our guide to incident reporting deadlines by regulation sets it beside the other clocks a disruption can start, and ISO 27001 vs DORA covers the information security side of the same question.
What do the other results get wrong?
We read the five comparisons ranking for "ISO 22301 and DORA" that we could open in October 2026. All five are under 2,000 words, they cite almost no articles, and they repeat a few errors.
That DORA names the standard. One page says ISO 22301 is referenced equally by DORA, NIS2 and ISO audits. Neither law, nor the DORA RTS on ICT risk management, nor the NIS2 Implementing Regulation names it. The NIS2 texts name ISO/IEC standards for information security, cloud definitions and vulnerability handling, and none for business continuity.
That certification covers most of DORA without effort. The same page says certified organisations already satisfy large portions of DORA and NIS2 without additional effort. The table above shows why that overstates it: the yearly cadence, the mandatory scenarios, the independent audit of the response and recovery plans, recovery objectives for each function and segregated restoration all need work a certificate does not evidence.
The incident clock. Another comparison gives DORA's reporting as a 4 hour initial and a 72 hour intermediate notification. The initial notification is due within 4 hours of classification and no later than 24 hours from awareness, and the 72 hours for the intermediate report run from the initial notification.
Testing collapsed into one programme. Two comparisons published in August 2026 describe DORA testing only as the risk-based resilience testing programme and threat-led penetration testing. Neither mentions Article 11(6), the separate duty to test the continuity plans themselves at least yearly. Merging the two is how continuity tests end up scoped as penetration tests, or missed altogether.
An outdated control number. A third page says ISO 27001 control A.17 and ISO 22301 provide a foundation for DORA's resilience testing mandates. A.17 is the continuity section of the 2013 edition of ISO 27001; the 2022 edition puts continuity in A.5.29, A.5.30 and A.8.14. And the DORA duty a BCMS exercise programme maps onto is Article 11(6), while the testing of Articles 24 to 27 looks for security weaknesses.
No article numbers. None of the comparisons cites Article 12(6) or Articles 24 to 26 of the RTS, so none tells a reader where DORA sets recovery objectives or which entities face a two hour ceiling.
Fill-in: your DORA continuity evidence
For each DORA duty, write down the BCMS record that already answers it, the gap that remains and who owns closing it.
| DORA duty | Evidence from your BCMS | Gap to close | Owner |
|---|---|---|---|
| Article 11(1) ICT business continuity policy, with RTS Article 24 content | |||
| Article 11(3) ICT response and recovery plans, independently audited | |||
| Article 11(5) BIA of severe business disruptions | |||
| Article 11(6) yearly tests, cyber-attack and switchover scenarios | |||
| Article 11(7) crisis management function | |||
| Article 12(1) and (2) backup policy and restore tests | |||
| Article 12(3) restoration onto segregated systems | |||
| Article 12(6) RTO and RPO for each function | |||
| Article 14 crisis communication plans and the media role | |||
| RTS Article 26(2) nine scenarios considered |
How does Venvera run ISO 22301 and DORA together?
Venvera keeps both in one place: every requirement, owner, task, deadline and piece of evidence in one dashboard instead of Outlook, Excel and mail chains. The ISO 22301 module carries 45 requirements, a 43-question gap assessment, 14 recurring obligations and 10 policy templates, and it sits beside the DORA module with its own requirements, gap assessment, register of information and resilience testing pages. On the crosswalk, the ISO 22301 business continuity plans requirement (clause 8.4.4) sits in the business continuity group with DORA, NIS2, ISO 27001 and the other frameworks that ask for continuity plans, so a plan and its approval, attached once, count for each of them. Venvera tracks the obligations and the evidence; it does not run your exercises or recovery tests, or certify the BCMS.
Start with a free compliance check, book a demo to see both frameworks in one workspace, or start a 14-day Professional trial with no credit card. The Professional plan covers five frameworks for EUR 899 per month; see pricing.
Frequently asked questions
Does DORA require ISO 22301 certification?
No. DORA does not name ISO 22301 or any other continuity standard, and it creates no certificate of its own. It requires the continuity outcomes in Articles 11 and 12, which a BCMS helps you produce.
Does an ISO 22301 certificate satisfy DORA Article 11?
Partly. It evidences the overall policy, the BIA and the exercise discipline. You still need the ICT-specific content in RTS Articles 24 to 26, the yearly tests with their scenarios, the independent audit of the response and recovery plans and the per-function recovery objectives.
Is the DORA business impact analysis the same as the ISO 22301 one?
It is the same exercise with sharper edges. Article 11(5) asks for severe business disruptions, quantitative and qualitative criteria, scenario analysis and attention to third-party dependencies and information assets. An ISO 22301 BIA extended in those directions serves both.
How often must DORA continuity plans be tested?
At least yearly, and after substantive changes to ICT systems supporting critical or important functions, under Article 11(6). Entities on the simplified framework test their backup and restore procedures at least once a year, or on every major change of the plan, under RTS Article 40.
Does DORA require a recovery point objective?
Yes. Article 12(6) requires recovery time and recovery point objectives for each function, reflecting whether it is critical or important and its potential impact on market efficiency.
Does DORA set maximum recovery times?
Only for three kinds of entity. RTS Article 24 sets 2 hours for the critical functions of central counterparties and for the critical or important functions of central securities depositories, and requires trading venues to resume trading within or close to 2 hours. Everyone else sets their own.
Can one exercise count for ISO 22301 and DORA?
Yes, if it meets RTS Article 25: severe but plausible scenarios, third-party services where applicable, switchover where required, a challenge to the plan's assumptions, documented results and deficiencies reported to the management body. Penetration tests and TLPT remain a separate programme.
Do microenterprises need a crisis management function?
No. Article 11(7) applies to financial entities other than microenterprises. Microenterprises still need the continuity policy, plans, BIA and yearly tests.
Is ISO 27001 enough for DORA continuity?
No. Its continuity controls, A.5.29 and A.5.30, assume recovery objectives exist without asking for the BIA that produces them. Our ISO 27001 vs DORA comparison covers the information security articles.
Do ICT third-party providers have to take part in continuity tests?
RTS Article 25(2)(b) requires testing of the ICT services they provide, where applicable, and central counterparties and central securities depositories must involve their providers directly. Contracts should give you that right.
Primary sources
The DORA provisions are from Regulation (EU) 2022/2554, the RTS provisions from Commission Delegated Regulation (EU) 2024/1774 and the reporting clock from Commission Delegated Regulation (EU) 2025/301. The searches for references to ISO 22301 covered those texts, Directive (EU) 2022/2555 and Commission Implementing Regulation (EU) 2024/2690, all as published in the Official Journal. ISO 22301 facts are from ISO's catalogue entries for ISO 22301:2019 and its 2024 amendment. The mapping of DORA provisions to ISO 22301 clauses is our reading of the texts and is offered as guidance for planning.
