EU DORA ICT Third-Party Provider Register 2026: Contractual Requirements and Compliance Checklist for SaaS Developers

DORA — the Digital Operational Resilience Act — entered full application on 17 January 2025. Most coverage focuses on the financial entities it regulates: banks, insurers, investment firms, payment processors. What receives less attention is the downstream effect on every SaaS vendor that serves those entities.

If your product is used by a single regulated financial institution in the EU, you will appear in their ICT Third-Party Provider Register. They are legally required to maintain it. And the contractual requirements that feed that register will shape what your MSA, DPA, and service terms need to say.

This guide explains the register itself, what it contains, what DORA Art. 28-30 require in contracts, what Critical Third-Party Provider (CTPP) designation means for large infrastructure vendors, and what a SaaS developer needs to prepare before their first serious financial-sector sales conversation.

What DORA Actually Regulates

DORA Regulation (EU) 2022/2554 applies to approximately 22,000 financial entities in the EU. The full list is in Article 2(1):

• Credit institutions (banks)
• Payment institutions and e-money institutions
• Investment firms and fund managers (UCITS, AIFMs)
• Crypto-asset service providers (CASPs) under MiCA
• Insurance and reinsurance undertakings
• Central securities depositories and counterparties
• Trading venues and data reporting services

Each of these entities is required to manage ICT third-party risk under a detailed framework. The framework's key tool is the register of information — a structured inventory of every ICT service provider the financial entity uses, maintained and submitted to the relevant national competent authority (NCA) and the European Supervisory Authorities (EBA, ESMA, EIOPA).

The ICT Third-Party Provider Register: Article 28(3)

Article 28(3) requires financial entities to maintain "a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers."

This is not optional and not a summary. It is a structured register with mandatory fields specified by the Joint Committee of the ESAs. The ESA Implementing Technical Standards (ITS) on the Register of Information were finalized in early 2024 and define exactly what data points each entry must include.

Mandatory register fields for each ICT third-party arrangement:

Your customers — the financial entities — are responsible for filling this in. But every field they cannot fill in because it is not in your contract, your DPA, or your documentation is a gap that blocks their NCA submission and triggers a remediation request to you.

Criticality Assessment: Which Providers Get Extra Scrutiny

Not all ICT services in the register are treated equally. Financial entities must classify each arrangement as supporting a critical or important function (CIF) or not.

A function is critical or important if its disruption would:

• Materially impair the financial entity's compliance with its regulatory requirements
• Materially impair its financial performance
• Materially impair its ability to provide services to customers

Services that typically qualify as supporting a CIF:

• Cloud infrastructure where production workloads run
• Core banking/insurance/trading platforms
• Authentication and identity providers
• Monitoring and observability for regulated workloads
• Data storage for customer financial records
• API gateways handling payment flows

Services that typically do not:

• Internal productivity tools (email, HR systems)
• Development/staging environments
• Non-production analytics

If your SaaS supports a CIF, the contractual requirements under DORA Article 30 apply in full. If not, a lighter standard applies. In practice, assume that any production infrastructure or data-handling service for a regulated entity will be classified as CIF-supporting — financial entities err on the side of caution to avoid NCA findings.

Article 30: Contractual Arrangements — What Must Be in Your Contract

For ICT services supporting a CIF, DORA Article 30 specifies the minimum content of the contractual arrangement. This is what your financial-sector customers will demand before or shortly after signing.

Article 30(2) minimum clauses:

1. Service Level Description (Art. 30(2)(a))

The contract must include "a clear and complete description of all functions and ICT services to be provided by the ICT third-party service provider."

What this means for your MSA: Vague SaaS agreements like "access to the software-as-a-service platform" are insufficient. You need a specific annex that describes the service components, their availability guarantees, and the functions they perform.

2. Locations (Art. 30(2)(b))

The contract must specify "the locations... where the functions and ICT services are to be provided and where data is to be processed, including the storage location, and a requirement for the ICT third-party service provider to notify the financial entity in advance if it envisages changing such locations."

What this means: You need to contractually commit to specific data processing locations and agree to notify customers before any change — not just update a help center page.

3. Provisions on Availability, Authenticity, Integrity, Confidentiality (Art. 30(2)(c))

The contract must include "provisions on availability, authenticity, integrity and confidentiality in relation to the protection of data, including personal data."

What this means: Your standard DPA is not sufficient on its own. You need explicit contractual security commitments covering each of these four properties, not just GDPR-required processing terms.

4. Access, Inspection, and Audit Rights (Art. 30(2)(d))

This is the clause that SaaS vendors find most difficult. The contract must grant:

• Full cooperation rights: The financial entity, its auditors, and relevant NCAs must be able to perform on-site inspections and audits.
• Pooled audits: The right to participate in pooled audits organized by multiple financial entities jointly.
• Continuous monitoring access: Rights to access documentation, systems, and data necessary for oversight.

What this means in practice: You will receive audit requests from financial sector customers. The DORA framework allows pooled audits — a consortium of your financial customers auditing you together — which is the practical mechanism for SaaS vendors who cannot support 20 individual on-site audits per year.

5. Termination and Exit (Art. 30(2)(f))

The contract must include exit provisions ensuring:

• The financial entity can exit without service degradation for a transition period (typically 6-12 months)
• Data is exportable in a portable format
• The vendor cooperates with the transition to an alternative provider

What this means: Your standard "30 days notice, data exported within 30 days" terms may be insufficient. Financial entities need to demonstrate to their NCA that they have a credible exit plan — which requires your contractual commitment to support it.

6. Subcontracting Chain Transparency (Art. 30(2)(g))

The contract must specify which subcontractors (including cloud infrastructure providers) you use, where they are located, and must require you to notify the financial entity if you add or replace subcontractors.

What this means: Your customers will want a contractual right to object to specific subcontractors, and will require advance notice of any changes.

The CTPP Framework: Critical Third-Party Providers

Above the level of individual financial entity relationships, DORA establishes an EU-level oversight framework for Critical Third-Party Providers (CTPPs). This applies to the largest cloud and infrastructure providers.

Article 31 gives the Joint ESA Committee the power to designate specific ICT third-party providers as critical based on:

• Systemic importance to the financial sector
• Number and types of financial entities relying on the provider
• Degree of substitutability

Designated CTPPs are subject to:

• An Oversight Lead (one of EBA, ESMA, or EIOPA) appointed for EU-level supervision
• Mandatory cooperation with oversight activities
• Right of the Lead Overseer to conduct on-site inspections
• Annual fees to fund oversight costs
• Ability to issue recommendations on measures to address identified risks

Who is likely designated: AWS, Microsoft Azure, Google Cloud, and other major cloud providers used by EU financial entities. These providers are subject to direct regulatory oversight at the EU level — not just through their financial entity customers.

For most SaaS developers: CTPP designation applies to your infrastructure provider (e.g., AWS), not to you directly unless you are operating at a scale where your absence would constitute a systemic risk to EU financial services.

Subcontracting Requirements: Your Infrastructure Provider Chain

Under DORA, your customers must register not just you, but also your material subcontractors. "Material subcontractor" in practice means:

• Your primary cloud infrastructure provider (AWS, Azure, GCP, Hetzner, OVH)
• Any CDN or DNS provider handling traffic for regulated workloads
• Any third-party data processors with access to financial customer data

This creates a chain: your financial entity customer registers you, and must also register your subcontractors in their ICT register. They need this information contractually from you.

Practical implications:

If you run on AWS us-east-1, your customer must include AWS in their register as a subcontractor. Depending on their risk assessment, this may trigger concerns about CLOUD Act exposure for EU financial data — the same concern that drives interest in EU-native infrastructure.

If you run on EU-domiciled infrastructure (Hetzner Germany, OVH France, Scaleway), your customer's register entry for that subcontractor shows no US parent entity, no CLOUD Act exposure, and no jurisdictional risk flag. This is a concrete contractual differentiator.

From a DORA register perspective, ICT_subcontractor_country = DE/FR vs. ICT_subcontractor_country = US + EU Region is a different risk profile in the NCA submission.

DORA-Ready Contract Annex: A Checklist

If you are targeting financial sector customers, prepare a DORA Compliance Annex to your standard MSA. It should cover:

DORA Compliance Annex — [YourProduct] — v1.0

1. SERVICE DESCRIPTION (Art. 30(2)(a))
   □ Named service components with function description
   □ SLA per component (availability, RTO, RPO)
   □ Critical function classification guidance

2. DATA LOCATIONS (Art. 30(2)(b))
   □ Primary processing location: [country, data center operator]
   □ Backup/DR location: [country, data center operator]
   □ Subprocessors and their locations: [list]
   □ Change notification: 30 days advance notice of location changes

3. SECURITY COMMITMENTS (Art. 30(2)(c))
   □ Encryption at rest: AES-256 or equivalent
   □ Encryption in transit: TLS 1.2+ enforced
   □ Access control: RBAC, MFA enforced for admin access
   □ Integrity monitoring: change detection, audit logs retained [X] years
   □ Availability commitment: [X]% uptime SLA with financial remedy

4. AUDIT RIGHTS (Art. 30(2)(d))
   □ Customer right to conduct on-site audit (annual, 30 days notice)
   □ Participation in pooled audits
   □ Provision of third-party audit reports (SOC 2 Type II, ISO 27001)
   □ NCA/ESA inspection cooperation

5. INCIDENT NOTIFICATION (Art. 30(2)(e))
   □ Major incident notification: within [X] hours of detection
   □ Incident classification aligned to DORA RTS on major incident reporting
   □ Root cause analysis delivery: within [X] business days

6. EXIT AND PORTABILITY (Art. 30(2)(f))
   □ Exit notice period: [X] months
   □ Transition support period: minimum 6 months post-termination
   □ Data export format: [standard format, e.g., CSV, JSON, SQL dump]
   □ Data export delivery: within [X] days of request
   □ Data deletion certification: within [X] days of successful export

7. SUBCONTRACTING (Art. 30(2)(g))
   □ Current material subcontractors: [list with country]
   □ Change notification: 30 days advance notice
   □ Customer right to object: [procedure]

TypeScript: Building a DORA Register Entry Generator

Financial entity customers will need to populate their ICT register with data from you. Providing a structured data export accelerates their compliance process and removes a friction point from the sales cycle.

interface DORATpspEntry {
  // Provider identification (ESA ITS fields)
  providerLegalName: string;
  providerLEI: string | null; // Legal Entity Identifier if applicable
  providerCountryHQ: string; // ISO 3166-1 alpha-2
  providerParentGroup: string | null;

  // Service classification
  ictServiceType: "cloud_infrastructure" | "saas" | "paas" | "security" | "data_analytics" | "other";
  functionSupported: string;
  criticalImportantFunction: boolean;

  // Contractual terms
  contractStartDate: string; // ISO 8601
  contractEndDate: string | null;
  noticePeriodDays: number;
  governingLaw: string; // e.g., "DE" for German law
  jurisdiction: string;

  // Subcontracting
  subcontractorsUsed: boolean;
  subcontractors: Array<{
    name: string;
    country: string;
    serviceType: string;
  }>;

  // Data locations
  dataStorageCountry: string;
  dataProcessingCountry: string;
  dataBackupCountry: string;

  // Operational resilience
  rto_hours: number; // Recovery Time Objective
  rpo_hours: number; // Recovery Point Objective
  availabilitySLA: number; // percentage, e.g., 99.9
}

// Generate DORA-compliant register entry for your SaaS
function generateDORAEntry(
  customerContractDate: string,
  contractEndDate: string | null = null
): DORATpspEntry {
  return {
    providerLegalName: "YourCompany GmbH",
    providerLEI: null, // Register if you have one
    providerCountryHQ: "DE",
    providerParentGroup: null, // null if no parent

    ictServiceType: "saas",
    functionSupported: "Cloud-native compliance monitoring and reporting platform",
    criticalImportantFunction: true, // Conservative default for financial customers

    contractStartDate: customerContractDate,
    contractEndDate: contractEndDate,
    noticePeriodDays: 90,
    governingLaw: "DE",
    jurisdiction: "München",

    subcontractorsUsed: true,
    subcontractors: [
      {
        name: "Hetzner Online GmbH",
        country: "DE",
        serviceType: "cloud_infrastructure",
      },
      {
        name: "Cloudflare Netherlands B.V.",
        country: "NL",
        serviceType: "cdn_dns",
      },
    ],

    dataStorageCountry: "DE",
    dataProcessingCountry: "DE",
    dataBackupCountry: "FI", // Helsinki DR site

    rto_hours: 4,
    rpo_hours: 1,
    availabilitySLA: 99.9,
  };
}

// Validate register entry completeness
function validateDORAEntry(entry: DORATpspEntry): {
  valid: boolean;
  gaps: string[];
} {
  const gaps: string[] = [];

  if (!entry.providerLegalName) gaps.push("providerLegalName required");
  if (!entry.providerCountryHQ) gaps.push("providerCountryHQ required");
  if (!entry.dataStorageCountry) gaps.push("dataStorageCountry required");
  if (!entry.dataProcessingCountry) gaps.push("dataProcessingCountry required");
  if (!entry.dataBackupCountry) gaps.push("dataBackupCountry required");
  if (entry.subcontractorsUsed && entry.subcontractors.length === 0) {
    gaps.push("subcontractors list required when subcontractorsUsed=true");
  }
  if (!entry.contractStartDate) gaps.push("contractStartDate required");
  if (!entry.noticePeriodDays) gaps.push("noticePeriodDays required");

  return {
    valid: gaps.length === 0,
    gaps,
  };
}

NCA Submission Timeline and Practicalities

Financial entities were required to submit their initial ICT Third-Party Provider Register to their NCA by 30 April 2025. Ongoing reporting is annual, with interim updates when material changes occur.

What this means for your sales cycle:

If a financial entity prospect is in the process of completing their NCA submission (or responding to NCA questions about gaps), they will have a specific list of information they need from you. Coming to that conversation with a pre-populated DORA annex and a structured data export is not a nice-to-have — it removes an active compliance blocker.

What NCAs check:

NCAs review register submissions for:

• Completeness of mandatory fields
• Consistency between criticality classification and contractual provisions
• Presence of DORA Art. 30 mandatory clauses for CIF-supporting arrangements
• Adequacy of exit and portability provisions

A financial entity that cannot provide required register fields because their vendor's contract is silent gets a remediation request. That request flows back to you as a contract amendment demand.

The EU Infrastructure Advantage in DORA Registers

The DORA register framework creates a specific procurement advantage for EU-domiciled infrastructure providers that has not yet filtered into mainstream sales conversations.

When a regulated financial entity's ICT register shows:

Cloud Infrastructure Subcontractor: Hetzner Online GmbH (DE)
Data Storage Country: DE
Data Processing Country: DE
Parent Group: None

versus:

Cloud Infrastructure Subcontractor: Amazon Web Services EMEA SARL (LU, parent: Amazon.com Inc. US)
Data Storage Country: EU-West-1 (IE)
Data Processing Country: EU
Parent Group: Amazon.com Inc. (US)

The first entry requires no additional CLOUD Act analysis, no US-parent jurisdictional risk note, and raises no flags in standard NCA review tooling. The second entry requires the financial entity's legal team to document their CLOUD Act risk assessment and potentially add a qualitative risk note to the submission.

This is not speculative. Several EU NCAs have issued guidance noting that US-parent subcontractors require additional risk justification in register submissions. The administrative overhead of that justification is a real cost in large financial entities with thousands of vendor relationships.

If you are building or migrating a SaaS product targeting financial sector customers, running on EU-native infrastructure is not just a marketing claim — it is a concrete reduction in your customers' compliance overhead.

Practical Next Steps for SaaS Developers

If you currently have zero financial sector customers:

• Prepare a DORA Compliance Annex template (use the checklist above)
• Ensure your DPA includes data location commitments with change notification
• Document your subcontractor chain with country information
• Review whether your current infrastructure provider introduces US-parent complexity into your customers' registers

If you already have financial sector customers:

• Audit your existing MSAs against the Art. 30(2) minimum requirements
• Identify which customers have classified your service as CIF-supporting
• Proactively provide your subcontractor list to customers who will need it for their register
• Schedule a DORA alignment review with your largest financial sector accounts

If you are pursuing financial sector enterprise deals:

• Include your DORA Compliance Annex in the initial proposal package
• Offer to provide a structured data export for the customer's register entry
• Make your infrastructure provider chain visible (and preference EU providers where possible)
• Ensure your contract includes explicit pooled audit participation language

Conclusion

DORA's ICT Third-Party Provider Register requirements went into effect in January 2025. Every SaaS vendor serving EU financial entities is now an entry in a structured, NCA-reviewed register. The register mandates specific contractual provisions — on data locations, audit rights, exit terms, and subcontractor transparency — that are not present in most standard SaaS agreements.

The financial sector's compliance burden does not end at their perimeter. It flows upstream to every ICT vendor in their stack. SaaS developers who understand the register requirements and proactively meet them close deals faster and avoid renegotiation cycles later. Those who discover the requirements after a financial sector customer raises them face contract overhaul under time pressure.

The DORA Compliance Annex checklist and the TypeScript generator above are starting points. The specific fields in your NCA submission vary by member state, and the Joint ESA ITS on the register continues to be refined through 2025-2026. Consult your legal team before finalizing DORA-targeted contract language for financial sector customers.

The register requirements described in this article are based on DORA Regulation (EU) 2022/2554 Articles 28-30, the Joint Committee ITS on the Register of Information (2024/0249), and EBA guidance published through Q1 2025. CTPP designation is an ongoing process; the examples of likely designated providers are the author's assessment, not official ESA designations.