OnwynOnwyn › Standards › DORA — Digital Operational Resilience Act (Regulation (EU) 2022/2554)
Regulation · 2022/2554DORA — Digital Operational Resilience Act (Regulation (EU) 2022/2554)
DORA is the EU's operational resilience law for the financial sector. It has applied since 17 January 2025 to banks, insurers, payment and e-money institutions, investment firms, crypto-asset service providers, fund managers, and around a dozen further categories of financial entity — and it reaches their ICT suppliers indirectly, because every contract for an ICT service must now carry a defined set of clauses and the financial entity must be able to audit, exit, and report on it. Most companies encounter DORA in that second way: not as a regulated entity, but as the software or hosting provider whose financial customer arrives with a contract addendum, a due-diligence questionnaire, and an audit right. This pack covers the five pillars — ICT risk management, incident management and reporting, resilience testing, ICT third-party risk, and information sharing — from the financial entity's side, plus a dedicated section for suppliers being pulled in by contract. A separate oversight regime applies to a small number of ICT providers designated as critical by the European Supervisory Authorities; almost no mid-sized vendor is one.
What this standard asks for
Every requirement in DORA — Digital Operational Resilience Act (Regulation (EU) 2022/2554), grouped the way the standard groups them. In the Compliance Engine each one carries what to do, how to evidence it, what auditors commonly reject, and a button to bring in a consultant if you would rather not work it out alone.
Scope, proportionality & dates
4 requirements
- Art. 2Establish whether DORA binds you directly or through a contract
- Art. 64Application date and readiness plan
- Art. 4Apply proportionality deliberately and document it
- Art. 16Simplified ICT risk management framework, where you qualify
Governance & ICT risk framework
7 requirements
- Art. 5(2)Management body owns ICT risk and approves the framework
- Art. 5(4)Management body knowledge and regular training
- Art. 6(1)-(3)A documented ICT risk management framework
- Art. 6(4)Independent responsibility for ICT risk, segregated from delivery and audit
- Art. 6(5)Review the framework annually and after major incidents
- Art. 6(6)-(7)Internal audit of the framework and follow-up on findings
- Art. 6(8)Digital operational resilience strategy
Protect, detect, respond & recover
10 requirements
- Art. 8Identify functions, assets and dependencies — and keep the inventory current
- Art. 7 / Art. 8(7)Systems fit for purpose, and a hard look at legacy
- Art. 9(2)-(4)(b)Information security policy and network protection
- Art. 9(4)(c)-(d)Access control, strong authentication and key protection
- Art. 9(4)(e)-(f)Change management, patching and updates
- Art. 10Detection mechanisms with defined alert thresholds
- Art. 11ICT business continuity policy, impact analysis and tested plans
- Art. 12Backups, restoration and redundant capacity
- Art. 13Learning and evolving: post-incident reviews, reporting and training
- Art. 14Crisis communication plans and a named spokesperson
Incident management & reporting
4 requirements
- Art. 17ICT-related incident management process
- Art. 18Classify incidents against the statutory impact criteria
- Art. 19(4)Initial, intermediate and final reports to the competent authority
- Art. 19(2)-(3)Informing clients, and voluntary notification of cyber threats
Digital operational resilience testing
3 requirements
- Art. 24A digital operational resilience testing programme
- Art. 25The range of tests to apply
- Art. 26-27Threat-led penetration testing, if you are identified for it
ICT third-party risk & contracts
6 requirements
- Art. 28(1)-(2)A strategy and policy for ICT third-party risk
- Art. 28(3)Register of information on all ICT contracts
- Art. 28(4) / Art. 29Pre-contract due diligence and concentration risk
- Art. 30(2)Mandatory clauses in every ICT service contract
- Art. 30(3)Additional clauses where a critical or important function is supported
- Art. 28(8)Exit strategies and tested transition plans
If you are the ICT service provider
6 requirements
- Supplier: Art. 30(1)-(2)Be contract-ready before your financial customer asks
- Supplier: Art. 30(2)(a)-(b)Subcontracting and data location transparency
- Supplier: Art. 30(2)(f)-(g)Incident assistance and cooperation with authorities
- Supplier: Art. 30(3)(e)Be ready for audits, inspections and access rights
- Supplier: Art. 28(8) / Art. 30(3)(f)Support exit and transition credibly
- Supplier: Art. 31Understand the critical ICT third-party provider regime — and whether it could reach you
Information sharing
1 requirement
- Art. 45Information-sharing arrangements
The documents you will end up with
The recommended document set for DORA — Digital Operational Resilience Act (Regulation (EU) 2022/2554) — 25 in total. The engine tracks which you have, which are missing, and which of your existing documents already cover a requirement.
The single document describing how you manage technology risk end to end, who owns it, and how independent that owner is from the people delivering the systems.
How the framework will actually be delivered: your risk tolerance, the targets you set, and the investment behind them.
Records whether DORA binds you directly or through a customer's contract, which regime you fall under, and why the measures you chose are proportionate to your size and risk.
The dated plan from where you are now to where the regulation expects you to be, with owners against each gap.
What the board and senior management are taught about ICT risk, how often, and how attendance is evidenced.
How the framework itself gets audited independently and how findings are tracked to closure.
What systems support which business functions, what depends on what, and which of it is legacy you are carrying knowingly.
The top-level security rules covering the systems that support your critical functions, including network protection.
Who gets access to what, how strong the authentication has to be, and how cryptographic keys are protected.
How changes and updates reach production safely, and how quickly security patches have to be applied.
What you monitor, the thresholds that raise an alert, and who is on the other end of it.
What the business must be able to keep doing, the impact analysis behind that, and the tested plans that deliver it.
What is backed up and how often, how restores are proven, and what redundant capacity exists.
Who says what to clients, staff, the press and the regulator during a serious incident, and who is the named spokesperson.
How incidents are logged, classified against the statutory impact criteria, escalated and learned from.
The clocks and templates for the initial, intermediate and final reports to your authority, and for telling affected clients.
The annual plan of what gets tested, by which method, by whom, and how the findings get fixed.
The scope, threat intelligence and rules of engagement for advanced red-team testing, and how the provider is qualified.
Your rules for using ICT providers: what may be outsourced, what approval it needs, and how concentration is watched.
The regulator-format list of every ICT service contract you hold, with the fields and identifiers the authority asks for — including which contracts support a critical or important function.
The checks you run on an ICT provider before signing, including whether you are becoming too dependent on one of them.
The standard clauses that must appear in every ICT contract, plus the heavier set for providers supporting a critical or important function.
How you would leave each significant ICT provider without stopping the business, and evidence the plan has been tested.
If you sell ICT services to financial entities: the pre-agreed answers and terms on subcontracting, data location, incident assistance, audit rights and exit, so a customer's DORA review does not stall your deal.
The terms under which you swap threat intelligence with peers, and what may not leave the building.
Work that counts twice
DORA — Digital Operational Resilience Act (Regulation (EU) 2022/2554) overlaps with 3 other frameworks in the engine. When you start one of these, the requirements you have already settled here are carried across as suggestions for you to confirm — you review them, we never mark them done on your behalf.
Start DORA today
Every live framework is included in one subscription — no per-framework pricing. Your first 30 days are free, we ask for no card, and there is nothing to cancel. On any requirement you can bring in a senior consultant for a review, a call, or done-for-you implementation.