wiki / banks & neobanks / DORA: What Operational Resilience Costs an EU Licence Holder

DORA: What Operational Resilience Costs an EU Licence Holder

What DORA is and who falls under it

DORA — Regulation (EU) 2022/2554 on digital operational resilience for the financial sector — has applied since 17 January 2025, directly in every EU member state and with no national transposition. It did not arrive alone, and the companion piece is easy to miss: Directive (EU) 2022/2556 strips the scattered ICT provisions out of eight sectoral directives — UCITS, Solvency II, AIFMD, CRD IV, BRRD, MiFID II, PSD2 and IORP II. Without it a payment institution would still carry its own incident rule in PSD2 and a fund manager its own in AIFMD, and the "single framework" would have fractured into eight mismatched ones. The directive entered into force on 16 January 2023, with transposition timed to the regulation's application date.

The perimeter spans some twenty categories: credit institutions, payment institutions and EMIs, account information service providers, MiCA-licensed CASPs, investment firms, fund managers — including third-party ManCos — insurers and intermediaries, credit rating agencies, trading venues, central securities depositories, benchmark administrators and crowdfunding platforms. The rule of thumb: if you hold an EU financial licence, you are almost certainly inside. One consequence matters when comparing venues on the licence map: DORA does not vary by member state — a Lithuanian EMI and a Luxembourg one read the same text.

Proportionality is written into the regulation rather than negotiated with the supervisor. A microenterprise — fewer than 10 staff and annual turnover or balance sheet up to €2 million — runs the simplified ICT risk management framework under Article 16 and does no threat-led penetration testing. Some entities sit outside the regulation entirely: insurance intermediaries that are microenterprises, occupational pension institutions with very few members, and a handful of small categories. But reading that as "we are small, this does not apply" is expensive: everyone inside the perimeter files the register of information and reports incidents, simplified regime included.

The underlying demand is single. A holder of an EU financial licence must demonstrably survive IT failures, attacks and cloud outages — and tell the supervisor about them on time. In the budget of a licensed business, DORA is the second-largest permanent compliance line after AML: it never ends, it grows with every new IT dependency, and it is tested at the licensing gate.

The five pillars: what is actually required

The regulation splits into five blocks of duties. Four are mandatory, the fifth voluntary. The detail most often missed: the ICT risk management framework is approved by the management body, which carries personal accountability for it under Article 5. "We delegated it to IT" does not survive contact with a supervisor who asks for the board minute, not the Jira ticket.

PillarWhat must physically existFrequencyDORA articles
ICT risk managementBoard-approved framework; inventory of IT assets and dependencies; map of critical or important functions; continuity policies and recovery plans; independent review of the frameworkReviewed at least annually and after every major incidentArts 5–16
Incident reportingClassification procedure against uniform thresholds; initial, intermediate and final report templates; a channel to the national supervisor; a log of all incidents, including non-major onesPer event, plus annual aggregate reportingArts 17–23
Resilience testingA testing programme: vulnerability scanning, scenario tests, continuity and recovery tests; for designated entities, TLPT using accredited testersBaseline programme annually; TLPT at least every three yearsArts 24–27
Third-party riskRegister of information covering every ICT contract; Article 30 contractual terms; pre-signing due diligence; concentration assessment; documented exit strategiesRegister filed annually; strategy and assessment reviewed annuallyArts 28–30
Information sharingAn arrangement for exchanging threat indicators within a trusted community; notification to the supervisor of participationVoluntaryArt 45

The dividing line that governs everything else is whether a service supports a "critical or important function". That single classification decides whether you need the enhanced contractual terms, audit rights and an exit plan. You make the call yourself and in writing — supervisors test the reasoning, not the label.

Incident reporting: thresholds and windows

An incident becomes major against the Article 18 criteria: the number and relevance of clients and financial counterparties affected, duration and service downtime, geographical spread, data losses across availability, authenticity, integrity and confidentiality, criticality of the services affected, and economic impact. Materiality thresholds are set by Delegated Regulation 2024/1772, adopted on 13 March 2024 and in force since 15 July 2024. The content and timing of the reports themselves come from RTS 2025/301.

ReportDeadlineClock starts at
Initial notification4 hours from classification of the incident as major, and no later than 24 hours from detectiondetection and classification
Intermediate report72 hoursinitial notification
Updated intermediate reportwithout delay on a material change of status or on return to normal operationsper event
Final reportno later than 1 monththe latest intermediate report
Significant cyber threat notificationvoluntary, no fixed window

Those 24 hours are calendar hours, weekends and public holidays included. Hence a requirement the text never states outright: an on-call rota and pre-drafted templates. An institution that starts working out who is authorised to sign a regulatory notification during the incident has already missed the window.

One piece of good news: the duplication really was removed. On 17 January 2025 the EBA repealed its guidelines on major incident reporting under PSD2, so payment institutions, EMIs, banks and AISPs now report once, under DORA, instead of twice. The remaining exception is narrow — PSPs outside DORA's perimeter, such as post-office giro institutions and credit unions.

The register of ICT contracts: annual filing and data quality

The register of information is DORA's most underestimated obligation. It is not a supplier list but a structured set of linked tables built to ESA templates, carrying an LEI for every provider, function codes, a criticality flag, data processing locations and the subcontracting chain.

The dress rehearsal showed how hard that is. In the ESAs' dry run, published on 17 December 2024, nearly 1,000 EU financial entities submitted registers. Just 6.5% passed all 116 data quality checks — meaning 93.5% contained at least one error. Half of the rest failed fewer than five checks, but the spread explains why the ESAs called the 2025 target "within reach" rather than met.

Then came the live cycles. The first EU-wide collection ran in spring 2025: in Luxembourg the CSSF window ran from 1 to 15 April, after which national regulators passed the data to the ESAs by 30 April. The second cycle ran from 11 February to 31 March 2026 against a 31 December 2025 cut-off. The checks themselves did not change, but they were applied to more fields: files accepted in 2025 were rejected in 2026. Third-country branches were added to scope.

This is not paperwork for its own sake. The register is the dataset from which the ESAs designate critical providers, and the lens through which supervisors see who is concentrated on a single cloud. Errors are the first trigger for questions, and discrepancies between two institutions describing the same provider are reconciled automatically.

Article 30, subcontracting and exit plans: the contracts you must rewrite

This is the most expensive section of the regulation, because it demands re-papered contracts rather than a new policy. Article 30 sets two tiers.

Every ICT contract must contain: a clear and complete description of all functions and services, stating whether subcontracting is permitted and on what conditions; the locations where services are provided and data is processed and stored, with advance notice of any change; provisions on availability, authenticity, integrity and confidentiality of data; guarantees of access to, recovery of and return of data on provider insolvency, resolution or termination; service level descriptions and their updates; assistance during ICT incidents at no additional cost or at a price fixed ex ante; a duty to cooperate fully with competent and resolution authorities; termination rights and notice periods; and participation of the provider's staff in digital resilience awareness and training programmes.

Contracts supporting a critical or important function add: full service level descriptions with precise quantitative and qualitative performance targets; notification of any development liable to materially affect the service; an obligation to implement and test business contingency plans; participation in the financial entity's TLPT; unrestricted rights of access, inspection and audit for the entity, an appointed third party and the competent authority; and exit strategies with a mandatory transition period during which the provider keeps delivering while the function is migrated.

The exit plan is where formal compliance breaks at the first inspection. A credible one does not read "we will move clouds in a fortnight". It has four parts: a degradation scenario setting out precisely what stops working and what keeps running; data extraction in a usable format, with the export actually tested; an identified alternative provider or in-house fallback; and evidence that the transition would neither breach regulatory requirements nor interrupt client service. The plan is meant to be tested, not filed.

Subcontracting deserves its own note. Delegated Regulation 2025/532 was published in the Official Journal on 2 July 2025 and entered into force on 22 July. Its path was bumpy: the ESAs submitted a draft in summer 2024, and on 21 January 2025 — four days after DORA began to apply — the Commission rejected it. The reason was Article 5 of the draft, which imposed monitoring duties across the entire subcontracting chain; in the Commission's view this went beyond the mandate the ESAs were given by Article 30(5) DORA and was not specifically linked to the conditions for subcontracting. The adopted text omits it. The practical effect: the duty to assess and monitor the chain beneath a critical function is still there — it sits in the regulation itself — but the granular monitoring methodology is not in the RTS, and supervisors will read it through the general provisions of Articles 28 to 30. For the layered structures of embedded finance, and for anyone operating under someone else's licence, this means seeing not just your vendor but whoever your vendor stands on.

Critical ICT providers: the cloud under direct EU oversight

On 18 November 2025 the ESAs designated the first 19 critical ICT third-party providers (CTPPs) — the named ones include AWS, Microsoft, Google Cloud, Oracle, SAP and Deutsche Telekom. The list covers hyperscalers, data centre operators, infrastructure and network providers and specialist financial technology platforms, and it is refreshed annually.

The oversight machinery works like this. Each designated provider is assigned a Lead Overseer — one of the three ESAs — plus a joint examination team drawn from ESA and national staff. The team runs annual risk assessments, issues information requests, conducts inspections including at the provider's own premises, and publishes recommendations. The provider must nominate an EU legal entity as its coordination point. Providers fund the regime themselves: fees are calculated on turnover under Delegated Regulation 2024/1505. Ignoring a Lead Overseer's recommendations can attract periodic penalty payments of up to 1% of the provider's average daily worldwide turnover under Article 35.

For a licence holder, designation removes nothing. The exit strategy, the concentration assessment and the contractual rights remain your duty: responsibility is not outsourced along with the server, and ESA supervision of AWS is not a substitute for your own supervision of AWS. What has changed is bargaining power. DORA addenda at the hyperscalers are now standard paper rather than the product of a six-month negotiation, which means a small institution can obtain terms once reserved for large banks simply by citing the regulation.

Enforcement and what it costs

As of August 2026 there are no publicly known fines issued specifically "for DORA". Sanctions are left to national law under Articles 50 to 52, there is no EU-wide ceiling, several member states allow criminal liability, and regimes differ widely. But coercion is already operating at the entrance. ESMA's peer review of Malta in July 2025 found the MFSA had granted CASP licences without adequately assessing ICT risks, and the conclusions went to every EU regulator. Since then the ICT section of an application has been a genuine filter: a weak DORA block stops a file as reliably as weak AML. How an application is assembled is covered in the guide to the MiCA CASP licence.

The second lever is data. Registers are cross-checked across the EU automatically, and discrepancies become supervisory orders. The price of non-compliance today is not a fine but months of delay to an authorisation, a passporting notification or a transaction. The same now applies to opening and keeping accounts: counterparties and correspondents increasingly ask for DORA documentation, and banking for a licensed operator has become a conversation about ICT resilience as much as about AML.

What it costs is a question with no honest public answer. The regulation sets no benchmarks, no official cost methodology has been published, and consultants' estimates differ by an order of magnitude and usually arrive attached to a proposal. The useful exercise is not "what does DORA cost" but which permanent lines it creates, each traceable to an article: a dedicated third-party control function and register maintenance (Art 28), the testing programme (Arts 24–25), TLPT every three years for designated entities (Art 26), independent review of the ICT risk framework (Art 6), and training for staff and the board (Art 13). The most underestimated line is not the testing but the standing vendor-control function — it never ends and grows with every new supplier.

One common misconception is worth clearing. The oversight fees under Regulation 2024/1505 are paid by the critical providers themselves, not by the financial entities that use them. That levy does not enter your budget; it enters the price of your cloud.

Proportionality offers legitimate savings: the simplified framework for microenterprises, no TLPT absent designation, outsourced monitoring. But alongside the licensed operator's compliance stack and the EU AML package, this is a fixed load that turns a "licence in reserve" into an expensive hobby — and the strongest argument for pricing a rented licence seriously at the outset.

How DORA shows up outside the licence holder: questionnaires, outages and due diligence

DORA confers no direct rights on whoever's money sits with the operator. It is a supervisory regulation, not a consumer one, and no cause of action flows from it. Outside the licence holder's own perimeter it does, however, change three practical things.

First, it explains the questionnaires. If you are a counterparty, vendor or portfolio company of a financial entity, questions about your software, integrations, data locations and subcontractors are not curiosity — they are someone populating their register of information. Declining to answer increasingly means declining the relationship.

Second, it sets expectations during an outage. The operator must classify the incident, notify the supervisor within hours and recover to a tested plan rather than improvising. A service down for a third day with no coherent status update is itself evidence about the quality of the framework behind it.

Third, it supplies a vocabulary for due diligence. When deciding where to hold operating balances, ask three questions: how the last register filing went, whether the entity is designated for TLPT and when the last one ran, and what the exit plan for its principal cloud provider actually says. The answers reveal more than any brochure. This matters most when comparing venues: a Lithuanian EMI and a Luxembourg one carry identical DORA obligations, but the maturity of execution and the strictness of supervision differ considerably.

One reminder DORA does not displace: money held at an EMI is not covered by deposit guarantee schemes, and operational resilience is no substitute for safeguarding. A family's own cyber defence is a separate discipline, covered in family cybersecurity and privacy.

The first year of incidents: numbers instead of horror stories

The ESAs' first annual report on major incidents, published on 3 June 2026, closes out the 2025 reporting year: 3,383 major incidents, an average of 0.18 per entity in scope. Credit and payments accounted for more than 75% of them. System failures caused 51%, external events 27%, and almost a third of all major incidents stemmed from failures attributable to third parties. Cyberattacks made up only 10%, roughly two-thirds of those being DDoS and data exfiltration or manipulation. A third of incidents — 1,056 — had cross-border effect, and around 8% touched more than ten member states. Two-thirds caused no or only minor disruption, and nearly 60% affected fewer than 1,000 clients.

The distribution tells you what the regulation is actually about. DORA is not a "hacker law" but a law about dependence on other people's infrastructure: your vendor's outage is your reportable incident, and the first year's data bears that out.

Overlaps: NIS2, MiCA, PSD2 and GDPR

For the financial sector DORA is lex specialis to NIS2. A licence holder lives under DORA and does not report twice. But non-financial group companies — a holdco, an IT subsidiary, a shared services entity — can fall under NIS2 in their own right through national transposition laws, and that is a separate project with separate deadlines.

The MiCA overlap is direct: a CASP has been inside DORA's perimeter from the same date, and the ICT section of a licence file is assessed against DORA rather than generic information-security language. For anyone entering under a third party's MiCA licence, the principal will insist on DORA-compatible contractual undertakings, because it must enter you into its own register.

With PSD2 the duplication has been removed, by Directive 2022/2556 and the EBA's repeal of its guidelines on 17 January 2025. Ahead lies PSD3 and the PSR: re-authorisation of EMIs into the single PI regime will put the ICT block through supervision again, and applications filed in 2027–2028 will need full DORA documentation from the start.

With GDPR, by contrast, the duplication persists and must be designed for. A DORA incident notification goes to the financial supervisor; a personal data breach notification under GDPR Article 33 goes to the data protection authority within 72 hours. A single incident can trigger both, through different channels, on different clocks and with different content. A single response procedure has to split those two streams automatically.

Finally, the EBA guidelines. EBA/GL/2019/04 on ICT and security risk management was not repealed outright but narrowed from 11 February 2025: what survives covers only relationship management with payment service users, and only for entities inside DORA's perimeter. Everything else has been absorbed by the regulation. The outsourcing guidelines continue to apply to non-ICT arrangements, but ICT outsourcing is now read through Articles 28 to 30 of DORA.

The UK is building a mirror perimeter. The FCA and PRA rules on critical third parties (PS24/16) have applied since 1 January 2025; on 10 July 2026 HM Treasury designated the first four — AWS, Google Cloud, Microsoft and Oracle — and oversight by the Bank of England, PRA and FCA began on 13 July 2026. A group licensed in both the EU and the UK lives under two regimes at once, and contracts with shared vendors have to satisfy both.

The calendar to 2028

DateMilestone
16 January 2023Directive (EU) 2022/2556 enters into force
15 July 2024RTS 2024/1772 on incident classification enters into force
17 December 2024ESAs publish dry run results: 6.5% of registers error-free
17 January 2025DORA applies; EBA repeals PSD2 major incident reporting guidelines
21 January 2025Commission rejects the draft RTS on subcontracting
11 February 2025EBA narrows guidelines EBA/GL/2019/04 on ICT and security risk
1–15 April 2025First live register of information filing (CSSF window)
2 and 22 July 2025Subcontracting RTS 2025/532 published and enters into force
18 November 2025ESAs designate the first 19 critical ICT third-party providers
17 January 2026Commission review deadline on requirements for statutory auditors (Art 58)
11 February – 31 March 2026Second register filing, cut-off 31 December 2025
3 June 2026ESAs publish the first annual report on major ICT incidents
13 July 2026UK oversight of critical third parties begins
2027 onwardsAnnual register filing; annual refresh of the CTPP list
17 January 2028General DORA review: CTPP designation criteria, the voluntary nature of cyber threat notifications, oversight of third-country providers, functioning of the Joint Oversight Network
≈2028–2029Re-authorisation of EMIs into PIs under PSD3: the ICT block is re-examined

The CTPP list is worth watching in its own right: it is revised annually, and a key vendor entering it redraws your concentration map.

Q/A

We are a microenterprise with an EMI licence — what is mandatory

The simplified framework under Article 16: basic ICT risk management, incident reporting and the register of contracts are due in any case; TLPT is not. The microenterprise threshold is fewer than 10 staff and turnover or balance sheet up to €2 million — cross it and you move into the full regime automatically, so the transition is best prepared in advance. The 2026 register collection covered everyone, including third-country branches, which makes "we will go unnoticed" a poor strategy.

Our product runs entirely on AWS — is that now a problem

No. Designation as a critical provider neither prohibits using one nor shifts responsibility to the ESAs: they supervise AWS, you still supervise your dependence on AWS. Your duties are unchanged — a contract carrying the full Article 30 terms, including unrestricted audit rights and participation in TLPT, a documented concentration assessment and a tested exit plan. Since 2025 you must also trace the subcontracting chain beneath a critical function.

Which contracts have to be rewritten first

Those supporting critical or important functions: cloud, core banking, processing, the KYC/AML vendor, card processing, hosting. These need the full Article 30(3) set — quantitative service levels, access and audit rights for you and the regulator, an obligation to participate in TLPT, contingency plans and exit provisions with a transition period. Other ICT contracts need only the Article 30(2) terms, but every contract without exception goes into the register.

There are no fines yet — can this wait until 2027

The lever is already live: registers are cross-checked automatically, a weak ICT section slows licences and passporting, and a first major incident reported badly becomes a supervisory case. Sanctions sit with national law, there is no EU ceiling, and some member states allow criminal liability. When supervisors look back, they will look at the 2025–2026 records — the ones being created, or not created, right now.

Download the offer «DORA»

How we approach such matters, the stages, the team and the contacts in one short document.

If you have questions or need a consultation, our experts will be glad to help.

Request a callback