For years, the EBA outsourcing guidelines told financial institutions how third-party risk management should look. DORA changed the game: it made those expectations legally binding, directly enforceable, and non-negotiable — for financial entities of every size, and for the ICT providers that supply them.
DORA did not invent third-party risk management for financial institutions. It replaced a supervisory expectations regime with a binding legal one. Understanding the difference explains why firms that thought they were compliant under EBA guidelines are now finding gaps.
DORA creates a cascade of obligations from regulated financial entities through their ICT providers. Understanding where your organisation sits in this chain determines what you must do — and what your customers will ask for.
Banks, payment institutions, investment firms, insurers, crypto asset providers authorised in the EU/EEA. Direct Article 28 obligations apply: maintain ICT register, conduct due diligence, enforce Article 30 contract terms, conduct periodic re-assessments, produce evidence to NCAs on request.
Article 28 — direct legal obligationCloud providers, SaaS vendors, core banking system suppliers, payment processors, data analytics providers, managed IT services. No direct DORA obligation — but financial entity clients must include Article 30 terms (audit rights, exit rights, incident notification, data location, sub-outsourcing disclosure) in every ICT supplier contract. If you cannot agree to these terms, regulated financial entity clients cannot use your services.
Article 30 — contractual obligation via clientIf you are an ICT provider with your own sub-contractors (cloud infrastructure, sub-processors, specialist service providers), your financial entity clients must be notified of significant sub-outsourcing arrangements under Article 30(3). Your customers need to know who their data is flowing through — and must approve material changes. Document your sub-contractor stack and notify clients of changes before they happen.
Article 30(3) — sub-outsourcing disclosureThe largest and most systemically important ICT providers may be designated as CTPPs by the ESA Joint Committee under Article 31. Designated CTPPs are subject to direct Lead Overseer supervision — on-site inspections, oversight fees, binding recommendations. Most providers will not be designated. But any provider to EU financial entities should understand the designation criteria and track whether they approach the systemic importance thresholds.
Article 31 — direct ESA oversight if designatedDORA Article 31 created a direct oversight regime for the largest ICT providers to EU financial institutions. Even providers not designated as CTPPs need to understand the regime — because their regulated clients now have heightened scrutiny of any vendor approaching systemic importance.
The ESA Joint Committee designates CTPPs based on: systemic impact if the provider failed or was disrupted across multiple financial entities; degree of substitutability (how hard to replace); and the nature, scale, and complexity of ICT dependencies. The ESA published the first CTPP register in 2025 — it covers major cloud providers and core financial infrastructure vendors. Most SMB ICT providers will not be designated.
Designated CTPPs are assigned a Lead Overseer (EBA for banking/payments, ESMA for markets, EIOPA for insurance). The Lead Overseer can conduct general investigations, on-site inspections, request information, and issue binding recommendations. CTPPs pay annual oversight fees. Failure to comply with Lead Overseer recommendations can result in periodic penalty payments of up to 1% of average daily worldwide turnover.
Even without CTPP designation, every ICT provider to DORA-regulated firms will face increased due diligence requests from their financial entity clients. The Article 28 obligation on financial entities to assess, document, and re-assess their ICT providers flows to every provider in scope — not just CTPPs. Be ready to answer DORA questionnaires, provide security certifications, disclose sub-contractors, and agree to Article 30 contract terms.
If you supply services to any bank, payment institution, investment firm, or insurer in the EU, prepare to receive DORA due diligence requests. Here is what they need from you — and why.
DORA Article 28(4)(f) requires financial entities to verify their ICT providers have resilience arrangements. Your clients need to see a documented BCP/DRP that covers the services you provide to them: RTO/RPO targets, backup procedures, alternative processing sites, and how you would notify them of a major incident. A general “we have a BCP” statement is not sufficient — they need the document or a summary specific to the services in scope.
Financial entities must assess the security posture of their ICT providers under Article 28.3. The most efficient way to satisfy this is a current third-party certification: ISO 27001 (international standard), SOC2 Type II (common in US/global SaaS), or sector equivalents. Financial entity clients will track your certification expiry and prompt renewal. Without a recognised certification, you will face more intensive questionnaire-based due diligence on every renewal cycle.
Article 30(2)(c) requires contracts to specify where data is located and processed, including all jurisdictions. Your clients need to know: where is data stored (primary and DR), which jurisdictions are involved, and what sub-contractors (cloud infrastructure providers, sub-processors) handle data as part of delivering your service. They must include this information in their own DORA ICT register. Keep your sub-contractor list current and notify clients before making material changes.
Article 30(2)(g) requires contracts to include incident reporting obligations. Financial entities need to know: what counts as a notifiable incident, how quickly you will notify them (typically 24–72 hours for major incidents), what information will be included in the initial notification, and how you will provide updates. This is not just a contractual requirement — your clients face their own DORA incident reporting obligations to their NCAs, and your notification timeline directly affects their compliance.
Your clients must include specific DORA Article 30 provisions in every ICT supplier contract: audit and inspection rights, exit and portability provisions (including minimum notice periods and transition assistance), data processing location clauses, sub-outsourcing notification requirements, and service level definitions with continuity obligations. If your standard contract terms conflict with Article 30 requirements — for example, if you limit audit rights or exclude exit provisions — financial entity clients cannot sign them as-is. Review your standard terms for DORA compatibility.
A financial entity operating in the EU may be subject to all three simultaneously. Understanding where they overlap avoids triple compliance effort — one vendor register can satisfy all three if structured correctly.
Applies to: EU/EEA financial entities (banks, payment institutions, investment firms, insurers, CASPs). Focus: ICT resilience, third-party operational risk, business continuity. Requires: ICT third-party register, due diligence, contractual provisions, periodic reassessment, exit strategies.
Financial sector onlyApplies to: any organisation processing personal data of EU/UK residents (universal scope). Focus: data protection, processor accountability, data subject rights. Requires: DPA with every processor, sub-processor register (ROPA), third-country transfer safeguards, breach notification chain within 72 hours.
Universal — any sectorApplies to: medium/large organisations in 18 critical sectors including banking and financial market infrastructure (overlaps with DORA for financial entities). Focus: cybersecurity and supply chain resilience. Requires: supplier security assessment, documented supply chain risk management, national authority reporting for significant incidents.
18 critical sectorsOne register, three frameworks: A single vendor register with DORA criticality classification, GDPR processor status, and NIS2 supply chain tier — plus shared fields (vendor contact, services, data location, certifications, assessment history) — avoids triple data entry. VendorAuditly structures exactly this, exporting evidence mapped to whichever framework an auditor or regulator requests.
Structured ICT register meeting EBA ITS field requirements, DORA due diligence questionnaires, Article 30 contract tracking, and one-click evidence export for NCA requests.
Start free — no credit card required →DORA · GDPR · NIS2 · ISO 27001 evidence export · Same-day setup