DORA: what it really requires of financial firms
DORA has applied since January 2025 and covers far more than banks. The five pillars, mandatory resilience testing and ICT supplier duties.
DORA (the Digital Operational Resilience Act) has applied across the EU since 17 January 2025 — with no transition period and no need for national implementing law, because it is a directly applicable regulation. Eighteen months on, supervisors have finished the “mapping” phase and moved to enforcement: the first requests to complete ICT contract registers and questions about resilience test results have already reached Polish entities. It’s a good moment for a structured answer to the question: what does DORA really mean in practice — including when you’re not a bank but a bank’s supplier.
Who DORA covers
The list is long — more than 20 categories of financial entities, including: banks, investment firms, insurers and insurance intermediaries, payment and e-money institutions, fund managers, crypto-asset service providers, exchanges and clearing houses. The proportionality principle softens the requirements for smaller entities but does not exempt them.
The second group covered by DORA — and often surprised by it — are third-party ICT service providers to the financial sector: the software house maintaining a bank’s system, the SaaS vendor serving an insurer, the hosting company behind a payment institution. DORA reaches them through contracts: the financial institution must impose specific clauses on the provider (audit rights, incident reporting, exit strategies), and the largest critical providers fall under direct European oversight.
The five pillars of DORA in practice
1. ICT risk management. A documented risk management framework: an inventory of systems and critical functions, risk analysis, controls, business continuity and backups with restore testing. Responsibility sits squarely with the management body — the board approves the strategy, reviews it and is required to understand ICT risk (board training is a requirement, not an option).
2. Incident reporting. A unified classification of ICT incidents and hard deadlines for reporting major incidents to the supervisor: an initial notification within 4 hours of classification (and 24 hours of detection), an intermediate report within 72 hours, a final report within a month. These deadlines cannot be met without a ready process — the same one we describe for breach response, just with a stricter clock.
3. Digital operational resilience testing. DORA is the first regulation of this rank to mandate security testing: all entities must run a testing programme (vulnerability scans, security assessments, penetration tests) at least annually for critical systems. Entities designated by the supervisor additionally undergo TLPT (threat-led penetration testing — red-team-style tests under the TIBER-EU framework) every three years, performed by independent, qualified testers.
4. Third-party ICT risk management. A full register of information on all ICT contracts (in a format imposed by technical standards), concentration risk assessment, mandatory contract clauses (audit rights, SLAs, incident reporting, exit plans) and a strategy for the failure of a key provider. This pillar generates the most operational work — and the most supervisory questions. We cover supplier management more broadly in our piece on TPRM.
5. Information sharing. An encouragement (not an obligation) to participate in sector threat-intelligence sharing arrangements.
DORA vs NIS2: how they differ
A common question from firms caught by both. The conflict rule is simple: DORA takes precedence as lex specialis for financial entities — within its scope it replaces the requirements of NIS2. The practical differences: DORA is more prescriptive (specific deadlines, register templates, mandatory testing), applies directly without national law, and puts far more weight on third-party providers. If you’re building compliance with both — start with DORA and you’ll get much of NIS2 along the way.
Where to start: a 90-day plan
- Mapping — a list of critical functions, the systems supporting them and their providers; without this map no pillar works.
- The ICT contract register — an inventory of all ICT provider contracts in the required format; a clause review against DORA requirements (audit, incidents, exit).
- The incident process — classification, materiality thresholds, notification templates for the supervisor, a dry run against the 4/24/72-hour clock.
- The testing programme — a schedule of scans and penetration tests for critical systems; first tests with a report that will stand up to supervisory scrutiny.
- Documentation and the board — a digital resilience strategy approved by the board, board training, roles assigned.
If you’re an ICT supplier to finance
Expect sector clients to start requiring: contractual clauses (audit rights, incident reporting within hours, exit plans and migration support), security evidence (penetration test results, certifications, policies) and participation in their exercises. Companies that have these ready win tenders — because they cut the client’s due diligence from months to days. A regular penetration test with a report prepared for financial-sector clients is now a standard part of the offer for this market.
Frequently asked questions (FAQ)
Does DORA require us to run red team exercises (TLPT)? Only if the supervisor designates you — the criteria are scale, criticality and risk profile; in practice it applies to the largest players. Everyone else has the “ordinary” testing programme obligation, including annual tests of critical systems. Note: the supervisor can extend the TLPT list — build testing maturity before they knock.
We’re a small insurance intermediary. Does DORA apply to us? The smallest intermediaries (microenterprises) are excluded, and proportionality softens requirements for small entities — but it doesn’t remove the basics: risk management, incident handling and provider oversight. Confirm your category with a lawyer; the technical foundations are worth having regardless.
What are the penalties for non-compliance? The supervisor has supervisory measures and administrative sanctions (including financial penalties), but in practice the first cost is operational: requests, recommendations, closing gaps under pressure. The second is commercial — financial institutions filter out non-compliant suppliers at the procurement stage.
How does a “DORA” penetration test differ from a regular one? In scope and documentation: the test must cover systems supporting critical functions, be performed by qualified testers, and the report must work as supervisory evidence (methodology, scope, risks, remediation plan, retest). We run such tests and help build the full annual programme — let’s talk.
Is the public cloud DORA-compliant? By itself — that’s the wrong question. DORA doesn’t ban the cloud; it requires you to understand concentration risk, have the right contract clauses, an exit plan and provider oversight. The largest cloud providers have been brought under direct EU oversight as critical providers, which tidies up part of the problem — but your own obligations remain.
Summary
DORA moves security from the “good practice” category to “legal obligation with deadlines and document templates”. The five pillars — ICT risk, incidents, testing, providers, information sharing — form a coherent programme you should want anyway: the regulation just adds rigour. If you need support on the technical side — from the testing programme, through penetration tests, to building the incident process — get in touch. We help both financial institutions and their ICT suppliers.
This article is not legal advice. Sources: Regulation (EU) 2022/2554 (DORA), KNF and EBA/ESMA/EIOPA communications.
