DORA has been applicable since January 17, 2025
The Digital Operational Resilience Act (EU Regulation 2022/2554) is the EU's most comprehensive financial sector cybersecurity regulation. It establishes uniform requirements for ICT risk management across EU financial services — and unlike the NIS2 Directive, DORA directly addresses ICT third-party service providers (ICT TPSPs), including SaaS vendors whose products are used by EU financial institutions.
The ICT Risk Management Framework requirement (Articles 5–16) is at the core of DORA. It is not optional, not a best-practice recommendation, and not implemented through member state law — it is directly applicable EU regulation.
Who does DORA apply to?
| Entity Type | Applies Directly? | Key DORA Obligations |
|---|---|---|
| Credit institutions (banks) | ✅ Yes | All DORA chapters; TLPT for significant entities |
| Payment institutions | ✅ Yes | All DORA chapters; incident reporting to NCA |
| Electronic money institutions | ✅ Yes | All DORA chapters |
| Investment firms | ✅ Yes | All DORA chapters; ESMA oversight |
| Insurance undertakings | ✅ Yes | All DORA chapters; EIOPA oversight |
| Crypto-asset service providers (CASPs) | ✅ Yes | All DORA chapters (from MiCA authorisation) |
| Critical Third-Party Providers (CTPPs) | ✅ Yes — directly overseen by ESAs | Art. 31 oversight; fines up to 1% daily global turnover |
| Other ICT TPSPs (ordinary SaaS vendors) | ⚠️ Indirectly — via Art. 30 contracts | Must comply with financial entity's DORA contractual requirements |
| Microenterprises (financial entities) | ✅ Yes — with simplified proportionate requirements | Simplified ICT risk management framework allowed |
The key insight for SaaS vendors: even if you are not a financial entity and have not been designated as a CTPP, your financial entity customers are legally required to include DORA Art. 30 provisions in contracts with you. If you want to sell to EU banks, payment institutions, or investment firms, you must accept these contractual requirements.
The five pillars of DORA ICT risk management (Art. 5–16)
Pillar 1: Governance and ICT risk management framework (Art. 5–7)
The management body of a financial entity bears ultimate responsibility for ICT risk management under DORA Art. 5. This is not something you can delegate entirely to IT. The management body must:
- Define, approve, oversee, and be responsible for the ICT risk management framework
- Acquire adequate knowledge and skills to understand ICT risk and its impact
- Review the framework at least annually
- Allocate adequate ICT budget
- Approve the ICT strategy (Art. 6) and internal ICT audit plans (Art. 5(2)(d))
Art. 6 requires a documented ICT strategy that addresses digital operational resilience objectives and aligns with the entity's business strategy. Art. 7 requires maintenance of up-to-date ICT systems, protocols, and tools that are reliable, adequate, and sufficiently resilient.
Pillar 2: ICT risk identification and asset management (Art. 8)
DORA Art. 8 requires:
- A comprehensive, continuously updated ICT asset inventory (hardware, software, ICT services, critical data assets)
- Identification and classification of functions, roles, and systems supporting business operations
- Mapping of dependencies between ICT assets and business functions
- Identification of all ICT third-party service providers, with concentration risk assessment
- Continuous ICT risk assessment — identifying threats and assessing impact on critical or important functions
"Critical or important functions" is the key DORA concept. Any function whose disruption, failure, or unauthorised access would materially impair financial performance, operational continuity, or compliance must be identified and subject to enhanced protection requirements.
Pillar 3: Protection and prevention (Art. 9)
DORA Art. 9 requires robust protection measures including:
- Access control policies (minimum rights; least privilege)
- Multi-factor authentication for all systems supporting critical functions
- Encryption at rest and in transit for sensitive data and critical systems
- Network segmentation and traffic monitoring
- Patch management with defined remediation SLAs by severity
- Endpoint security (EDR/AV on all workstations and servers)
- ICT change management aligned with DORA Art. 9(4)
Patch management timelines under DORA should reflect the severity of the vulnerability and criticality of the affected system. For critical vulnerabilities in systems supporting critical functions, same-day or 24-hour patching is the expected standard.
Pillar 4: Detection (Art. 10)
DORA Art. 10 requires mechanisms to promptly detect anomalous activities, including anomalies in ICT network activity and ICT-related incidents. Financial entities must:
- Deploy monitoring tools covering all ICT systems supporting critical functions
- Maintain multi-layered controls (SIEM, IDS/IPS, UEBA, anomaly detection)
- Update detection signatures and rules regularly
- Enable log retention sufficient for incident investigation
- Generate regular operational risk reports for the management body
The DORA requirement is specific: "prompting mechanisms" means near-real-time detection, not weekly log reviews. For critical functions, 24/7 monitoring capability is expected.
Pillar 5: Response, recovery, and learning (Art. 11–13)
Art. 11 requires a comprehensive incident management process. Art. 12 requires backup policies. Art. 13 requires post-incident learning to feed back into improved controls.
| Requirement | DORA Article | Key Requirement |
|---|---|---|
| Incident management policy | Art. 11(1) | Documented processes to detect, manage, classify, report, and resolve ICT incidents |
| ICT incident classification | Art. 18 | Classification based on: impact on clients, data integrity, reputation, economic loss, duration |
| Major incident reporting | Art. 19 | Initial notification: 4h / 24h; Intermediate: 72h; Final: 1 month |
| Backup policies | Art. 12 | Data, applications, and systems backed up; restoration procedures tested; RTO/RPO defined and tested |
| BCP and crisis management | Art. 11(5) | Business Continuity Plan for ICT incidents; crisis communication plan; executive management involvement in severe incidents |
| Post-incident review | Art. 13 | Root cause analysis; lessons learned incorporated into improved controls; threat intelligence integration |
DORA Art. 19 incident reporting timelines
Major ICT-related incidents must be reported to the relevant competent authority (NCA — national competent authority per sector):
| Report Type | Deadline | Content |
|---|---|---|
| Initial notification | Within 4 hours of classification as major incident; no later than 24 hours after first awareness | Nature of incident; initial impact assessment; containment measures initiated |
| Intermediate report | Within 72 hours of first awareness (or immediately on status change) | Updated impact assessment; containment status; root cause investigation update |
| Final report | Within 1 month of submitting intermediate report | Root cause analysis; resolution; remediation measures; lessons learned |
Additionally, DORA Art. 20 allows voluntary notification of significant cyber threats that have not yet caused an incident. This is an important tool for sharing threat intelligence with the competent authority before an incident occurs.
DORA Art. 30: What SaaS vendors must accept in contracts
If you provide ICT services to EU financial entities, your customers' legal teams will require the following provisions in your service contract (Art. 30(2)):
- Full service description: What services are provided, including subcontractors; service levels including quantitative and qualitative targets
- Data location: Where data is stored, processed, and backed up; third-country locations flagged
- Data portability: Procedures for data portability on termination; transition assistance period
- Incident notification: TPSP must notify financial entity promptly of major ICT incidents affecting the services provided to that entity
- Audit rights: Financial entity (and its regulators) must be able to audit the TPSP's ICT practices; third-party certifications (ISO 27001, SOC 2) may substitute for direct audit in certain cases
- Termination rights: Financial entity can terminate for material breach of DORA obligations, regulatory non-compliance, or event rendering the TPSP unfit for purpose
- Business continuity: TPSP must maintain BCP aligned to the financial entity's RTO/RPO requirements
- Data protection: DORA Art. 30 sits alongside GDPR Art. 28 for personal data processing — both sets of requirements apply
Practical advice for SaaS vendors: review your standard MSA/DPA for DORA Art. 30 provisions before a bank asks for them. Having a DORA addendum ready saves weeks of negotiation.
DORA vs GDPR vs NIS2 — where they overlap
| Requirement | DORA | GDPR | NIS2 |
|---|---|---|---|
| ICT risk management framework | Mandatory — Art. 5–16 | Art. 32 TOMs (partial overlap) | Art. 21 (10 security areas) |
| Incident reporting | 4h/72h/1mo to financial regulator | 72h to DPA (personal data only) | 24h/72h to CSIRT/NCA |
| Third-party risk | Art. 28–30 (detailed TPSP requirements) | Art. 28 (DPA for processors) | Art. 21(d) supply chain security |
| Resilience testing | Art. 24–25 (TLPT for significant entities) | Not required | Implicitly required under Art. 21 |
| Management accountability | Art. 5 — management body responsibility | Art. 5/24 — controller accountability | Art. 20 — management body liability |
| Fines | CTPP: up to 1% daily global turnover. Financial entities: per sector law | Up to €20M / 4% global turnover | Essential: €10M / 2%; Important: €7M / 1.4% |
Threat-Led Penetration Testing (TLPT) — DORA Art. 25
Significant financial entities — those identified as systemic by their competent authorities — must conduct TLPT at least every three years. TLPT follows the TIBER-EU framework (Threat Intelligence-Based Ethical Red Teaming). This is a significant undertaking:
- Scope covers all critical or important functions
- Must be conducted by qualified external testers (certified red team providers)
- Results and remediation plans submitted to the competent authority
- Pooled TLPT: multiple financial entities sharing critical ICT providers can jointly conduct TLPT with provider participation
For most SaaS vendors: TLPT is unlikely to be required of you directly. However, if your financial entity customers designate you as a CTPP, TLPT involving your infrastructure becomes possible.
Getting started: practical steps for financial entities and SaaS vendors
For financial entities:
- Conduct a DORA gap assessment against all 16 articles in the ICT risk management framework
- Ensure management body has received DORA training and approved the ICT risk management framework
- Map all ICT third-party providers; identify concentration risks
- Review all ICT TPSP contracts for Art. 30 compliance; issue addenda where required
- Test incident reporting processes — can you meet the 4h/72h timelines?
- Conduct DORA-aligned resilience testing (vulnerability assessment → pen test → TLPT if required)
For SaaS vendors selling to financial entities:
- Prepare a DORA addendum for your MSA (standard Art. 30 provisions)
- Document your ICT risk management framework (this generator helps)
- Ensure incident notification SLAs can meet 4h initial notification to affected clients
- Document RTO/RPO targets and make BCP/DRP available for customer review
- Obtain ISO 27001 or SOC 2 certification — these satisfy the audit rights provision in many cases
- Prepare for concentration risk questions (what % of a financial entity's critical function do you support?)
Generate your DORA ICT Risk Management Policy
Related generators: DORA ICT Risk Management Policy Generator (new!), Incident Response Plan, BCP/DRP Plan, Information Security Policy, Vendor Risk Assessment, Vulnerability Management Policy.
Related reading: DORA Compliance for SaaS Fintech, NIS2 Directive Guide, GDPR Art. 32 Technical Measures.
⚠️ This guide is for informational purposes only and does not constitute legal or regulatory advice. DORA compliance requirements are entity-specific and subject to ESA technical standards. Engage a qualified DORA compliance specialist for your specific situation.