EU DORA compliance: where the ICT register fails and supervisors notice
Sienna VanceApril 29, 2026
Key takeaways
DORA''s ICT third-party register is the first document supervisors request in an inspection. Financial entities that built their register from procurement records miss providers onboarded outside formal IT processes, which are typically the highest-risk dependencies.
DORA incident classification requires entities to assess whether an ICT incident meets the criteria for ''major incident'' status within a supervisory notification window. Most entities cannot make that assessment accurately because their monitoring does not cover the full ICT asset scope used in the classification criteria.
Threat-led penetration testing under DORA is not a penetration test with a different name. TLPT requires an intelligence-led red team engagement scoped to production systems, with the threat intelligence phase documented and submitted to the competent authority. Entities that submit standard penetration test reports in place of TLPT evidence create a specific regulatory exposure.
DORA Article 28 requires contractual arrangements with ICT third-party providers to include audit rights, exit strategies, and service level commitments covering resilience. Existing contracts with cloud providers and SaaS vendors renegotiated before DORA came into force typically do not contain these provisions, and renegotiation has proved slower than compliance programs anticipated.
Critical ICT third-party providers designated by the ESAs are subject to direct supervisory oversight. Financial entities relying on a designated provider do not inherit that oversight as a compliance substitute. They remain responsible for their own DORA obligations regardless of the provider''s supervisory status.
DORA penalties reach 1% of average daily global turnover applied per day of continued non-compliance for critical ICT providers, and up to 2% of total annual turnover for financial entities. The daily penalty structure for providers creates pressure on the contracts financial entities need to renegotiate.
TL;DR
DORA compliance programs built around the five-pillar framework produce good documentation. What supervisors actually examine in an inspection is narrower and more specific: the ICT third-party register, the evidence that TLPT was conducted to the required standard, the incident classification trail for the past twelve months, and the contractual provisions with the top five ICT dependencies. Those four things are where the gap between a clean internal review and a difficult supervisory inspection consistently opens.
The register that was complete until the inspection
A mid-tier investment firm operating across four EU member states completed its DORA gap analysis in late 2024. The ICT third-party register listed 47 providers, categorised by criticality, with contractual review status documented for each. The gap analysis rated the register as substantially complete. When the national competent authority conducted its first DORA inspection in Q1 2025, the lead supervisor asked one question before opening the register: which of your ICT providers were onboarded in the last 36 months by business units rather than through central IT procurement? The firm''s compliance team did not have an answer. Subsequent review found eleven providers in that category, three of which supported trading infrastructure. None were in the register. Two had contracts that predated DORA''s scope and contained no audit rights, no exit strategy provisions, and service level commitments that referenced availability but not resilience under stress conditions.
The gap analysis had been accurate. It assessed every provider in the register against DORA''s contractual requirements and criticality criteria. The register was the problem. It had been built from central IT procurement records and did not capture providers acquired through business unit purchasing, shadow IT channels, or legacy contracts signed before the firm''s DORA program began. DORA does not define ''ICT third-party register'' with a methodology for construction. It defines what the register must contain. The methodology question — how you find everything that should be in it — is where most financial entities have their largest unacknowledged exposure.
What DORA actually requires across its five obligations and where evidence fails
DORA''s five pillars are a useful organizing framework for compliance programs. They are not the framework supervisors use when they examine an entity. Supervisory inspections work from specific artifacts: the ICT risk management framework documentation, the third-party register and supporting contractual evidence, the TLPT reports and intelligence packages, the major incident notification trail, and the business continuity and disaster recovery test results. Each artifact has a specific evidence standard implied by the regulation that is more demanding than the pillar-level requirement suggests.
The ICT risk management framework under Article 5 must be ''comprehensive'' and cover the full scope of the entity''s network and information systems. Comprehensive in supervisory practice means the framework''s scope matches the entity''s actual ICT dependency map, not the systems documented in the internal inventory. The gap between those two scopes is the same gap that appears in NIS2 and PSD2 compliance failures: the undocumented asset, the shadow IT dependency, the cloud storage bucket provisioned on a business unit credit card.
Major incident classification under Article 18 requires entities to apply criteria specified in the regulatory technical standards developed by EBA, ESMA, and EIOPA. The criteria include the number of clients affected, the duration of the incident, the geographic spread, and the economic impact. Applying these criteria accurately requires the entity to know, in near-real-time, which clients are affected by an ongoing incident and what economic exposure that represents. Most financial entities do not have that correlation capability in their monitoring infrastructure. The classification is made on incomplete information, the notification window is missed or the notification is filed with incorrect classification, and the supervisory record shows an incident handling failure.
TLPT under Articles 26 and 27 is the requirement that creates the most confusion in compliance programs. The requirement applies to significant financial entities and mandates threat-led penetration testing conducted in accordance with the TIBER-EU framework or equivalent national framework. TIBER-EU is not a penetration testing methodology. It is a process framework that specifies how threat intelligence is gathered, how the red team scope is defined from that intelligence, how the test is conducted against production systems, and how the results are reported to the competent authority. A standard penetration test report, regardless of quality, is not TLPT evidence under DORA. The distinction matters because supervisors have requested TLPT evidence from entities that submitted penetration test reports and found the documentation insufficient.
Example
In Vulnox engagements with financial entities preparing for DORA TLPT requirements, the most consistent gap was in the threat intelligence phase. TIBER-EU specifies that the threat intelligence report must document the specific threat actors likely to target the entity, their known tactics, techniques and procedures, and the priority attack scenarios derived from that intelligence. This phase must be conducted by an approved Threat Intelligence provider and the output reviewed by the competent authority before the red team engagement begins. Financial entities that had conducted red team exercises without the structured intelligence phase had documentation that satisfied their internal security program but did not constitute TLPT under the TIBER-EU process. The engagement had to be repeated with the correct structure, at additional cost and delay.
The TIBER-EU distinction has a specific regulatory consequence that standard penetration testing does not. TLPT results under DORA are shared with the competent authority and, under Article 27(1)(e), with other financial entities on a voluntary basis when the same ICT provider or infrastructure is involved. This information sharing mechanism is designed to build systemic resilience. It also means that TLPT findings are part of the supervisory record in a way that internal penetration test results are not. Financial entities that are not aware of this when they scope TLPT engagements may inadvertently create supervisory documentation of vulnerabilities that they have not yet remediated.
What DORA readiness assessments consistently find
Assessment base: Vulnox DORA readiness assessments and ICT risk management engagements, 2024-2025
ICT third-party registers built from procurement records miss the highest-risk providers
In Vulnox DORA readiness assessments, the ICT third-party register was the artifact with the largest gap between documented completeness and actual completeness. Registers constructed from central IT procurement records or existing vendor management systems consistently omitted providers in three categories: business unit cloud deployments acquired outside central IT, legacy providers whose contracts predated the firm''s vendor management process, and subcontractors used by primary ICT providers who were not visible to the financial entity in the contracting chain.
DORA Article 28(2) requires the register to cover ''all arrangements with ICT third-party service providers.'' The word ''all'' is not qualified by ''procured through central IT'' or ''known to the vendor management system.'' Supervisors reading a register that omits trading infrastructure dependencies because they were provisioned by a business unit are looking at a DORA Article 28 deficiency, not a documentation gap to be remediated at the next review cycle.
Contractual renegotiation timelines significantly longer than compliance programs projected
DORA Article 30 specifies minimum contractual provisions for ICT third-party arrangements, including audit rights, exit strategies, service level commitments covering resilience, and provisions for cooperation with supervisory inspections. In Vulnox assessments conducted in 2024 and early 2025, financial entities that had identified the contractual gap in 2023 and initiated renegotiation with cloud providers and major SaaS vendors reported that renegotiation timelines extended to 12 to 24 months for providers with significant negotiating leverage. Provisions most frequently resisted by providers were audit rights that would require on-site access and exit strategy documentation that would require providers to document migration assistance procedures.
A financial entity that identified the contractual gap and initiated renegotiation in good faith but has not yet obtained the required provisions is not DORA compliant. The supervisory expectation is the completed contractual arrangement, not the correspondence showing the negotiation is ongoing. Entities in this position need to document the timeline and the specific provisions outstanding and consider whether alternative risk mitigations are available for the gap period.
Major incident classification made on incomplete asset scope data
DORA''s regulatory technical standards for major incident classification include a criterion assessing the number of clients or financial counterparts affected. In Vulnox tabletop exercises simulating DORA incident classification, financial entities consistently could not apply this criterion accurately within the notification window because their monitoring infrastructure did not correlate affected ICT systems to client dependencies in real time. The classification was made on a conservative estimate, the notification was filed with estimated figures, and the follow-up report required correction of the initial classification.
A notification filed with an incorrect major incident classification creates a supervisory record showing either an over-classification or an under-classification. Under-classification, where the entity initially assessed the incident as below major incident threshold and later revised upward, is the more significant regulatory concern. It suggests the incident monitoring and classification process does not function as required under Article 18.
Business continuity and DR test results not maintained as DORA evidence
DORA Article 11 requires financial entities to implement business continuity policies and disaster recovery plans for ICT, and to test them. The testing requirement is not specific about format, but supervisory guidance from EBA has clarified that evidence of testing must be maintained and available for inspection. In several Vulnox assessments, financial entities had conducted DR tests but had not maintained structured documentation of test scope, results, identified gaps, and remediation actions in a format that would support DORA evidence production. The tests had happened. The evidence that they happened and what they found did not exist in a supervisory-grade format.
DORA compliance is not demonstrated by having done the work. It is demonstrated by producing evidence that the work was done, what it found, and what was remediated. An entity that conducted a thorough DR test and cannot produce that evidence in an inspection is in the same supervisory position as an entity that did not conduct the test.
Entities using designated critical ICT providers have more DORA exposure, not less
Common belief
Financial entities that rely on major cloud providers designated as critical ICT third-party providers under DORA benefit from direct supervisory oversight of those providers. The ESA oversight framework for critical providers reduces the financial entity''s own compliance burden for that dependency.
What we found
In DORA readiness assessments conducted after the first ESA designations of critical ICT third-party providers were published, financial entities that had initially treated the designation as a compliance shortcut discovered they needed to add documentation rather than remove it. The designation created a reference point against which their own provider assessments were measured, not a substitute for those assessments.
This assumption is specifically wrong in a way that matters for compliance programs. The ESA oversight framework for critical ICT third-party providers under Chapter V of DORA creates direct supervisory obligations for the provider. It does not modify or reduce the financial entity''s own obligations under Chapters II, III, and IV.
A financial entity relying on an ESA-designated cloud provider must still maintain that provider in its ICT third-party register with full criticality assessment, must still have contractual arrangements meeting Article 30 requirements with that provider, must still include the provider in its ICT risk management framework, and must still have exit strategy documentation. The designation of the provider as critical does not transfer any of these obligations to the provider or to the ESA.
The practical effect runs the other direction. Entities relying on designated critical providers face an additional compliance task: they must demonstrate to their own national competent authority that their oversight and contractual arrangements with the designated provider are consistent with the provider''s supervisory status and the ESA''s oversight findings. If the ESA''s oversight of a critical provider identifies deficiencies, financial entities relying on that provider may receive supervisory questions about whether their own risk assessments reflected those deficiencies.
Where DORA compliance programs consistently underestimate the evidence burden
The ICT concentration risk reporting obligation
DORA Article 29 requires financial entities to report ICT concentration risk arising from dependencies on a single provider or a small number of providers. This is a disclosure obligation that runs separately from the third-party risk management obligations. Most DORA compliance programs address it as a risk identification task. Supervisors have begun treating it as an evidence production obligation: they expect entities to demonstrate that they have quantified their concentration risk, assessed it against appetite thresholds, and have a documented response if the concentration exceeds those thresholds. The gap between a risk identification checklist and a quantified concentration risk assessment with appetite thresholds is significant.
Sub-outsourcing visibility requirements
DORA Article 30(3) requires that contractual arrangements with ICT third-party providers include provisions ensuring the financial entity is informed of and can assess sub-outsourcing arrangements that affect critical or important functions. Major cloud providers and SaaS vendors routinely use subcontractors. The contractual provision requiring notification is the minimum. The evidence obligation is demonstrating that when subcontracting changes occur, the entity''s risk assessment of the primary provider is updated. Compliance programs that obtained the notification provision in contracts but have no process to act on the notifications when they arrive have the documentation without the operational capability.
TLPT scope definition as a supervisory document
Under TIBER-EU and equivalent national frameworks, the scope definition for TLPT is agreed with the competent authority before the engagement begins. The scope document is therefore a supervisory record, not an internal planning document. Financial entities that treat scope definition as an internal security team decision and present the completed engagement to the authority after the fact are not following the process. The authority''s involvement in scope definition is part of the regulatory requirement, and an engagement conducted without that involvement does not qualify as TLPT under DORA regardless of technical quality.
The register as a living document versus a project deliverable
DORA Article 28(3) requires financial entities to update their ICT third-party register at least annually and when significant changes occur. Most compliance programs treated the register as a project deliverable produced for the initial compliance deadline. The ongoing maintenance obligation requires a process for detecting new ICT third-party arrangements, assessing them for criticality, and updating the register within the required timeframe. Financial entities without that process are accumulating an undocumented register gap from the day their initial register was filed.
Proportionality provisions and their limits
DORA Article 4 allows competent authorities to apply requirements proportionately based on the size, nature, and complexity of the financial entity. Smaller entities and those outside the significant institution category have reduced TLPT obligations and some flexibility in ICT risk management framework design. What proportionality does not affect is the core evidence obligations: the third-party register, the incident classification and notification process, and the contractual requirements with ICT providers. Smaller entities that have interpreted proportionality as a general reduction in DORA obligations rather than a reduction in testing requirements specifically are carrying unaddressed compliance gaps.
The supervisory picture that emerged in the first year of enforcement
DORA entered into application on 17 January 2025 with no grace period for financial entities in scope
Unlike some regulatory transitions, DORA''s application date was the compliance date. Entities that had not completed their ICT third-party register, contractual renegotiations, and incident classification processes by that date were non-compliant from day one of enforcement. The compliance gap was not a future risk for those entities. It was an immediate supervisory exposure. Source: DORA Article 64.
EBA published its final regulatory technical standards on major incident classification under DORA in January 2024, leaving financial entities approximately twelve months to build classification capability against the defined criteria
The twelve-month window was sufficient for entities that began operationalizing the criteria immediately. For entities that waited for national competent authority implementation guidance, the effective window was shorter. Several member states published national guidance in Q3 and Q4 2024. Source: EBA RTS on major incident classification, January 2024.
DORA penalties for financial entities reach 2% of total annual turnover; for critical ICT third-party providers the daily penalty structure applies at 1% of average daily global turnover
The daily structure for providers creates cumulative exposure that escalates rapidly for large providers. For financial entities the ceiling is fixed but still significant at scale. The more operationally significant consequence for most entities is mandatory remediation under supervisory supervision, which imposes resource and timeline constraints that can exceed the direct financial penalty. Source: DORA Articles 42 and 52.
Where DORA supervisory focus is heading in 2025 and 2026
The first significant DORA enforcement action against a financial entity will cite ICT third-party register incompleteness as a primary finding, not TLPT non-compliance or incident reporting failure, and will be published by a major EU financial supervisor before end of 2025.
The ICT third-party register is the artifact supervisors examine first and the one with the most systematic construction gap across the financial sector. TLPT non-compliance is visible but affects a narrower subset of entities and is more likely to result in remediation directions than public enforcement actions in the first wave. Incident reporting failures require an incident to have occurred. Register incompleteness can be found in any inspection without waiting for an incident. The supervisory incentive to establish the register obligation through an enforcement action is high, and the evidentiary bar for demonstrating incompleteness is low.
Confidence: mediumAbsence of any published enforcement action citing ICT third-party register deficiency as a primary finding before end of 2025. Observable leading signal: competent authority inspection letters in Q2-Q3 2025 that specifically cite register scope methodology as a finding requiring remediation.By mid-2026, at least three major cloud providers designated as critical ICT third-party providers will have published amended standard contractual terms for financial entities that include DORA Article 30 provisions, reducing the renegotiation burden for smaller financial entities but creating a two-tier contract structure between entities that negotiated before and after the amendment.
The contractual renegotiation burden is creating visible pressure on the market. Providers with large financial sector customer bases face the same renegotiation demand from hundreds of entities simultaneously. Publishing standardized DORA-compliant terms is the rational response from a provider negotiating capacity standpoint. The risk to financial entities in the first tier is that the standardized terms may not be equivalent to individually negotiated provisions, particularly on audit rights and exit strategy detail.
Confidence: highNo major designated critical ICT provider publishes standardized DORA-compliant contractual terms for financial entities by mid-2026. Observable leading signal: provider communications to financial entity customers in Q3-Q4 2025 referencing DORA contractual updates.
What financial entities say going in, and what the evidence shows
We completed our DORA gap analysis before the January 2025 deadline and remediated the priority findings. We are compliant.
Root cause:The gap analysis assessed documented controls and identified articulated deficiencies against the five DORA pillars. It did not verify that the ICT third-party register was complete against the actual dependency map, that the incident classification process could function accurately within the notification window, or that business continuity test results existed in supervisory-grade documentation. Remediating the findings identified by a gap analysis that was scoped to documented controls does not remediate the gaps the gap analysis could not see.
Our primary cloud provider was designated as a critical ICT third-party provider. That oversight covers our main dependency.
Root cause:ESA designation of a critical provider creates direct supervisory obligations for the provider. It does not modify the financial entity''s own DORA obligations for that dependency. The financial entity must still maintain the provider in its register with a criticality assessment, hold contractual arrangements meeting Article 30 requirements, and include the provider in its ICT risk management framework. Designation adds an additional documentation requirement — demonstrating alignment with the ESA''s oversight findings — rather than reducing existing ones.
We commissioned a red team exercise last year. That satisfies the TLPT requirement.
Root cause:DORA TLPT under Articles 26 and 27 requires an engagement conducted in accordance with the TIBER-EU framework or an equivalent national framework, which mandates a structured threat intelligence phase conducted by an approved provider, scope definition agreed with the competent authority before the engagement begins, testing conducted on production systems, and results shared with the authority. A red team exercise not structured to this process, regardless of technical quality, does not constitute TLPT evidence under DORA. The distinction is process, not technical depth.
What DORA is actually testing and where compliance programs missed it
DORA is the most evidence-intensive financial regulation the EU has produced. The operational resilience testing requirements, the third-party register obligations, and the incident classification and notification process all create ongoing evidence production obligations that run throughout the year, not just at audit time. This is a deliberate regulatory design choice. The European Commission''s intent, visible in the recitals and in the ESA guidance published during the development phase, was to create a regulation that could not be satisfied by a point-in-time compliance exercise.
Most financial entity compliance programs did not internalize that design choice. They ran the DORA program like a framework implementation: gap analysis, remediation plan, evidence production at deadline. That approach produced clean documentation and, for many entities, a genuine improvement in ICT risk management capability. What it did not produce is the ongoing evidence trail that supervisors expect to examine: a third-party register that is demonstrably current, an incident classification record that shows the process functioning correctly across the past twelve months, and a TLPT cycle that follows the process framework rather than approximating it with an equivalent engagement.
My position is that the compliance industry undersold the operational discipline DORA requires and oversold the documentation project. Entities that now believe they are DORA compliant because they produced a register and a gap analysis report in 2024 will find that supervisory inspection in 2025 and 2026 tests something different.
Counterargument
The reasonable counterargument is that supervisory expectations for first-wave DORA inspections will be calibrated to the practical constraints financial entities faced in building compliance programs against regulations that were finalized late and had limited implementing guidance available. If supervisors applied a strict evidentiary standard from day one, the enforcement burden on the sector would be disproportionate to the time available to build capability. This is a legitimate expectation. The risk is that entities relying on supervisory leniency in the first wave make no progress toward the operational discipline the regulation requires, and face the same gaps in the second wave with less justification for them.
One concrete step before the end of this week
Pull your ICT third-party register and identify how it was constructed: which data sources were used to populate it and which were not. Specifically, determine whether providers onboarded by business units outside central IT procurement are included, whether legacy providers with contracts predating your DORA program are included, and whether the subcontractors of your top five ICT dependencies are assessed even if not individually listed.
If the answer to any of those three questions is no, you have a register gap that will be visible in a supervisory inspection and is cheaper to address now than to explain later.
Further Reading
Gap Analysis
framework gap analysisVulnerability Assessment
vulnerability assessmentEMEA compliance frameworks: the complete guide to GDPR, NIS2, DORA, and 40+ regional mandates
EU DORA compliance for financial entities under the Digital Operational Resilience ActNational Vulnerability Database NIST
NIST National Vulnerability DatabaseOWASP Web Security Testing Guide
OWASP security testing guideThird-Party Risk Management
third-party risk management
Frequently Asked Questions
What must be included in a DORA ICT third-party register and how should it be constructed?
DORA Article 28 requires the register to cover all ICT third-party arrangements, including criticality assessments, contractual status, and concentration risk indicators. The register must be updated at least annually and when significant changes occur. Construction methodology matters: registers built from central IT procurement records typically miss providers onboarded by business units, legacy providers with pre-DORA contracts, and subcontractors of primary providers. Supervisors treat register incompleteness as a primary Article 28 deficiency, not a documentation gap.
What is the difference between TLPT under DORA and a standard penetration test?
DORA TLPT under Articles 26 and 27 follows the TIBER-EU framework or equivalent national framework, which requires a structured threat intelligence phase conducted by an approved provider, scope definition agreed with the competent authority before the engagement begins, testing against production systems, and results shared with the competent authority. A standard penetration test, regardless of technical quality, is not TLPT evidence under DORA. The distinction is process structure, not technical depth. Entities that submitted penetration test reports as TLPT evidence have received supervisory findings requiring the engagement to be repeated.
How does DORA major incident classification work and what are the notification timelines?
DORA Article 18 requires financial entities to classify ICT incidents against criteria in the EBA regulatory technical standards, including number of clients affected, duration, geographic spread, and economic impact. Major incidents require initial notification to the competent authority within 4 hours of classification, an intermediate report within 72 hours, and a final report within one month. Applying classification criteria accurately requires real-time correlation between affected systems and client dependencies, which most entities' monitoring infrastructure does not support.
What contractual provisions does DORA Article 30 require with ICT third-party providers?
DORA Article 30 requires contractual arrangements to include: a clear description of services and service level commitments covering resilience and availability; audit rights including on-site access for the financial entity and its competent authority; exit strategy provisions with documented migration assistance; provisions ensuring the entity is informed of sub-outsourcing arrangements affecting critical functions; and cooperation obligations with supervisory inspections. Major cloud and SaaS providers have resisted audit rights requiring on-site access and exit strategy documentation requirements, making renegotiation timelines longer than most compliance programs projected.
Does relying on an ESA-designated critical ICT provider reduce a financial entity's DORA compliance obligations?
No. ESA designation of a critical ICT third-party provider creates direct supervisory obligations for the provider under DORA Chapter V. It does not modify the financial entity's own obligations under Chapters II, III, and IV. The financial entity must still maintain the provider in its ICT register with a current criticality assessment, hold contractual arrangements meeting Article 30 requirements, and include the provider in its ICT risk management framework. Designation adds an obligation to align entity assessments with ESA oversight findings rather than substituting for those assessments.
What does DORA proportionality mean for smaller financial entities?
DORA Article 4 allows competent authorities to apply requirements proportionately based on entity size, nature, and complexity. In practice, proportionality reduces the TLPT obligation for entities below the significant institution threshold and allows flexibility in ICT risk management framework design. It does not reduce the core evidence obligations that apply to all entities: the ICT third-party register must be complete regardless of entity size, incident classification and notification requirements apply in full, and Article 30 contractual requirements apply to all ICT third-party arrangements supporting critical or important functions.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.