A digital lender doesn’t run on its own infrastructure alone. Cloud hosting, credit risk modelling engines, and credit origination systems are typically built on third-party providers, and the EU’s Digital Operational Resilience Act (DORA), which has applied since 17 January 2025, treats that dependence as a regulated risk rather than a vendor-management footnote.
Why DORA targets vendor contracts specifically
Before DORA, oversight of ICT vendors was a patchwork of regional and sector guidelines without a single legally binding standard across the EU. DORA replaces that patchwork with one harmonised framework and puts two principles at its centre:
- Internal responsibility is absolute. The financial entity, not the vendor, remains fully responsible for the resilience of any outsourced function. If a vendor fails, the entity bears the consequences regardless of the vendor’s own compliance status.
- External oversight now exists for the largest providers. DORA’s Oversight Framework for Critical ICT Third-Party Providers (CTPPs) gives the European Supervisory Authorities (ESAs) the power to directly monitor and issue binding recommendations to the most systemically important vendors, including major cloud providers. That oversight supplements but doesn’t replace the financial entity’s own responsibility.
Article 30: what every vendor contract must now include
Article 30 sets out mandatory contractual provisions for any arrangement with an ICT third-party provider. Where that arrangement supports a critical or important function, such as core banking systems or loan servicing software, the requirements tighten further.
| Requirement | What it covers |
|---|---|
| Full service description | Scope, performance targets, and the specific country or region where data is processed and stored |
| Audit and inspection rights | Unrestricted rights of access, inspection, and audit for the financial entity; if impractical (for example with a hyperscale provider), an alternative assurance arrangement must be agreed and documented |
| Incident assistance | The provider commits in advance to assisting during an ICT incident, with costs agreed ex-ante rather than negotiated mid-crisis |
| Business continuity and exit strategy | A documented contingency plan and exit strategy for critical functions, guaranteeing data access and return in a usable format if the contract ends or the vendor fails |
| Cooperation with authorities | The provider agrees to cooperate with the financial entity’s competent and resolution authorities |
For lenders whose legacy contracts were never written with this level of audit access or exit planning, bringing every relevant contract up to these standards has meant renegotiating or, in some cases, replacing long-standing vendor relationships.
The Register of Information
DORA also requires financial entities to maintain a detailed Register of Information covering all ICT third-party arrangements, kept current and submitted to the relevant competent authority. It serves two functions:
- Internal visibility. It gives an entity’s own management and board a current view of every ICT dependency, its risk profile, and where exposure is concentrated.
- Systemic risk mapping. Competent authorities aggregate Registers across the sector to identify concentration risk: if too many entities rely on the same provider for the same critical function, that provider’s failure becomes a sector-wide problem rather than a single company’s.
The first Register of Information submissions in 2025 gave the ESAs the data behind the first wave of CTPP designations. CTPP oversight doesn’t reduce an individual entity’s own monitoring obligations; that burden continues regardless of which providers are under direct ESA supervision.
What this changes in practice
A DORA-aligned approach to vendor risk affects more than compliance paperwork:
- Resilience claims need evidence. Tested vendor failover and a documented exit strategy let a lender show investors, partners, and borrowers that services continue functioning through a disruption, not just assert that they will.
- Negotiating leverage shifts. Article 30’s requirements are not optional extras a lender is asking for; they are what the regulation requires, which changes the starting point of a vendor negotiation.
- New vendor relationships start from the same bar. Building DORA’s requirements into vendor due diligence from the outset means a new AI, credit origination, or infrastructure partner is assessed for resilience and compliance before the contract is signed, not after.
Contract remediation against Article 30 is not a one-time project. It is now a standing part of how a lender manages every ICT vendor relationship that touches a critical or important function.