DORA third-party risk requirements now sit at the centre of every EU financial entity's ICT vendor programme, reshaping how banks, insurers, and investment firms document, monitor, and exit critical technology relationships. Since the regulation's January 2025 application date, risk and compliance teams have moved from interpreting the text to operationalising it — building registers, renegotiating contracts, and preparing for the possibility that a core vendor gets designated for direct regulatory oversight.
Here is what DORA actually requires, and how mature third-party risk management (TPRM) programmes are meeting it.
What Is DORA Third-Party Risk Management?
DORA third-party risk management requires financial entities operating in the EU to identify, contractually govern, and continuously monitor every ICT service provider that supports a critical or important function. The obligation sits in Chapter V of Regulation (EU) 2022/2554 and applies broadly — banks, insurers, investment firms, payment institutions, and most other regulated financial entities fall within scope, regardless of size. Unlike earlier outsourcing guidance that treated vendor risk as a periodic questionnaire exercise, DORA demands an ongoing, risk-based classification of business functions, a documented pre-contractual due diligence process, and a mapped view of subcontracting chains that can run several layers deep before a service ever touches the entity's own systems.
For third-party risk teams, the practical shift is significant. Vendor risk can no longer live in a spreadsheet that gets updated once a year before an audit. It has to be a structured, queryable system of record that ties every contract to a criticality rating, a named function owner, and evidence of ongoing monitoring — the same discipline that continuous monitoring programmes outside the EU are converging toward under NIS2, OCC guidance, and similar regimes.
How Does the DORA Register of Information Work?
The register of information is a standardised inventory that financial entities must maintain of all contractual arrangements with ICT third-party providers, built around templates published by the European Supervisory Authorities. Entities must submit this register to their national competent authority at least annually, and regulators use the aggregated data across the sector to identify which providers are systemically important enough to warrant direct oversight.
Contract & Provider Identifiers
Legal Entity Identifiers (LEIs) and contracting-entity details for every ICT relationship on the register.
Criticality Classification
Each supported business function is rated critical, important, or neither, driving how closely the contract is governed.
Subcontracting Chain Mapping
Full visibility into fourth-party dependencies, not just the entity the financial firm contracts with directly.
Data Location & Processing Details
Where data is stored, processed, and transferred across the provider's own infrastructure and subcontractors.
Termination & Audit Rights
The contractual notice periods, audit access, and exit provisions written into the agreement.
Most legacy TPRM programmes struggle here not because the concept is new, but because the data has never lived in one place with a consistent taxonomy. Building the register from scratch, reconciling it against actual contracts, and keeping it current as vendors are added or renewed is now a standing operational requirement, not a one-time compliance project.
See how continuous monitoring and a structured vendor register turn DORA compliance from an annual scramble into a standing operational discipline.
See the Governance FrameworkWhat Oversight Applies to Critical ICT Third-Party Providers?
Providers designated as Critical ICT Third-Party Providers, typically large cloud, data centre, and infrastructure vendors used across many financial entities, are placed under direct oversight by a Lead Overseer appointed from among the European Supervisory Authorities rather than left solely to individual customer due diligence. The Lead Overseer can request information, run investigations and inspections, and issue recommendations the provider is expected to address. Designation does not transfer accountability, however — each financial entity remains fully responsible for its own risk management, contractual controls, and continuity planning even when its provider is subject to this regulatory layer.
How Should Financial Entities Build DORA-Compliant Exit Strategies?
A DORA-compliant exit strategy is a documented, testable plan for transitioning away from an ICT third-party provider that supports a critical or important function, covering the transition period, data portability, and continuity arrangements if the provider fails, is acquired, or becomes non-compliant. Contracts need explicit provisions for orderly termination, data return or deletion, cooperation during migration, and restrictions on further subcontracting without notice. Entities are expected to identify realistic alternatives in advance — a secondary vendor, an in-house fallback, or a phased migration path — rather than discovering during a crisis that no viable exit exists.
Just as disaster recovery plans are tested rather than filed away, exit strategies for critical providers should be exercised periodically. Walking through the transition plan on paper, confirming data export formats still work, and validating that alternative providers remain viable are what separate a real exit strategy from a contractual formality.
Crest connects verified vendor data, continuous monitoring, and structured documentation into one platform — so critical-provider oversight and exit readiness stay audit-ready by default.
How Does DORA Connect to Incident Reporting and Resilience Testing?
DORA extends major ICT-incident reporting and, for significant entities, threat-led penetration testing (TLPT) obligations to the third-party providers supporting critical functions, which means vendor cooperation clauses are now a regulatory requirement rather than a negotiating nicety. Financial entities must be able to report qualifying incidents to regulators within tight timeframes, which is only possible if contracts obligate providers to notify their customers quickly and share the technical detail needed to assess impact. Where TLPT applies, in-scope providers must participate in adversarial testing exercises, adding a layer of operational coordination most vendor contracts were never written to support — a demand that echoes the broader shift toward operational resilience expectations regulators are setting globally, and one that overlaps closely with obligations already familiar from NIS2 third-party risk management.
Key Takeaways
- DORA applies to nearly all EU financial entities and requires a documented register of information for every ICT third-party contract.
- Critical ICT Third-Party Providers face direct oversight from a Lead Overseer, but accountability for risk stays with the financial entity.
- Exit strategies must be documented, tested, and backed by realistic alternative providers, not just a termination clause.
- Incident reporting and resilience testing obligations now extend contractually to third-party providers supporting critical functions.
Frequently Asked Questions
Yes. DORA applies based on whether a vendor provides ICT services to an EU financial entity supporting a critical or important function, not on where the vendor is headquartered. Non-EU cloud, software, and infrastructure providers serving EU banks or insurers fall within scope of the same contractual and due diligence requirements.
Any provider of digital or data services delivered through ICT systems, including cloud computing, software, data centre, network, and data analytics providers that support a financial entity's operations. The classification hinges on the function the service supports, not the vendor's industry label.
The register should be kept current internally as contracts are signed, renewed, or terminated, and financial entities must submit it to their national competent authority at least once a year, or on request during a supervisory review.
The vendor becomes subject to direct oversight by a Lead Overseer drawn from the European Supervisory Authorities, who can request information, conduct inspections, and issue recommendations. The financial entities using that vendor remain fully responsible for their own risk management regardless of the designation.
DORA is sector-specific to financial services and is significantly more prescriptive about contractual terms, the register of information, and direct oversight of critical providers, while NIS2 sets broader baseline cybersecurity and incident-reporting requirements across critical infrastructure sectors. Financial entities in the EU typically need to satisfy both, since the two regimes overlap but aren't interchangeable.
DORA includes a simplified ICT risk management framework for certain small and non-interconnected investment firms and other qualifying smaller entities, but the third-party risk register and contractual requirements still apply in a proportionate form. Size reduces the burden; it doesn't remove the obligation.
Conclusion
DORA third-party risk management turns what used to be a compliance checkbox into an operating discipline: a live register of every ICT relationship, documented oversight of critical providers, tested exit plans, and contracts written to support incident reporting and resilience testing on short notice. None of this is achievable with static spreadsheets and annual review cycles — it requires a system that keeps criticality ratings, subcontracting chains, and contractual obligations current as vendors change.
Crest brings that discipline to third-party risk management with continuous monitoring, structured due diligence, and audit-ready documentation built for exactly this kind of regulatory scrutiny. If your team is still reconciling DORA's register of information by hand, it's worth seeing what a purpose-built TPRM platform can take off your plate.