← All guides
Financial Regulation11 min read4 June 2026

DORA Compliance for SaaS Fintech: Digital Operational Resilience Act Guide (2026)

The EU Digital Operational Resilience Act (DORA) applies to financial entities and their critical ICT providers. If your SaaS serves banks, insurers, or investment firms — or if you're a Critical Third-Party Provider — here's what you need to comply with.

The EU Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554 — has applied since 17 January 2025. If your SaaS company serves EU financial entities (banks, insurers, investment firms, payment institutions, crypto-asset service providers), or if you're a critical ICT third-party provider (CTPP), DORA directly affects your business.

This guide explains who DORA applies to, what it requires, and how to approach compliance as a SaaS fintech or ICT service provider.

Who Does DORA Apply To?

Financial Entities (Primary Scope)

Entity typeExamplesScope
Credit institutionsBanks, savings banks, credit unionsFull DORA obligations
Payment institutionsPSPs, e-money institutionsFull DORA obligations
Investment firmsBrokers, asset managers, robo-advisorsFull DORA obligations
Insurance undertakingsInsurers, reinsurers, insurance intermediariesFull DORA obligations
Crypto-asset service providersCASPs under MiCAFull DORA obligations
Crowdfunding platformsEquity/lending crowdfunding under ECSPRFull DORA obligations
Central counterparties (CCPs)Clearing housesFull DORA obligations
Micro-enterprises (some)Financial entities <10 employees / <€2M turnoverSimplified regime (Art. 16)

ICT Third-Party Providers (Indirect + Critical)

DORA distinguishes between ordinary ICT providers and Critical Third-Party Providers (CTPPs):

  • All ICT third-party providers must comply with contractual requirements under Art. 30 when contracted by financial entities — meaning your contracts must include specific DORA clauses
  • Critical Third-Party Providers (CTPPs) — designated by ESAs (European Supervisory Authorities) — face direct DORA oversight: supervisory assessments, information requests, on-site inspections, recommendations, and fines up to 1% of global daily turnover for each day of non-compliance (up to 6 months)

CTPP designation is based on: systemic importance to financial entities, number of financial entities using the provider, cross-border reach. Hyperscalers (AWS, Azure, GCP) and major financial infrastructure providers are the obvious CTPP candidates. Most SaaS companies won't be designated CTPPs — but they must still meet contractual requirements when serving financial entities.

The 5 Pillars of DORA

1. ICT Risk Management (Chapter II, Art. 5-16)

Financial entities must maintain a comprehensive ICT Risk Management Framework that includes:

  • ICT risk governance: management body directly responsible and accountable (Art. 5); no delegation to IT department without oversight
  • ICT risk strategy aligned with overall business strategy
  • ICT asset inventory (hardware, software, data, cloud services — Art. 8)
  • ICT risk identification and classification: continuous monitoring, vulnerability testing, threat intelligence
  • ICT risk protection: network/infrastructure security, access controls, data policies, backup/recovery
  • ICT risk detection and response: anomaly detection, incident response procedures
  • ICT risk recovery: business continuity and disaster recovery plans
  • ICT risk learning and evolving: post-incident analysis, threat intelligence integration

For SaaS companies selling to financial entities: your customers must document their ICT risk framework, and your service will be part of their ICT risk landscape. This means your security documentation (processor security policy, SOC 2 report, ISO 27001 certificate) will be scrutinised as part of their DORA compliance — not just in GDPR due diligence.

2. ICT Incident Management and Reporting (Chapter III, Art. 17-23)

DORA creates a tiered incident reporting regime for financial entities:

TriggerReport toTimelineContent
Major ICT-related incident (Art. 19)Competent authority (NCA)Initial: 4 hours (or end of business day if discovered after 2pm) / Intermediate: 72 hours / Final: 1 monthNature, impact, response actions
Significant cyber threat (Art. 19(2))Competent authority (voluntary)Without undue delayThreat nature, potential impact, mitigations

"Major" incident classification criteria (Art. 18) include: number of clients affected, criticality of services impacted, geographic spread, duration, data losses, reputational impact, economic significance.

What this means for ICT providers: Your incident response plan must align with your financial entity customers' DORA reporting timelines. If your platform goes down, your customer needs to assess whether they have a major ICT incident to report. Your breach notification to them needs to happen fast enough for them to meet their DORA obligations — typically within hours, not 24-48 hours.

3. Digital Operational Resilience Testing (Chapter IV, Art. 24-27)

DORA mandates a graduated testing programme:

  • Basic testing (all financial entities): Vulnerability assessments, penetration testing, source code reviews, performance testing, scenario-based testing, compatibility testing — at least annually
  • Advanced TLPT (significant financial entities): Threat-Led Penetration Testing (TLPT) — intelligence-based, red team exercises targeting live production systems — every 3 years. TIBER-EU framework. Tests must cover ICT third-party providers' systems where they host critical functions.

For SaaS ICT providers: You may be required to participate in your financial entity customers' TLPT exercises if you host critical functions for them. This is a significant operational commitment — scoped penetration tests on production systems conducted by external red teams.

4. ICT Third-Party Risk Management (Chapter V, Art. 28-44)

This is the section most directly relevant to SaaS companies selling to financial entities.

Art. 30 requires all contracts between financial entities and ICT third-party providers to include:

  • Full description of all functions and services the ICT provider will provide, including whether sub-contracting is involved and with whom
  • Locations where services will be provided and where data will be processed
  • Data security provisions (at rest, in transit, incident notification)
  • Access, inspection, and audit rights for the financial entity (and competent authorities)
  • Business continuity requirements and SLAs (RTO/RPO)
  • Data portability and exit assistance provisions
  • Cooperation with financial entity's supervisory authority
  • Termination rights (including where CTPP designation impacts risk profile)

If your SaaS serves EU banks or insurers, expect them to send you a DORA contract addendum requiring you to accept these terms. This is similar to what GDPR DPAs did for data processing — a standard contract addition that becomes table-stakes for financial sector sales.

5. Information Sharing (Chapter VI, Art. 45)

DORA creates a voluntary framework for financial entities to share cyber threat intelligence and information with each other — sector ISACs (Information Sharing and Analysis Centers). This is relevant to large financial entities, not typically to SaaS providers.

DORA vs GDPR: How They Interact

AreaGDPR requirementDORA requirementInteraction
Incident notification72 hours to DPA (Art. 33)4 hours initial / 72 hours intermediate to NCA (Art. 19)DORA timelines are tighter — your notification to financial entity customers must enable their DORA reporting
Sub-processors / ICT providersArt. 28 DPA requiredArt. 30 detailed contract requiredBoth need contracts; DORA adds specific clauses beyond GDPR DPA
Data securityArt. 32 appropriate TOMsArt. 9-10 specific ICT security requirementsComplementary — DORA is more operationally prescriptive for financial entities
Business continuityArt. 32(1)(c) — resilience and recoveryArt. 11-12 full BCP/DRP requirements with ICT-specific elementsDORA adds more specific BC/DR requirements for financial entities
Audit rightsArt. 28(3)(h) controller audit rights over processorsArt. 30(2)(d)/(e) supervisory authority access + financial entity audit rightsDORA adds regulatory access — competent authorities can audit your systems

Practical Steps for SaaS Companies Selling to Financial Entities

  1. Assess whether your service is "critical" to customers: Core banking functionality, payment processing, trading infrastructure = high scrutiny. Marketing analytics, HR = lower scrutiny.
  2. Prepare DORA-compliant contract templates: Review your DPA and master services agreement against Art. 30 requirements. Add clauses on audit rights, sub-contractors, data location, exit assistance.
  3. Update your incident response plan: Add a "financial entity notification" workflow with tight timelines (4 hours initial for any potential major incident).
  4. Document your sub-contractor chain: Financial entity customers must know who processes their data (Art. 30(1)(b)). Your sub-processor list becomes a DORA deliverable.
  5. Prepare for audit/inspection requests: Accept that financial entity customers (and potentially their regulators) may request to inspect your security controls. SOC 2 Type II or ISO 27001 reduces but doesn't eliminate this burden.
  6. Review BCP/DRP for RTO/RPO commitments: DORA requires financial entities to set and enforce RTO/RPO SLAs on their ICT providers. Know your numbers.

DORA Fines and Enforcement

  • Financial entities: Fines set by member states — expected to be significant given DORA's financial stability focus
  • Critical Third-Party Providers (CTPPs): ESAs can impose fines up to 1% of average daily worldwide turnover in the preceding business year, applied for each day of non-compliance until compliant (up to 6 months)
  • CTPP non-compliance with Lead Overseer recommendations: Periodic penalty payments also available

Related guides

Generate your BCP/DRP Plan → /generate/bcp-drp-plan | Incident Response Plan → /generate/incident-response-plan | Processor Security Policy → /generate/processor-security-policy

⚠️ This guide is for informational purposes only and does not constitute legal advice. DORA compliance requirements depend on your entity classification and member state implementation. Engage qualified financial regulatory counsel.