What is DORA? Complete SaaS & ICT Provider Compliance Guide 2026

Post #1318 in the sota.io EU Cyber Compliance Series

The Digital Operational Resilience Act (DORA, Regulation EU 2022/2554) has been fully applicable since January 17, 2025. If you sell SaaS, cloud infrastructure, or ICT services to any financial institution in the EU — a bank, insurer, payment provider, or crypto exchange — DORA affects your contractual obligations, your security controls, and potentially your regulatory oversight status.

This guide covers everything SaaS and ICT providers need to know: what DORA actually requires, who is in scope, the five compliance pillars, third-party rules, and how EU-native infrastructure reduces your compliance burden.

What is DORA?

DORA is an EU regulation that creates a unified framework for digital operational resilience across the financial sector. Before DORA, each EU member state had different rules for how banks and insurers should manage ICT risk. DORA harmonizes all of this into a single regulation that applies directly in all 27 member states without national transposition.

Key facts:

• Regulation: EU 2022/2554
• Signed: December 14, 2022
• Entry into force: January 16, 2023
• Fully applicable: January 17, 2025 (now in force)
• Enforced by: EBA (banking), EIOPA (insurance), ESMA (securities) — together the ESAs
• Direct regulation: No national transposition needed — applies directly like GDPR

Who is in Scope?

DORA's scope is broad. Article 2 covers 20+ categories of financial entities:

Financial Entities (directly regulated)

• Credit institutions (banks)
• Payment institutions and e-money institutions
• Investment firms
• Crypto-asset service providers (CASPs under MiCA)
• Central counterparties (CCPs) and central securities depositories
• Insurance and reinsurance undertakings
• Pension funds, UCITS management companies, AIFMs
• Credit rating agencies, audit firms (statutory)
• Crowdfunding service providers
• Data reporting service providers

ICT Third-Party Service Providers (indirectly regulated, directly supervised if critical)

If your SaaS or cloud platform serves any of the above, you are an ICT third-party service provider under DORA. This means:

• Financial entities must include DORA-specific clauses in your contracts
• You must support their exit strategies and audit rights
• If you are designated critical by the ESAs, you face direct supervision

The Five Pillars of DORA

Pillar 1: ICT Risk Management (Articles 5–16)

Financial entities must maintain a comprehensive ICT risk management framework covering:

• ICT risk identification and classification (including cloud, SaaS, APIs)
• Protection and prevention measures (logical and physical access controls)
• Detection of anomalous activities
• Response and recovery procedures
• Communication and post-incident review

What this means for ICT vendors: Your SaaS product must support your financial customers' ability to document their risk exposure. You should provide: asset inventory support, security configuration documentation, and log access for their ICT risk register.

The management body (board) is directly accountable — senior management cannot delegate ICT risk away. This drives purchasing decisions: financial entities prefer vendors that simplify their board-level reporting obligations.

Pillar 2: ICT Incident Management and Reporting (Articles 17–23)

DORA creates a three-tier incident classification and prescribes strict reporting timelines:

Key reporting path: Directly to the home state competent authority (e.g., BaFin for German banks, ACPR for French banks). Competent authorities may share with ESAs for cross-border incidents.

What this means for ICT vendors: Your SaaS must provide incident notification SLAs that allow your customers to meet the 4-hour initial reporting deadline. This typically means:

• Real-time incident communication channels
• Contractual commitment to notify customers within 2 hours of a major incident
• Log access within the incident window

Pillar 3: Digital Operational Resilience Testing (Articles 24–27)

All financial entities must conduct annual ICT testing. Significant entities (determined by national competent authorities) must also conduct advanced Threat-Led Penetration Testing (TLPT) — at minimum every three years.

TLPT is based on the TIBER-EU framework (Threat Intelligence-Based Ethical Red-teaming) developed by the ECB. Key elements:

• Real threat-intelligence-driven attack scenarios
• Red team tests live production systems (not sandboxes)
• Results shared with supervisors
• Approved external testers (TLPT provider register per national authority)

Mutual recognition: DORA Article 26 allows TLPT results from one jurisdiction to be recognized by others — reducing duplication for multinational banks.

What this means for ICT vendors: Your SaaS should support penetration testing by customers or their designated testers. Contracts blocking security testing (common in US-origin SaaS) are non-compliant with DORA. EU-native platforms typically allow testing by default.

Pillar 4: ICT Third-Party Risk Management (Articles 28–44)

This is the pillar that most directly affects SaaS and cloud vendors. DORA Article 28 requires financial entities to:

1. Maintain a register of all ICT third-party service providers (contractual inventory)
2. Conduct pre-engagement risk assessment before onboarding any ICT provider
3. Include mandatory contractual clauses in all ICT service agreements
4. Ensure exit strategies and business continuity plans for critical services
5. Grant audit rights (direct and via third-party auditors) to themselves and supervisors

Mandatory contract clauses (Article 30) include:

• Full description of ICT services provided (scope, SLAs)
• Locations where data is processed and stored (specifically addresses cloud/multi-cloud)
• Provisions on data portability and interoperability
• Cooperation obligations in incident situations
• Audit rights and right to access, inspect, and perform tests
• Exit clause with adequate transition period

The critical third-party framework (Articles 31–44): The ESAs can designate any ICT third-party provider as a Critical Third-Party Provider (CTPP). This triggers direct oversight by a Lead Overseer (one of the three ESAs). As of 2025, the ESAs have begun the first round of CTPP designations — major cloud providers (AWS, Microsoft Azure, Google Cloud) are primary candidates.

CTPPs must:

• Cooperate with the Lead Overseer
• Provide all requested information
• Allow on-site inspections
• Submit annual self-assessment reports
• Comply with mandatory recommendations from oversight visits

Pillar 5: Information and Intelligence Sharing (Articles 45–49)

DORA encourages — and in some cases requires — cyber threat intelligence sharing among financial entities. This includes:

• Voluntary sharing arrangements (Article 45) — financial entities can form trust groups
• Threat intelligence on tactics, techniques, and procedures (TTPs)
• Anonymized sharing of indicators of compromise (IoCs)

The ESAs are expected to develop common platforms or standards for sharing. This pillar is less prescriptive than the others but creates a legal basis for information-sharing that was previously legally ambiguous under GDPR.

DORA and the CLOUD Act: The Critical Intersection

For EU financial institutions, DORA's third-party risk management requirements collide directly with the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018).

The CLOUD Act allows US law enforcement to compel US-based cloud providers (AWS, Microsoft, Google, Oracle) to disclose data stored anywhere in the world — including in EU data centers. This creates a direct conflict:

Practical consequence: Financial entities using US-headquartered cloud providers face a structural compliance tension under DORA Article 28(2)(j) — which requires contracts to specify where data is processed and stored — and Article 28(8), which requires that the ICT provider comply with applicable law (including, potentially, conflicting laws).

EU financial regulators are increasingly flagging this. The EBA Guidelines on ICT and Security Risk Management (2019, superseded by DORA 2025) already noted this risk. DORA's supervisory convergence means national competent authorities will apply CLOUD Act risk analysis more consistently starting in 2026.

DORA Compliance Matrix: US vs EU ICT Providers

What DORA Means for SaaS Vendors Serving Financial Customers

If You Are an ICT Third-Party Provider (Most SaaS)

Your financial customers must:

1. Add you to their ICT third-party register
2. Conduct a pre-engagement risk assessment of your service
3. Include DORA Article 30 mandatory clauses in your contract
4. Maintain an exit strategy from your service

Your obligations:

• Accept contract amendments including DORA-compliant clauses
• Support audit rights (do not contractually block audits)
• Provide documentation to support their risk assessment
• Give incident notification within their 4-hour reporting window
• Cooperate with their competent authority if requested

If you refuse to accept DORA clauses, EU financial entities cannot use your service — full stop.

If You May Become a CTPP (Large-Scale ICT Providers)

If your platform serves a large number of EU financial entities, you may be designated a Critical Third-Party Provider. Signs you might be in scope:

• Multiple banks, insurance companies, or payment institutions use your service
• Your service is systemic (disruption would affect the EU financial system)
• You provide core infrastructure (cloud compute, data storage, network)

CTPP designation means direct ESA oversight — quarterly reporting, on-site inspections, mandatory recommendations. This is a new compliance burden with no equivalent in pre-DORA law.

EU-Native Tools for DORA Compliance

DORA creates demand for EU-native ICT risk management, incident reporting, and resilience testing tools that:

1. Are contractually governed by EU law (not US law)
2. Do not have CLOUD Act exposure
3. Can support audit rights by EU supervisory authorities

Key tool categories for the DORA-COMPLIANCE-TOOLS series:

Hosting as a DORA Risk Reducer

For SaaS vendors serving the financial sector, where you run your infrastructure materially affects your customers' DORA compliance burden:

EU-native hosting (e.g., Hetzner, Scaleway, OVHcloud):

• No CLOUD Act exposure → cleaner DORA Art. 28 contractual position
• EU data protection law governs exclusively
• No risk of CTPP designation driving customers to add you to a "high-risk" register

US hyperscaler hosting (AWS, Azure, GCP):

• CLOUD Act risk must be documented in third-party risk assessments
• Customers must include specific CLOUD Act risk mitigations in their ICT risk register
• Potential CTPP overlap risk (if the hyperscaler you run on is designated)

sota.io runs exclusively on Hetzner (Germany) — no US parent, no CLOUD Act exposure, no CTPP overlap risk. For financial-sector customers using sota.io as their deployment platform, this eliminates an entire risk category from their DORA compliance assessment.

DORA Timeline and Enforcement Milestones

Key Definitions Under DORA

ICT risk: Any reasonably identifiable circumstance related to the use of network and information systems which could adversely affect the security of network and information systems, tools, processes or devices — including risk from third-party providers.

Major ICT-related incident: An ICT-related incident with a high adverse impact on network and information systems that support critical or important functions of the financial entity.

Digital operational resilience: The ability of a financial entity to build, assure, and review its operational integrity and reliability by ensuring, either directly or indirectly through the use of services of ICT third-party service providers, the full range of ICT-related capabilities needed to address the security of the network and information systems.

Critical ICT third-party service provider (CTPP): An ICT third-party service provider designated as critical pursuant to Article 31 by the ESAs.

Practical Checklist for ICT Vendors Serving EU Financial Clients

• Map all EU financial entity customers → determine if you're an ICT third-party provider
• Review your standard SaaS/cloud agreement for DORA Article 30 clause compatibility
• Add mandatory DORA clauses: audit rights, incident notification, data location, exit strategy
• Document your incident notification process → can you notify in <2 hours to enable 4-hour regulatory reporting?
• Remove any contractual provisions blocking security testing or audits
• Assess CTPP designation risk if your service is used by many EU financial entities
• Document your data processing locations (for your customers' Article 28 registers)
• Prepare a data portability / exit package for customers who need exit strategy documentation
• If US-hosted: document CLOUD Act risk mitigation measures for customers' risk registers

What's Next in This Series

This is Post #1 in our EU DORA Compliance Tools Series (5 posts):

1. This post: DORA Fundamentals — scope, pillars, third-party rules, CLOUD Act intersection
2. Next: DORA ICT Risk Management Tools — EU-Native Alternatives 2026 — GRC platforms, risk frameworks, EU-native options
3. DORA Incident Reporting Automation — how to meet the 4-hour deadline with EU tools
4. DORA Third-Party Risk Management — EU-compliant vendor assessment workflows
5. DORA Compliance Stack Finale — complete EU financial services ICT guide

Summary

DORA is not a future obligation — it has been fully applicable since January 17, 2025. Every SaaS vendor serving EU banks, insurers, payment providers, or crypto exchanges is already operating under its third-party risk framework. The five pillars — ICT risk management, incident reporting, resilience testing, third-party risk, and threat sharing — create concrete requirements for contracts, audit rights, and incident notification SLAs.

For ICT vendors, the practical compliance path is clear: accept DORA-compatible contract clauses, support audit rights, deliver sub-2-hour incident notifications, and document your data processing locations. For vendors hosted on EU-native infrastructure (no CLOUD Act exposure), the contractual and risk-register burden on your financial customers is significantly lower — a real competitive differentiator in regulated markets.

The ESA CTPP designation process is now underway. If your platform is systemic to the EU financial sector, monitor the EBA, EIOPA, and ESMA registers closely.