DORA third-party risk explained: what changes for your ICT vendors

Your vendor isn't regulated. Your contract with them is.

Ask a SaaS vendor whether DORA applies to them and you'll often get a confident no. They aren't a bank. They don't hold a financial licence. Strictly speaking, they're right: the Digital Operational Resilience Act, Regulation (EU) 2022/2554, regulates financial entities, not their suppliers.

But since 17 January 2025, every bank, insurer, payment institution and investment firm in the EU has had to prove that its ICT vendors meet a specific set of obligations. It proves that through contracts, a register and evidence. So the vendor ends up carrying a large share of the load anyway, one step removed.

This post walks through what DORA actually asks for on the third-party side, where the financial entity's obligations end and the vendor's begin, and which details tend to catch both sides off guard.

Who counts as an ICT third-party service provider?

The definition is broader than most people expect. Article 3(19) defines an ICT third-party service provider simply as an undertaking providing ICT services. Article 3(21) then defines ICT services as digital and data services provided through ICT systems to one or more users on an ongoing basis, including hardware as a service and technical support delivered through software or firmware updates.

That pulls in far more than cloud hosting. A few examples that regularly surprise people:

• A SaaS HR platform that stores employee data
• An analytics tool that receives a transaction export every night
• A managed security provider running your security operations centre
• An AI writing assistant connected to your document store
• A market data vendor whose feed powers a pricing model

So is your vendor in scope?

The test isn't whether the vendor sounds technical. It's whether the service is digital, ongoing and delivered through ICT systems. If it is, the arrangement belongs in the register of information, whatever the vendor's size.

Which financial entities are in scope?

Article 2(1) lists 20 types of financial entity, from credit institutions and payment institutions to crypto-asset service providers, insurers, central securities depositories and crowdfunding platforms. Article 4 applies proportionality throughout, and microenterprises and some smaller firms get a simplified framework, so a five-person investment firm isn't expected to run the same programme as a systemic bank.

If you're a vendor, the useful question isn't which category your customer belongs to. It's whether any of your customers is one of those 20 types. If even one is, expect DORA clauses at your next renewal.

What does Article 28 require from the financial entity?

Article 28 is the core of the third-party pillar, and its first principle matters most. Under Article 28(1), the financial entity remains fully responsible for compliance when it uses a third party. You can't outsource DORA to a vendor.

From there, the article builds a lifecycle:

• A third-party risk strategy and policy, reviewed regularly (Article 28(2))
• A register of information covering every contractual arrangement for ICT services (Article 28(3))
• A pre-contract assessment: does the service support a critical or important function, what risks does it bring, including concentration risk, and has due diligence been done (Article 28(4))
• Contracting only with providers that meet appropriate information security standards (Article 28(5))
• Audits and inspections at a frequency driven by risk (Article 28(6))
• Termination rights for specific triggers, such as a significant breach or weaknesses in the provider's ICT risk management (Article 28(7))
• Documented exit strategies for services supporting critical or important functions (Article 28(8))

Why DORA has no standard questionnaire

Notice what's missing: a questionnaire. DORA doesn't prescribe one. It expects the financial entity to show, with evidence, that each of these steps happened. That's a much higher bar than a completed spreadsheet.

Critical or important functions: the label that changes everything

Most of DORA's heavier obligations attach to ICT services that support a critical or important function. Article 3(22) defines that as a function whose disruption would materially impair the entity's financial performance, the soundness or continuity of its services, or its ability to keep meeting the conditions of its authorisation.

Why does one label matter so much? Because it decides how many contract provisions are mandatory (15 instead of 9), whether an exit strategy must exist, and how closely your subcontractors are examined.

Here's the part vendors rarely hear: the financial entity makes this call, and it doesn't always say so. If your customer's new contract suddenly asks you to take part in threat-led penetration testing and grants unrestricted audit rights, you've almost certainly been classified as supporting a critical function.

What Article 30 puts into the contract

Article 30 turns that lifecycle into contract text. Article 30(1) requires the rights and obligations to be set out in writing, in one document available on paper or in a downloadable, durable format. Every ICT contract then needs nine provisions under Article 30(2):

• A complete description of the services, including whether subcontracting is allowed and on what conditions
• Where services are provided and where data is processed and stored, with advance notice of any change
• Protection of the availability, authenticity, integrity and confidentiality of data, including personal data
• Access, recovery and return of data if the provider becomes insolvent, is wound down, discontinues the service or the contract ends
• Service level descriptions, including updates
• Assistance during ICT incidents at no extra cost, or at a cost fixed in advance
• Full cooperation with competent and resolution authorities
• Termination rights and minimum notice periods
• Participation in the financial entity's ICT security awareness programmes and resilience training

Six more for critical or important functions

For services supporting critical or important functions, Article 30(3) adds six more: precise quantitative and qualitative service levels, notice and reporting duties, implemented and tested business contingency plans, participation in threat-led penetration testing, unrestricted access, inspection and audit rights, and an exit strategy with a mandatory transition period. We go through all 15, with the evidence that proves each one, in our DORA Article 30 checklist.

The register of information: where gaps become visible

The register of information is where DORA turns third-party risk into data. Every contractual arrangement for ICT services goes in, along with the provider, the functions it supports, the subcontractors involved and where data sits.

Supervisors now collect it every year. For the 2026 cycle, the reference date was 31 December 2025, and national authorities ran submission windows between February and March 2026 with deadlines that varied by country: De Nederlandsche Bank asked for 20 March, Luxembourg's CSSF for 31 March. The files go in as plain CSV inside a zip with a prescribed structure.

Why should a vendor care about a regulator's spreadsheet? Because it asks for things only the vendor knows: your legal entity identifier, your subcontractors for the service, the countries where you process data. When a customer's DORA team emails you in January asking for your LEI and your subcontractor chain, this is why.

Subcontractors and the fourth-party problem

Article 29 asks financial entities to assess concentration risk, including long or complex subcontracting chains. The Commission's subcontracting standard, Delegated Regulation (EU) 2025/532, spells out what has to be assessed when an ICT service supporting a critical or important function relies on subcontractors: the risks they add, the provider's ability to oversee them, and the conditions under which subcontracting is allowed.

The final text is softer than the draft. The Commission removed a proposed article that would have required contracts to cover monitoring of the entire subcontracting chain. The due diligence duty remains, though. If your vendor runs on a hyperscaler and uses a third-party model provider for an AI feature, those dependencies still need to be visible to you.

And the hyperscalers themselves? On 18 November 2025 the European Supervisory Authorities designated the first 19 critical ICT third-party providers, including AWS, Microsoft, Google Cloud, Oracle, SAP and Bloomberg. They're now overseen directly at EU level. That doesn't remove the financial entity's own duties for those services. It adds a second layer of supervision on top.

What vendors actually get asked for

Put all of this together and a pattern emerges. A DORA-regulated customer will typically ask an ICT vendor for:

• A contract addendum covering the Article 30 provisions
• Evidence of information security standards: a SOC 2 Type II report, an ISO 27001 certificate with its Statement of Applicability, or equivalent
• Data locations and a current subcontractor or sub-processor list
• Incident notification commitments that let the customer meet its own reporting deadlines
• Business continuity and disaster recovery plans, with recent test evidence
• Exit and transition support terms
• A legal entity identifier and corporate structure details for the register

Why the vendor's incident window matters

The incident point deserves a closer look. Under DORA's incident reporting standards, a financial entity must send an initial notification for a major ICT incident within 4 hours of classifying it as major, and no later than 24 hours after becoming aware of it. If the vendor's contract allows 72 hours to tell the customer, the customer can be out of time before it knows the incident exists.

Is a questionnaire enough to prove any of this?

No. A questionnaire records what a vendor says. DORA asks what you can prove. When a supervisor reviews a third-party programme, the questions are concrete: is the clause in the signed contract, does the SOC 2 report cover the service you actually buy, did the continuity test happen in the last year?

That's why DORA programmes are moving from questionnaire-led reviews to document-led ones: read the contract, the DPA, the SOC 2 report and the continuity plan, and tie each requirement to the clause or page that satisfies it. Done by hand across hundreds of vendors, it's slow. That's the problem ProcureCortex was built to solve.

Where to start this quarter

If you're on the financial entity side, here's a practical order of work for the rest of 2026:

• Re-check which vendors support critical or important functions. Classifications made under deadline pressure in 2024 are often wrong.
• Pull the signed contracts for those vendors and check each Article 30 provision against the actual text, not the negotiation tracker.
• Compare every vendor's incident notification window with your 4-hour and 24-hour reporting clock.
• Ask critical vendors for current subcontractor lists and data locations, and compare them with your register.
• Confirm an exit strategy exists for each critical service, and note when it was last reviewed.
• Start collecting register data for the next annual cycle now, not in January.

If you're the vendor

If you're a vendor selling into financial services, flip the list: have your Article 30 addendum, evidence pack and subcontractor list ready before the customer asks. Procurement reviews go noticeably faster when the answers arrive with the first request.

Sources

• Regulation (EU) 2022/2554 (DORA), full text on EUR-Lex: https://eur-lex.europa.eu/eli/reg/2022/2554/oj
• Commission Delegated Regulation (EU) 2025/532 on subcontracting ICT services supporting critical or important functions: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202500532
• European Commission, DORA implementing and delegated acts, including incident reporting standards: https://finance.ec.europa.eu/regulation-and-supervision/financial-services-legislation/implementing-and-delegated-acts/digital-operational-resilience-regulation_en
• European Supervisory Authorities, designation of critical ICT third-party providers (18 November 2025): https://www.eba.europa.eu/publications-and-media/press-releases/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital
• De Nederlandsche Bank, reporting DORA registers of information in March 2026: https://www.dnb.nl/en/sector-news/supervision-2026/dora-reporting-dora-registers-of-information-in-march-2026/
• CSSF, register of information submission timeframe 2026: https://www.cssf.lu/en/2026/02/dora-submission-timeframe-for-register-of-information-edesk-portal-open-as-of-11-february-2026/
• Herbert Smith Freehills Kramer, Commission adopts revised DORA subcontracting RTS: https://www.hsfkramer.com/notes/tmt/2025-posts/european-commission-adopts-revised-dora-subcontracting-rts-a-partial-retreat-on-monitoring-sub-contractors