Learn
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has been fully applicable since 17 January 2025. It is a regulation rather than a directive, so it applies directly across every EU Member State without national transposition of its substantive requirements. What varies is supervision: DORA is enforced by the national competent authority (NCA) that already supervises your type of entity, working alongside the three European Supervisory Authorities (the EBA, ESMA and EIOPA).
Supervisory engagement under DORA is not a single event. It is the ordinary work of a competent authority applying the powers DORA gives it: reviewing your ICT risk management framework, examining your Register of Information, testing your incident reporting and resilience arrangements, and following up where it finds gaps. Article 50 sets out those powers, including the right to access any relevant document or data, to carry out on-site inspections, to summon representatives for explanations, and to require corrective and remedial measures.
This article walks through how DORA supervision is organised, what a review process typically involves, what supervisors examine against each part of the regulation, how the penalty regime actually works, and how to be ready. Where a specific enforcement figure or supervisory statistic cannot be tied to the regulation or to an official source, we have left it out rather than guess.
The Register of Information is already live
The ESAs ran a voluntary dry run of the Register of Information in 2024, with almost 1,000 financial entities submitting registers through their competent authorities. Official reporting began in 2025. Under DORA, competent authorities collect the registers from the entities they supervise, run data quality checks, and act as the gateway to the ESAs. A complete, exportable Register of Information is therefore the first thing most supervisors can be expected to look at.
🎯
Section 1
Who Supervises Your DORA Compliance
DORA does not create a single new supervisor. Article 46 designates, for each category of financial entity, the competent authority that already oversees it under the relevant sectoral law. Credit institutions are supervised by their prudential authority, with the ECB responsible for those classified as significant under the Single Supervisory Mechanism. Payment and e-money institutions, investment firms, insurers and reinsurers, fund managers, crypto-asset service providers and the other entity types each fall to the authority designated in their governing directive or regulation.
Separately, critical ICT third-party service providers (CTPPs) are overseen at EU level. Under the Oversight Framework in Articles 31 to 44, one of the ESAs is appointed Lead Overseer for each designated CTPP. That oversight sits above your own supervision: it does not replace your obligation to manage the third-party relationship, but it means the largest providers face direct scrutiny of their own.
How supervisory attention is prioritised
DORA is built on the principle of proportionality (Article 4): requirements and supervisory intensity should reflect an entity's size, risk profile, and the nature, scale and complexity of its services. Authorities do not review every entity at once. In practice, the factors that tend to raise an entity up the queue are visible in the regulation itself.
Systemic significance
Larger and more systemically important entities carry the fullest set of obligations and draw the closest attention. Smaller entities benefit from the simplified ICT risk management framework in Article 16.
Incident history
Entities that have reported major ICT-related incidents give supervisors a natural starting point for a closer look at incident handling and root-cause follow-through.
Third-party concentration
Heavy dependence on a small number of ICT providers, especially any designated as a CTPP, is exactly the concentration risk DORA is designed to surface.
Thematic and routine reviews
Authorities also run thematic reviews on specific risks, such as cloud dependency, and integrate ICT risk into their existing supervisory cycles.
The practical point: if your entity has not yet had a DORA-focused review, that is not a signal you are out of scope. It is time to prepare. Because DORA folds into existing supervisory relationships, the more useful question is not "when will a new regulator arrive" but "how ready are we for our current supervisor to ask DORA questions".
🔍
Section 2
What a DORA Review Involves
DORA does not prescribe a single assessment procedure, and timelines and formats vary by authority and by the scope of the review. What is fixed is the toolkit an authority can draw on, set out in Article 50. A review usually moves through a recognisable sequence, and understanding it helps you allocate resources rather than scramble.
Phase 1 - Notification and scope
A review begins when the authority sets out its scope. That may be a full look across your DORA framework or a thematic focus on one pillar - ICT risk management (Chapter II), incident reporting (Chapter III), resilience testing (Chapter IV), or third-party risk (Chapter V). The scope letter typically comes with an initial document request. Notice periods and response windows are set by the authority, not by DORA.
Phase 2 - Document request and desk review
Article 50 lets the authority take a copy of any document or data it considers relevant. Requests are usually granular. Common items include:
- The complete Register of Information (Art. 28) covering ICT providers, contractual arrangements and sub-outsourcing chains
- The ICT risk management framework and approved policies (Art. 5-16)
- The resilience testing programme, including any threat-led penetration testing (TLPT) where required (Art. 24-27)
- Incident classification procedures and reports filed for major incidents (Art. 17-23)
- Management body ICT risk reports and approval records (Art. 5)
- Business continuity and disaster recovery plans with evidence of testing (Art. 11-12)
- ICT third-party contracts, exit strategies and concentration risk analyses (Art. 28-30)
Phase 3 - On-site inspections or remote deep-dives
Article 50 gives authorities the power to carry out on-site inspections and investigations. Depending on the entity's risk profile, this may be an on-site visit, a remote session, or a combination. Expect requests to see processes working rather than only documented: how an incident is escalated, how the Register of Information is maintained, how testing findings are tracked.
Phase 4 - Interviews with key personnel
Article 50 expressly allows an authority to summon representatives for oral or written explanations and to interview any person who consents. DORA puts the management body at the centre of ICT risk under Article 5, so interviews commonly reach beyond the technical team:
- Management body members: to show ICT risk is a standing agenda item, that the framework was approved at board level, and that members maintain adequate knowledge
- CTO / CIO: architecture, resilience testing outcomes, change management
- CISO: incident classification, threat landscape, security operations
- Chief Risk Officer: integration of ICT risk into the wider risk framework
- Compliance / DPO: regulatory reporting and alignment across DORA, GDPR and NIS2
- Third-party risk managers: vendor assessment, contract monitoring, exit plan testing
Consistency matters: supervisors look for alignment between what the policies say and what people actually do.
Phase 5 - Findings and follow-up
Where the authority identifies shortcomings, Article 50 lets it require corrective and remedial measures. In practice that means findings, remediation expectations, and follow-up. The formats and deadlines are set by each authority. A review outcome becomes part of your supervisory record and shapes how closely you are watched next time.
📈
Section 3
What Supervisors Examine, Article by Article
The clearest way to prepare is to map each obligation to what strong evidence looks like against it. The table below is a readiness aid, drawn from the text of DORA. It is not a supervisory scoring rubric issued by any authority.
| Area | DORA reference | Strong evidence | Likely to raise questions |
|---|---|---|---|
| Management body oversight | Art. 5 | Board formally approves the ICT risk framework; standing agenda item with regular reporting; members maintain documented ICT knowledge | No evidence of board-level ICT risk discussion; framework signed off by IT alone; no training records |
| ICT risk management framework | Art. 6-16 | Documented framework with clear ownership and risk appetite, regular review cycles, integrated with enterprise risk management | Generic IT policies relabelled as a DORA framework; no ICT risk appetite; policies not reviewed since before DORA |
| Register of Information | Art. 28 | Complete, accurate register covering all ICT third-party providers; arrangements mapped to functions; maintained in the reportable ESA format | Incomplete provider inventory; missing sub-outsourcing chains; cannot produce the ESA-format export; data quality gaps such as missing identifiers |
| Incident classification and reporting | Art. 17-23 | DORA classification criteria implemented and tested; reporting deadlines met; root-cause analysis documented | Pre-DORA process not updated; classification by subjective judgment; late or missing notifications |
| Resilience testing programme | Art. 24-27 | Risk-based testing of critical ICT systems; TLPT performed where the entity meets the criteria; findings tracked to remediation | Testing limited to an annual pen test; no TLPT where required; results not linked to risk management; prior findings unaddressed |
| Third-party risk management | Art. 28-30 | Due diligence on ICT providers; concentration risk analysed; exit strategies documented and tested; contracts aligned with Art. 30 | No exit strategies; contracts missing DORA clauses such as audit rights, data location and subcontracting; concentration risk not assessed |
| Business continuity and recovery | Art. 11-12 | Plans cover all critical functions; tested with documented results; recovery objectives defined and validated | Plans exist on paper but untested; recovery objectives not defined; last test over 12 months ago; failures not addressed |
| ICT change management | Art. 9 | Formal process with risk assessment, testing and rollback; emergency change process defined; audit trail maintained | Informal or inconsistent process; no pre-deployment risk assessment; emergency changes bypass controls |
| Information sharing | Art. 45 | Considered participation in threat intelligence sharing, with a documented decision either way | No awareness of the arrangements; no participation and no rationale recorded |
| ICT asset management | Art. 8 | Complete ICT asset inventory; classification by criticality; dependencies mapped; assets supporting critical functions identified | Incomplete inventory; no criticality classification; dependencies unknown; shadow IT not addressed |
The incident reporting clock
A recurring supervisory theme is whether an entity can actually meet the major-incident reporting deadlines set by the ESAs' technical standards. The timeline runs in three steps:
| Initial notification | Within 4 hours of classifying the incident as major, and no later than 24 hours after becoming aware of it. |
| Intermediate report | Within 72 hours of the initial notification. |
| Final report | Within one month of the last update. |
⚖️
Section 4
Penalties and Remedial Measures: How They Actually Work
DORA does not fix a single EU-wide fine ceiling for financial entities the way some regulations do. Article 50 requires each Member State to lay down administrative penalties and remedial measures that are, in the regulation's words, "effective, proportionate and dissuasive". As a result, the maximum monetary amounts and the way they are calculated differ from one Member State to another. Treat any single headline figure with care unless it is tied to the specific national regime that applies to you.
Corrective and remedial measures
Article 50 lets a competent authority require corrective and remedial measures for breaches, order the cessation of conduct that breaches the regulation, and adopt measures, including of a pecuniary nature, to bring an entity back into compliance.
Public notices
Under Article 50, authorities may issue public notices, including statements identifying the person responsible and the nature of the breach. Reputational exposure, not only the fine, is part of the deterrent.
Individual accountability
Article 50 allows measures to be applied, subject to national law, to members of the management body and other individuals responsible for a breach. ICT risk is a governance matter, not only a technical one.
Oversight of critical providers
For designated CTPPs, the Lead Overseer can impose periodic penalty payments of up to 1% of the provider's average daily worldwide turnover in the preceding year, on a daily basis for up to six months, under Article 35.
One gap tends to widen the review
A shortcoming in one area often prompts questions in a related one. An incomplete Register of Information invites scrutiny of third-party risk management, which in turn raises concentration risk and exit planning. Closing the obvious gaps early keeps a focused review from broadening.
🌎
Section 5
How DORA Supervision Is Structured Across the EU
Because DORA is a directly applicable regulation, the substantive rules are the same in every Member State. The supervisory architecture is layered: your own competent authority, the three ESAs coordinating at EU level, and the Oversight Framework for the largest ICT providers. Knowing which layer does what tells you where a given request will come from.
| Layer | Who it covers | Role and legal basis |
|---|---|---|
| National competent authority | Your financial entity, by type | The day-to-day supervisor. Article 46 designates, for each entity category, the authority already responsible under the relevant sectoral law. It holds the Article 50 powers to request documents, inspect, interview and require remediation. |
| The ECB (SSM) | Significant credit institutions in the banking union | Acts as the competent authority for significant banks it directly supervises, folding ICT risk into its existing prudential supervision. |
| The ESAs (EBA, ESMA, EIOPA) | All in-scope entities, via coordination | Author the technical standards, run the Register of Information collection through the NCAs, and coordinate consistent application. They do not replace your NCA. |
| Lead Overseer | Designated critical ICT third-party providers | One of the ESAs is appointed Lead Overseer for each CTPP under the Oversight Framework (Art. 31-44), with its own powers including the periodic penalty payments in Article 35. |
Cross-border groups
Entities supervised across more than one jurisdiction may see differences in review timing and format, since the practical approach rests with each national authority even though the rules are common. Where the ECB is the direct supervisor, ICT risk is handled through its existing supervisory arrangements. Build your evidence once, in a form any of your supervisors can consume.
✅
Section 6
Preparing for a DORA Review: A Practical Checklist
Preparation is what separates a calm review from a scramble. The items below are the standing readiness most entities should hold, each tied to a part of DORA rather than to any single supervisor's preference.
Readiness checklist
1. Register of Information (Art. 28)
Complete register with all providers, contractual arrangements, business function mappings, sub-outsourcing chains and legal entity identifiers. Verify the ESA-format export. Cross-reference against procurement records to catch missing providers.
2. ICT risk management framework (Art. 5-16)
Board-approved framework with supporting policies for information security, access control, change management, business continuity and incident management. Evidence of review with dates and signatories.
3. Management body evidence (Art. 5)
Minutes showing ICT risk on the agenda, an approved risk appetite statement, training records for the management body, and board-level ICT risk reporting.
4. Incident response readiness (Art. 17-23)
A classification approach aligned to the DORA criteria, a documented reporting workflow with escalation paths that can meet the deadlines, an incident log with root-cause analyses, and evidence of exercises.
5. Resilience testing evidence (Art. 24-27)
A testing programme, TLPT results where the entity meets the criteria, vulnerability assessments with remediation tracking, and continuity and recovery test results fed back into risk assessments.
6. Third-party contracts and exit plans (Art. 28-30)
Contracts reviewed for the Article 30 requirements such as audit rights, data location, subcontracting and termination. Exit strategies for critical providers. A current concentration risk analysis.
7. Gap assessment and remediation tracker
A documented internal gap assessment with a remediation plan showing owners, deadlines and progress. Demonstrating that you know your gaps and are closing them is usually more credible than claiming none exist.
8. Staff readiness
A designated coordinator, pre-briefed CTO, CISO, CRO and management body, interview preparation for key personnel, and a central repository the review team can be given access to.
The entities that come through a review well are rarely the ones claiming perfection. They are the ones that understand their own gaps, hold a credible remediation plan, and can retrieve evidence quickly and completely. Being able to show your working is worth more than asserting there is nothing to find.
🛡️
Section 7
How Venvera Helps You Stay Review-Ready
Venvera is a multi-framework compliance platform. DORA is one of the frameworks it supports, alongside NIS2, ISO 27001 and others, so the evidence you assemble for a supervisor can be reused across the obligations you carry. The point is simple: keep your framework, register, incidents and testing in one place, so that when a supervisor asks, you retrieve rather than reconstruct.
Register of Information
A structured register for ICT providers, contractual arrangements, business functions and sub-outsourcing chains, with ESA-format export so you are not compiling spreadsheets under time pressure.
Gap assessment with scores
A gap assessment across the DORA chapters with article-level scoring, so you can see where you stand and produce a remediation view before a supervisor asks for one.
Board-ready reporting
Board-level ICT risk reporting aligned to Article 5: posture, open findings, remediation progress and incident trends, in a form you can put in front of the management body.
Evidence management
A central evidence repository with version history and audit trails, so continuity test results or incident records can be retrieved quickly and shown to be current.
Incident management
DORA-aligned classification and a reporting workflow built around the ESAs' deadlines, covering the incident lifecycle from detection through root-cause analysis.
Third-party and concentration risk
Provider risk assessments, concentration analysis, exit plans and Article 30 contract tracking, so a question about a critical provider has a documented answer.
Frequently Asked Questions
Who supervises a financial entity's DORA compliance?
Your existing sectoral supervisor. Article 46 of DORA designates, for each entity type, the competent authority already responsible under the relevant EU directive or regulation, with the ECB acting for significant credit institutions in the banking union. The three ESAs (EBA, ESMA and EIOPA) coordinate at EU level and run the Register of Information collection through those national authorities. Separately, critical ICT third-party providers are overseen by a Lead Overseer, one of the ESAs, under Articles 31 to 44.
Since when has DORA applied?
DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 (Article 64). It is directly applicable across the EU, so its substantive requirements took effect on that date without national transposition.
What can a supervisor request under DORA?
Article 50 gives competent authorities broad powers: to access and take a copy of any document or data considered relevant, to carry out on-site inspections and investigations, to summon representatives for oral or written explanations, to interview any consenting person, and to require corrective and remedial measures. In practice a supervisor will commonly ask for the Register of Information, the ICT risk management framework, incident records, resilience testing results and third-party contracts.
What penalties can apply under DORA?
DORA does not set a single EU-wide fine amount for financial entities. Article 50 requires each Member State to provide administrative penalties and remedial measures that are effective, proportionate and dissuasive, so the maximums vary by country. Authorities can order the cessation of a breach, adopt pecuniary measures, issue public notices naming the entity and the breach, and apply measures to responsible individuals. For designated critical ICT third-party providers, the Lead Overseer can impose periodic penalty payments of up to 1% of average daily worldwide turnover, on a daily basis for up to six months, under Article 35.
What should we have ready before a review?
A complete, exportable Register of Information; a board-approved ICT risk management framework with supporting policies; an incident classification and reporting capability that can meet the ESAs' deadlines; a resilience testing programme, including TLPT where the entity meets the criteria; and third-party arrangements with Article 30 clauses, exit strategies and a concentration risk analysis. Holding a documented gap assessment and remediation plan on top of these is usually viewed more favourably than claiming full compliance.
Be Review-Ready With Venvera
A DORA review is rarely a surprise in substance: the regulation tells you what a supervisor can ask for. The work is in being able to produce it. Keeping your framework, Register of Information, incidents, testing and third-party evidence in one system turns a review from a reconstruction exercise into a retrieval one.
If you want a quick read on where you stand, run a free compliance check, or see how the DORA module and the control crosswalk let you reuse evidence across DORA, NIS2 and ISO 27001.
Primary sources
This guide is drawn from the regulation and official EU material: Regulation (EU) 2022/2554 (the full DORA text, including Articles 5, 17-30, 35, 46, 50 and 64); the European Banking Authority DORA pages; and the ESAs' Register of Information dry run communications. Incident reporting deadlines follow the ESAs' technical standards. Always confirm the current text and the national regime that applies to you before relying on a specific date or figure.
Updated July 2026 · Venvera Compliance Platform · venvera.com
This article is for information only and is not legal or regulatory advice. Confirm the requirements and the national regime that apply to your institution with your own advisers.
