Your ERP handles accounting, supplier payments, regulatory reporting, and payroll. If this system fails, your business doesn’t slow down — it stops. This is precisely the scenario that the DORA (Digital Operational Resilience Act) aims to prevent across the European financial sector. Since 17 January 2025, this regulation imposes an unprecedented operational digital resilience framework on financial entities and their critical ICT service providers.
The issue: most IT directors and CISOs in the financial sector know DORA exists, but few have precisely mapped what the regulation changes in the management, contracting and testing of their ERP. This guide fills that gap.
Key Takeaways in 30 Seconds
- DORA (EU Regulation 2022/2554) applies since 17 January 2025 to 20 types of financial entities and their ICT providers.
- ERP systems are almost always classified as “critical” as they handle accounting, payments and regulatory reporting.
- Penalties: up to 2% of annual worldwide turnover for financial entities, daily fines up to 1% of daily worldwide turnover for 6 months (Avenga).
- SAP has been officially designated as a “critical third-party ICT service provider” by European supervisory authorities (SAP).
- DORA complements NIS2, it doesn’t replace it: both apply, with distinct scopes and supervisory authorities.
DORA in 3 Minutes: What the European Digital Resilience Regulation Says
Context: Why the EU Imposed DORA
On 19 July 2024, a CrowdStrike Falcon update caused the largest IT outage in recent history. Banks like Bank of America, Chase, Capital One and Wells Fargo saw their payment systems disrupted. Estimated losses for the 500 largest US companies: over $5.4 billion (Wikipedia). The most affected financial entities were those least mature in third-party risk management — precisely DORA’s focus.
This isn’t an isolated case. Cyberattacks on the financial sector are multiplying: ransomware targeting banking systems, software supply chain compromises, sensitive data theft. The EU learned from these incidents to impose a harmonised framework across the entire financial sector.
Scope: Who is Concerned?
DORA applies to 20 types of financial entities:
- Credit institutions (banks, finance companies)
- Investment firms and management companies
- Insurance and reinsurance companies
- Payment and electronic money institutions
- Crypto-asset service providers
- Central securities depositories and trading platforms
- Occupational pension funds
And crucially: their critical third-party ICT service providers — ERP vendors, cloud hosts, infrastructure providers. The DORA register, mandatory since 2025, covers nearly 22,000 financial entities in the EU (SBS Software).
Timeline: Application Since January 2025, Enhanced Controls 2026
- 14 December 2022: adoption of EU Regulation 2022/2554
- 17 January 2025: entry into application
- 17 January 2026: the European Commission conducts a review and submits a report to Parliament and Council (EUR-Lex)
- 2026-2027: ramping up of controls by European supervisory authorities (EBA, EIOPA, ESMA)
The first TLPT (Threat-Led Penetration Testing) cycle is underway. Significant financial entities must conduct TLPT at least every 3 years (EBA).
DORA’s 5 Pillars and Their Impact on ERP
DORA is structured around 5 pillars that frame all obligations. Each has direct implications for your ERP.
Pillar 1 — ICT Risk Management: Mapping ERP Dependencies
Article 8 of DORA requires identification and documentation of all “critical or important functions”. ERP almost always falls into this category: it handles general and analytical accounting, the supplier cycle (orders, receipts, invoices, payments), regulatory reporting and often payroll.
What this changes practically:
- Map complete ERP dependencies: servers, databases, middleware, banking connectors, interfaces with trading or asset management systems
- Document failure scenarios: what happens if the ERP server fails? If the database is corrupted? If the payment gateway link is cut?
- Maintain an updated ICT register, transmissible to supervisory authorities
Pillar 2 — Incident Classification and Reporting: Integrating ERP into Notification Processes
DORA imposes a process for detecting, classifying and reporting major ICT incidents to competent authorities. If your ERP suffers an incident affecting the continuity of a financial service — for example, inability to generate regulatory statements or process payments — this incident must be classified and, depending on its severity, notified to authorities.
ERP Implications:
- Integrate ERP supervision into the company’s SIEM (Security Information and Event Management)
- Define ERP-specific alert thresholds: downtime, number of blocked transactions, data loss
- Document the notification procedure: who reports, within what timeframe, to which authority
Pillar 3 — Operational Resilience Testing: Testing ERP Failover (DRP/BCP)
This is the pillar that most changes the game for ERP teams. DORA imposes regular resilience testing at two levels:
- Basic tests: vulnerability tests, performance tests, failover tests to backup environment (DRP/BCP), backup restoration tests
- Advanced tests (TLPT): for significant entities, threat-led penetration tests conducted by specialised teams simulating real attacks on critical systems — including ERP
TLPT under DORA differs from classic pentesting: it covers the entire organisation, not an isolated perimeter. It can last 3 to 4 months and includes mandatory “purple teaming” exercise where the attack team then collaborates with the defence team (Blaze InfoSec).
For ERP, this means:
- Simulate complete ERP system failure and measure failover time to DRP
- Test ERP backup restoration under real conditions (not on paper)
- Verify that critical interfaces (banking, reporting, payroll) reconnect properly after failover
Pillar 4 — Third-Party ICT Risk Management: Is Your ERP Vendor a Critical Provider?
This is the most transformative pillar for the relationship between the company and its ERP vendor. DORA requires formal evaluation of each ICT service provider before contract signature, continuous risk monitoring, and specific contractual clauses (audit, portability, exit plan).
European supervisory authorities (ESAs) have the power to directly designate “critical” ICT service providers and subject them to direct supervision. SAP has already received this official designation (SAP). Other major ERP vendors will likely follow.
What this implies:
- Check if your ERP vendor appears on the list of critical providers designated by ESAs
- Audit your ERP contract clauses: SLAs, audit rights, data portability, exit strategy
- Ensure the vendor can provide DORA compliance evidence requested by regulators
Pillar 5 — Information Sharing: ERP Data in Sectoral Exchanges
DORA encourages (without strictly mandating) sharing of cyber threat information between financial entities. If your ERP detects an intrusion attempt via a known vulnerability in a third-party connector, this information can be shared with other sector actors to prevent similar attacks.
In practice, this requires compartmentalising shared information to avoid exposing sensitive business data — an architectural task that directly affects the ERP layer.
DORA Checklist for Your ERP
10 Questions to Ask Your ERP Vendor or Host
- Do you have a documented and tested business continuity plan (BCP) for your ERP platform?
- What is your contractual RTO (Recovery Time Objective) and RPO (Recovery Point Objective)?
- Are your datacenters located in the EU? If not, what sovereignty guarantees do you offer?
- Have you been designated a “critical third-party ICT service provider” by ESAs? If yes, under what supervision?
- Do you grant DORA audit rights to your financial clients? Under what conditions?
- How do you ensure data portability in case of termination or failure?
- What is your process for notifying major ICT incidents?
- Are your subcontractors (cloud host, database provider) identified and documented in your ICT register?
- What security certifications do you hold (ISO 27001, SOC 2, C5)?
- Can you provide compliance evidence requested by financial regulators within a timeframe compatible with DORA reporting obligations?
Contractual Clauses to Renegotiate
DORA imposes precise contractual requirements for agreements with ICT service providers. For your ERP contract, verify:
- Availability SLA: a 99.5% SLA allows 43 hours of unavailability per year. For a critical financial ERP, aim for 99.9% minimum
- Audit rights: the contract must provide reasonable access to provider premises and systems for audit — including by regulators
- Portability and exit plan: detailed reversibility clause, standard data formats, restitution deadline, migration assistance
- Incident notification: contractual notification deadline (DORA imposes “without undue delay” initial reporting), minimum report content
- Chain subcontracting: veto or information rights on your vendor’s critical subcontractors
ERP Resilience Testing Plan
A DORA-compliant testing plan for ERP must cover at minimum:
Annual tests:
- Failover to backup environment (DRP) with actual RTO timing
- Complete ERP database backup restoration
- Critical interface reconnection test (banking, regulatory reporting, payroll)
- Load testing under degraded conditions (one less server node)
Every 3 years (TLPT for significant entities):
- Simulated targeted attack on ERP system by external red team
- Mandatory purple teaming: joint debriefing with defence team
- Complete documentation of discovered vulnerabilities and remediation plan
Cloud vs On-Premise ERP Facing DORA: Advantages and Risks
Public Cloud: Third-Party Risk Concentration but Better Infrastructure Resilience
Deploying ERP on a hyperscaler cloud (AWS, Azure, Google Cloud, OCI) offers structural advantages for resilience: multi-zone redundancy, automatic failover, high SLAs, security certifications (ISO 27001, SOC 2, C5 for Germany). Oracle publishes DORA-specific compliance guides for OCI (Oracle).
But cloud concentrates third-party risk: if your ERP runs on Azure and Microsoft suffers a major incident (CrowdStrike scenario), your BCP depends on Microsoft’s resilience, not yours. DORA understood this: the regulation requires that the financial entity remains “fully responsible” for its resilience, even when outsourcing.
In practice: cloud ERP simplifies DORA compliance on infrastructure, but complicates third-party concentration risk management. Regulators will expect analysis of this concentration risk and a credible exit plan.
On-Premise: Total Control but Heavier BCP/DRP Responsibility
On-premise ERP gives total infrastructure control. No dependence on a hyperscaler, no third-party concentration risk at hosting level. However, BCP/DRP responsibility rests entirely with the company: backup datacenter, data replication, failover testing, security patch updates.
For a regional bank or mid-sized insurer, this responsibility has significant cost in internal skills and infrastructure.
Hybrid Model: The Most Frequent Compromise
Most financial entities adopt a hybrid model: primary ERP in private or public cloud, with separate backup site (different datacenter, different cloud provider). This model enables benefiting from cloud resilience while limiting concentration risk.
DORA doesn’t impose a deployment model. The regulation requires results (service continuity, recovery time, proven tests) — not technical choices. The IT director remains free in architecture, but must prove it holds.
How Major ERP Systems Position Themselves Against DORA
SAP: Designated Critical ICT Provider
SAP is the first major ERP vendor to be officially designated a “critical third-party ICT service provider” (CTPP) by European supervisory authorities (SAP). This designation means SAP is subject to direct ESA supervision and must meet the highest standards of security, continuity and compliance.
For SAP financial sector clients, this designation is a guarantee: SAP cannot escape DORA requirements. In return, compliance audits will be more frequent and contractual requirements stricter.
SAP offers DORA compliance support tools, notably via SAP LeanIX for application and ICT dependency mapping (SAP LeanIX).
Oracle: OCI Compliance Guides and DORA Clauses
Oracle published DORA compliance guides for Oracle Cloud Infrastructure (OCI), detailing how Exadata and Recovery Appliance features align with DORA Articles 7 to 12. Oracle highlights integrated appliance resilience (automatic failover, encryption, isolation) and specific contractual provisions for portability and exit strategies (Oracle).
Oracle also offers a DORA-specific contractual checklist for NetSuite, its SME cloud ERP, covering Article 30 requirements on contractual arrangements.
Sage, Unit4, Odoo: Where Stand Mid-Size European Vendors?
Mid-size European vendors haven’t yet been designated CTPP by ESAs. Their DORA exposure depends on the number of financial clients they serve and their classification by national regulators.
For these vendors, the DORA question arises at two levels:
- As ICT service provider: if a financial sector client uses Sage or Unit4 for accounting, the vendor must be able to meet DORA contractual requirements (SLA, audit, portability, incident notification)
- As company: if the vendor itself processes financial data or provides payment services, it may be directly subject to DORA
Maturity level varies. Large European vendors (Sage, Unit4) generally have ISO 27001 certifications and documented BCPs. Smaller vendors (Odoo Community, Dolibarr) must be evaluated case by case — certification and compliance documentation depend on the hosting and integration partner, not the open source vendor.
DORA vs NIS2: Two Regulations, Two Logics
DORA and NIS2 apply in parallel, but with different scopes and logics:
| Criteria | DORA | NIS2 |
|---|---|---|
| Regulation/Directive | Regulation (direct application) | Directive (national transposition) |
| Sector | Financial exclusively | 18 sectors (energy, health, transport, digital…) |
| Targeted entities | Financial entities + ICT providers | Essential and important entities |
| Supervisory authority | ESAs (EBA, EIOPA, ESMA) | ANSSI (France), BSI (Germany)… |
| Penetration testing | Mandatory TLPT (significant entities) | Security tests but no TLPT |
| Third-party supervision | Direct CTPP supervision | Entity responsibility |
If your company is a bank or insurer, DORA prevails over NIS2 for digital resilience aspects (lex specialis principle). But you remain subject to NIS2 for obligations not covered by DORA.
To deepen NIS2 obligations, consult our NIS2 and ERP guide for mid-size companies.
What to Watch in 2026-2027
The first DORA compliance cycle is just beginning. Here are the deadlines and topics to follow:
- European Commission review (January 2026): first application assessment, possible technical standards adjustments
- New CTPP designations: after SAP, other ERP vendors could be designated critical providers by ESAs
- Control ramp-up: supervisory authorities begin auditing ICT registers and resilience testing plans
- DORA/NIS2 convergence: financial sector companies subject to both texts will need to rationalise their compliance systems
- TLPT tests: the first advanced testing cycle is underway for significant entities — feedback will feed market best practices
For deeper ERP security insights, consult our ERP cybersecurity guide and our NIS2 directive analysis. If you’re evaluating a cloud model for your financial ERP, our cloud vs on-premise comparison details technical and economic trade-offs.
