Learn
By the time you finish this article, you’ll know exactly what a DORA supervisory assessment looks like from the inside - and which gaps are getting firms flagged right now.
I’ve been dreading this day for about two years. Not because I think DORA is a bad regulation - honestly, it’s one of the better-designed pieces of EU financial legislation - but because for most of 2024 and 2025, the conversation around DORA compliance felt almost theoretical. “We’re getting ready.” “We’re mapping our providers.” “We’re building out our framework.”
Well. Theory’s over.
National competent authorities across the EU are now conducting supervisory assessments under DORA. Not pilot reviews. Not “readiness checks.” Actual enforcement-backed assessments with the power to issue findings, impose remediation timelines, and - yes - levy penalties. The European Supervisory Authorities published their oversight framework guidance in late 2025, and NCAs have been staffing up supervisory teams since Q4.
If you’re in a compliance, risk, or IT governance role at a financial institution in the EU, this is the article that tells you what’s actually happening on the ground - not what the regulation says in the abstract, but what regulators are doing in practice.
Who’s Getting Assessed First (and Why)
Let’s dispel the first myth: supervisory assessments aren’t random. NCAs are prioritising based on a combination of entity size, systemic importance, and - this is the part nobody talks about - the quality of the Register of Information submissions they received in January 2025.
Think about it from the regulator’s perspective. They asked every financial entity in their jurisdiction to submit a Register of Information. Some entities submitted thorough, well-structured registers with proper ESA entity codes, clear contractual arrangements, and complete function-to-provider mappings. Others submitted... something. A spreadsheet. A PDF. A zip file with 40 Excel tabs and no obvious schema.
Guess which group is getting the early visits.
The NCAs that I’ve spoken with (indirectly, through compliance contacts at assessed firms) are generally following a tiered approach:
Tier 1 (2025-Q1 2026): Significant financial institutions, systemically important payment processors, large insurance groups. These entities were on the NCA’s radar well before DORA. The supervisory assessment is essentially an extension of existing oversight, now with specific DORA criteria.
Tier 2 (2026): Mid-tier banks, investment firms with material ICT outsourcing, electronic money institutions, and crypto-asset service providers that registered under MiCA. These are the entities where the NCA expects “reasonable progress” but will accept documented remediation plans.
Tier 3 (2026-2027): Smaller entities, boutique investment firms, crowdfunding platforms, smaller payment institutions. The NCA knows these firms have fewer resources, but “proportionality” doesn’t mean “exemption.” They still need the basics: a functional RoI, documented ICT risk management, incident reporting procedures.
What Regulators Actually Ask For
I was able to piece together a composite picture of early DORA supervisory assessments from conversations with compliance officers at three firms that have been through them. The consistent thread? Regulators aren’t impressed by slide decks. They want working systems, live data, and people who can explain what’s actually happening - not what’s written in a policy document.
Here’s what they’re focusing on, ranked by how much time supervisors are spending on each area:
1. Register of Information - The First Thing They Check
Every single assessment I’ve heard about starts here. The supervisor asks to see the Register of Information. Not a summary. Not a report about the register. The actual register, with all its entity relationships intact.
They’re checking for:
- Completeness: Does the register cover all ICT third-party service providers, or only the ones you thought to include? Regulators have their own intelligence about major cloud providers and SaaS platforms. If your bank uses Salesforce, Azure, and Bloomberg Terminal but your register only lists your core banking vendor, that’s a finding.
- Structural integrity: Are contractual arrangements properly linked to business functions? Can the supervisor trace from a specific provider through a contract to the business function it supports, and from there to the entity that relies on it?
- ESA entity codes: Are LEI codes correct? Are EBA/EIOPA/ESMA classifications accurate? This sounds like a technicality, but incorrect entity codes mean your data can’t be cross-referenced with the ESA’s aggregated oversight database. They take this seriously.
- Currency: Is the register up to date, or is it a snapshot from six months ago that nobody’s touched since submission?
One compliance officer told me their supervisor spent over two hours just on the Register of Information. Two hours. On one part of the assessment. If your RoI is a spreadsheet that doesn’t reflect your actual provider landscape, you’re going to have a very long day.
2. ICT Risk Management Framework - Show, Don’t Tell
Regulators are done with theoretical frameworks. They want evidence that your ICT risk management framework is operationalised. Specifically:
- Can you demonstrate a risk assessment that was conducted in the last 12 months, with documented methodology, actual findings, and remediation actions?
- Is there a risk register that’s actively managed - with risks being added, updated, escalated, and closed?
- Does the management body actually review ICT risk? Show the board minutes. Show the risk committee agenda. Not a template - the actual meeting record.
The phrase I keep hearing from people who’ve been through these assessments: “They wanted to see the work, not the policy.”
3. Incident Reporting Readiness - The Fire Drill
Some NCAs are running what I’d call a “fire drill” as part of their assessment. They present a hypothetical ICT incident scenario and ask: walk us through your response. Right now. In this room.
They’re looking for whether your team can:
- Classify the incident using DORA’s RTS criteria (not your generic “High/Medium/Low” matrix)
- Identify the correct notification authority and timeline (initial notification within 4 hours for major incidents)
- Demonstrate a documented escalation path from IT operations to compliance to management body
- Show that your incident classification thresholds match the RTS - transaction counts, service availability percentages, economic impact thresholds, data integrity metrics
One firm had beautifully documented incident response procedures. But when the supervisor asked the head of IT operations to classify a specific scenario using the DORA RTS criteria, he couldn’t do it. The procedure existed. The training hadn’t happened. That became a finding.
4. Third-Party Risk Management - Beyond the Vendor List
Supervisors are digging into your actual third-party ICT risk management practices. Do you have exit strategies for critical providers? Can you demonstrate due diligence on sub-outsourcing? Do your contracts include the clauses DORA requires (audit rights, termination triggers, data location)?
The kicker: they’re asking to see actual contracts, not just your contract register. If your contract with AWS doesn’t include DORA-required provisions, saying “we’re in the process of renegotiating” only buys you so much time.
5. Digital Operational Resilience Testing - Prove You Test
DORA Article 24 requires digital operational resilience testing. Regulators are asking for evidence: when was your last vulnerability assessment? What penetration tests have you run? What were the findings, and what did you do about them?
For firms designated for TLPT (threat-led penetration testing), they’re already asking about TIBER-EU alignment and whether you’ve engaged a qualified threat intelligence provider. But more on that in a moment.
The Penalty Framework: What’s Actually at Stake
DORA doesn’t prescribe harmonised penalties the way GDPR does (no “4% of global turnover” headline number). Instead, it leaves penalty frameworks to Member States, subject to DORA’s minimum requirements. Here’s what that means in practice:
Administrative penalties
NCAs can impose fines. The amounts vary by jurisdiction, but Article 50 of DORA specifies that penalties must be “effective, proportionate, and dissuasive.” Several Member States have set maximum penalties at up to 1% of average daily worldwide turnover, applied for up to six months. For a mid-sized bank, that’s not pocket change.
Periodic penalty payments
If you don’t remediate findings within the timeline set by the NCA, they can impose daily penalty payments until you do. This is the mechanism that makes “we’ll get to it next quarter” a very expensive strategy.
Public disclosure
NCAs can publish the identity of the entity and the nature of the infringement. For a financial institution, the reputational damage from a public DORA finding can be worse than the fine itself.
Personal liability
Some Member States have extended liability to individual members of the management body. If the board approved an inadequate ICT risk management framework, individual directors can face personal penalties. This tends to focus minds rather quickly.
The 8 Gaps That Keep Showing Up
Based on what I’m hearing from firms that have been through early assessments, here are the most common findings. If you recognise yourself in any of these, you still have time to fix them - but the window is narrowing.
1. Incomplete RoI
Missing ICT providers, particularly SaaS tools that nobody thought to classify as “ICT services” - Slack, Jira, Confluence, Zoom. If your business would be materially impacted by their outage, they belong in the register.
2. No exit strategies
DORA Article 28 requires documented exit plans for critical ICT providers. Most firms have contracts. Very few have exit strategies that would actually work in practice.
3. Generic incident classification
Using your existing “P1/P2/P3” incident framework instead of DORA’s specific RTS criteria. The regulation defines precise thresholds. Your internal labels don’t map to them automatically.
4. Board engagement is performative
The board “approved” the ICT risk management framework but can’t explain what’s in it. Regulators are asking board members direct questions. “I rely on my CISO” is not the right answer.
5. No concentration risk analysis
You use AWS for everything but haven’t documented what happens if AWS goes down. Concentration risk analysis under DORA Article 29 isn’t optional - it’s a core requirement.
6. Testing is ad hoc
You ran a pen test last year. Maybe. But there’s no documented testing programme, no defined frequency, no evidence that findings led to remediation. DORA wants a programme, not a point-in-time exercise.
7. Sub-outsourcing blind spots
Your provider uses a sub-contractor, who uses another sub-contractor. You didn’t know. DORA says you should. The chain of ICT sub-outsourcing needs to be documented and risk-assessed.
8. Cross-border inconsistency
Groups operating in multiple EU countries with different DORA approaches in each subsidiary. DORA applies at the entity level, but regulators expect group-wide coherence.
Your 90-Day Action Plan
If you haven’t been assessed yet, you have a window. It won’t last forever. Here’s what I’d prioritise if I had 90 days to get ready:
Weeks 1-2: Audit your Register of Information
Compare it against reality. Walk through every department and ask: “What ICT services do you actually use?” You’ll find gaps. Fix them now. Make sure every entry has correct ESA entity codes, proper contractual linkages, and accurate function mappings.
Weeks 3-4: Run an incident response drill
Create a realistic ICT incident scenario. Run it with your actual response team. Can they classify it using the DORA RTS criteria? Do they know who to notify and within what timeframe? If not, you’ve identified your training gap before the regulator does.
Weeks 5-8: Document your risk management framework properly
Not the PowerPoint version. The actual, operationalised version with evidence of risk assessments conducted, findings recorded, remediation tracked, and board oversight documented. If you can show a supervisor a living system rather than a static document, you’re in a fundamentally different position.
Weeks 9-10: Review your critical provider contracts
Pull the contracts for your top 10 ICT providers. Check each one for DORA-required provisions: audit rights, exit clauses, data location, sub-outsourcing notification requirements. Flag the gaps. Start the conversations with procurement.
Weeks 11-12: Get your testing programme on paper
Document a formal digital operational resilience testing programme with defined scope, frequency, methodology, and remediation tracking. Even if you haven’t run all the tests yet, having a structured programme shows the regulator you’re taking it seriously.
Proportionality Is Real - But It’s Not a Get-Out-of-Jail Card
DORA explicitly states that requirements apply in a proportionate manner, taking into account the size, risk profile, nature, scale, and complexity of the financial entity. This is important. A 50-person payment institution isn’t expected to have the same ICT risk management infrastructure as Deutsche Bank.
But proportionality has limits. Here’s what it doesn’t mean:
- It doesn’t mean you can skip the Register of Information.
- It doesn’t mean you can ignore incident reporting.
- It doesn’t mean your board doesn’t need to understand ICT risk.
- It doesn’t mean you can avoid testing entirely.
What it does mean is that the depth and sophistication of your approach should match your risk profile. A small firm can have a simpler risk framework, fewer documented scenarios, and less frequent testing cycles. But “simpler” doesn’t mean “absent.” The regulators I’ve heard about are perfectly willing to accept proportionate approaches - as long as they can see that the approach is conscious, documented, and actually implemented.
The NCA Lottery: Supervisory Approaches Vary
One thing that’s become clear is that different NCAs are taking somewhat different approaches. DORA is an EU regulation (directly applicable, no transposition needed), but the supervisory methodology isn’t fully harmonised yet.
From what I can tell:
- BaFin (Germany) is being thorough and structured, with detailed questionnaires sent in advance and focused on-site sessions. They’re particularly interested in ICT concentration risk and sub-outsourcing chains.
- DNB (Netherlands) is integrating DORA assessments into their existing supervisory cycle, combining them with broader operational resilience reviews. Pragmatic, but with high expectations on documentation quality.
- Banque de France / ACPR is focusing heavily on incident reporting readiness and cross-border coordination for groups with French subsidiaries.
- CBI (Ireland) has been particularly focused on the Register of Information and third-party risk management, reflecting Dublin’s role as a European fintech hub with significant outsourcing dependencies.
The ESAs are working toward greater harmonisation through joint supervisory guidance, but for now, your experience will depend partly on which NCA oversees you. The one consistent theme? They all want to see the Register of Information. Get that right, and you’re starting from a position of strength.
The Window Is Open. It Won’t Stay Open.
Right now, most NCAs are still in a phase where they’re willing to accept documented remediation plans rather than immediately reaching for penalties. That’s a grace period, not a permanent state. By late 2026, the expectation will shift from “show us your plan” to “show us your results.”
The firms I’ve seen come through early assessments in good shape all share one characteristic: they treated DORA as an ongoing operational capability, not a project with a finish line. Their Register of Information is a living system. Their risk assessments are current. Their incident response has been tested. Their board can actually talk about ICT risk intelligently.
That’s not impossible. It’s not even that hard, if you have the right tools and approach. But it does require moving from “we have a policy” to “we have a system.” Platforms like Venvera exist precisely for this - to give you a living compliance system with a structured Register of Information, DORA-specific incident classification, and cross-framework mapping across 13 regulatory frameworks - rather than a filing cabinet full of Word documents.
The supervisors are here. They’re professional, they’re prepared, and they’re not going away. The question isn’t whether you’ll be assessed. It’s whether you’ll be ready when it happens.
Ready Before the Regulator Calls?
Venvera gives you a structured Register of Information, DORA-specific incident classification, risk management workflows, and xBRL-CSV export - everything supervisors are checking for, starting at €399/month.
Book a Demo →Last updated: March 2026. This article reflects early enforcement observations and should not be taken as legal advice. Consult your legal counsel and NCA for jurisdiction-specific guidance.