DORA for Payment Operators: EU Digital Operational Resilience in Practice

The Digital Operational Resilience Act has applied since 17 January 2025. If you operate a payment institution, e-money institution, or account information service provider with EU exposure, DORA is not a future compliance consideration — it is a current requirement.

This article covers who is in scope, what the five pillars actually require in practice, the incident reporting timelines, and the third-party provider regime — including the specific detail on Critical Third-Party Provider designation that has been widely misreported.

Scope: Which Payment Businesses Are Covered

DORA Article 2 lists the in-scope entity types explicitly. For payment operators, the relevant categories are:

• Credit institutions (banks)
• Payment institutions (PIs licensed under PSD2/national law)
• Account information service providers (AISPs)
• Electronic money institutions (EMIs)
• Crypto-asset service providers under MiCA
• ICT third-party service providers serving any of the above

Small entity exemption: payment institutions with fewer than 10 employees and annual turnover or balance sheet below €2 million qualify for a simplified framework under Article 16. This reduces documentation requirements while maintaining the core incident reporting and third-party monitoring obligations.

Out of scope: pure technology companies that do not hold a financial services license are not directly in scope as regulated entities — though they may be in scope as ICT third-party providers if they serve in-scope financial entities at sufficient scale.

If you hold a PI or EMI license in any EEA member state and process card payments, run open banking infrastructure, or operate embedded finance products, DORA applies to you.

The Five Pillars

1. ICT Risk Management Framework

Every in-scope entity must maintain a written ICT risk management framework covering: ICT asset identification and classification, protection and prevention measures, detection capabilities, response and recovery procedures, and communication plans.

In practice, this means:

• A complete inventory of ICT assets — hardware, software, data, services
• Classification by criticality (what breaks if this fails?)
• Documented risk assessment methodology
• Business continuity and disaster recovery plans tested at least annually
• A post-incident review process

The proportionality principle applies. A twenty-person payments startup with a PI license has materially lower documentation requirements than a large acquirer. The simplified framework for small entities reduces the formality of the ICT risk framework while maintaining its core elements.

What catches operators off-guard: the ICT asset inventory. Most payment companies have never done a complete audit of every software component, SaaS tool, and cloud service they depend on. DORA requires exactly this. Starting with a critical path inventory — what does a payment transaction touch, in what order, through what systems — is the practical starting point.

2. ICT-Related Incident Reporting

DORA distinguishes between ICT incidents (anything affecting ICT systems) and major ICT incidents (those meeting threshold criteria for reporting to the competent authority).

Classification criteria for major incidents include: number of clients or counterparts affected; geographic spread across member states; duration and service unavailability; economic impact; data losses; reputational impact. The thresholds are defined in the Joint Regulatory Technical Standards published by the EBA, ESMA, and EIOPA.

Reporting timelines (using the EBA’s draft RTS framework):

• Initial notification: within 4 hours of classifying the incident as major, and no later than 24 hours after first detecting it
• Intermediate report: within 72 hours of the initial notification
• Final report: within 1 month of incident resolution

Reports go to the relevant competent authority — BaFin for German-licensed entities, DNB for Netherlands, CBI for Ireland, and so on. The competent authority aggregates data and may escalate to the European Supervisory Authorities.

Practical implication: most payment operators will need to build a formal incident classification process. The majority of ICT incidents will not meet the “major” threshold — but every incident must be assessed against the criteria and the assessment documented. A process that routes all incidents through a classification checklist, with escalation logic for those approaching the thresholds, is the operational requirement.

3. Digital Operational Resilience Testing

All in-scope entities must conduct resilience testing annually, covering ICT systems supporting critical functions.

Basic testing: all entities must conduct basic digital operational resilience testing — vulnerability assessments, network security scans, gap analyses, physical security reviews.

Threat-Led Penetration Testing (TLPT): significant entities — those with systemic importance, typically determined by the competent authority — must conduct TLPT every three years using the TIBER-EU framework. TLPT involves advanced red-team exercises simulating real threat actors. Not all payment institutions will be designated for TLPT, but tier-one PSPs and large EMIs processing material volumes should expect it.

4. Third-Party ICT Risk Management

This is where most payment operators face the most immediate practical work. DORA requires:

• A comprehensive register of all ICT third-party providers
• Due diligence before engaging new providers
• Key contractual provisions in all ICT agreements
• Ongoing monitoring of third-party performance and resilience

Required contractual provisions in all ICT agreements:

• Full description of services and service levels
• Locations where data is processed and stored
• Provisions on data portability and return upon termination
• Cooperation obligations (right to audit, right to inspect)
• Sub-contracting transparency — providers must notify of sub-contractors
• Business continuity and incident notification obligations
• Exit clauses enabling orderly transition with adequate notice

Contracts predating DORA that lack these provisions must be updated at the next renewal. For payment operators running on standard cloud SaaS contracts, this typically means negotiating data processing addenda and service agreements up to DORA standards during the renewal cycle.

Sub-contracting chains: if your payment processor sub-contracts their cloud infrastructure to a cloud provider, that chain must be visible to you. You cannot satisfy DORA third-party risk management if you only manage direct relationships — the sub-contractor risk sits with you.

5. Information and Intelligence Sharing

DORA creates a voluntary framework for financial entities to share cyber threat intelligence — indicators of compromise, attack patterns, defensive measures. Participation is voluntary and legally protected (sharing does not constitute a breach of confidentiality obligations).

In practice, this pillar has the lowest immediate compliance burden. Participation in existing industry information sharing mechanisms (like FS-ISAC) satisfies the intent.

Critical Third-Party Providers: What Operators Actually Need to Know

The CTPP regime is the most discussed element of DORA and also the most commonly misunderstood in operator-level discussions. Getting the specifics right matters.

In November 2025, the European Supervisory Authorities (EBA, ESMA, EIOPA) designated the first batch of Critical ICT Third-Party Providers. Confirmed designated providers include AWS, Google Cloud, and Microsoft Azure. CTPPs face lead overseer supervision, fees, and specific additional obligations.

The penalty clarification: the periodic penalty payment of up to 1% of average daily worldwide turnover per day applies to designated CTPPs under lead overseer enforcement — not to payment operators generally. For regulated payment institutions that fail to comply with DORA, enforcement and penalties are determined by the relevant national competent authority and national implementation provisions. These vary by member state and by the severity of the breach. Do not conflate the CTPP penalty regime with the general payment operator compliance framework.

What the CTPP designation means for payment operators: if your payment infrastructure runs on AWS, Google Cloud, or Microsoft Azure (as most does), you are using a designated CTPP. DORA requires you to manage this relationship with enhanced due diligence — not a light-touch vendor review. Your contracts with these providers should reflect DORA-compliant terms for critical ICT services.

The Practical Compliance Checklist

For a payment institution starting its DORA compliance program now:

1. ICT asset inventory: map every system that touches a payment transaction. Include SaaS tools, cloud services, third-party APIs, and sub-contractors of your primary providers.

2. Criticality classification: for each asset, assess: what is the impact of a failure? Which assets are in the critical function path?

3. Third-party contract audit: review all ICT supplier contracts against the DORA required provisions list. Flag gaps for next renewal cycle.

4. Incident classification process: build a written process for classifying ICT incidents against the major incident criteria. Automate the logging and routing.

5. Business continuity testing: schedule at least one annual BCP test covering the critical function path. Document the results and remediation actions.

6. CTPP relationships: for AWS, Google Cloud, and Azure specifically, review your existing data processing agreements and enterprise contracts against DORA third-party requirements.

7. Regulatory notification: confirm which competent authority you report to and establish the contact process for incident notifications.

DORA is not a future compliance project. It has been in force since January 2025. The PCI DSS experience is instructive — operators who start compliance programmes early when enforcement is light avoid the scramble that follows when regulators begin examining whether the five pillars are actually in place.