DORA and digital operational resilience in finance: what payment service providers need to know

Why DORA was adopted

Finance is one of the most digitalised sectors. Payments, accounts, trading and customer service run almost entirely on information systems, and a growing share of those systems is sourced from external providers such as cloud services and software vendors. This improves efficiency, but it also means that a single technical disruption or cyber attack can spread quickly across several organisations.

Before DORA, requirements concerning ICT risk were scattered across different legislation and supervisory guidance, and they varied by sector. The European Union brought them together in the Digital Operational Resilience Act, Regulation (EU) 2022/2554, known as DORA. It is complemented by amending Directive (EU) 2022/2556, which aligned earlier sector-specific legislation with the new framework.

DORA has applied since 17 January 2025. As a regulation, it is directly applicable in all Member States. The detailed requirements are specified in technical standards prepared by the European Supervisory Authorities (ESAs) and adopted by the Commission as delegated and implementing regulations.

A central idea of DORA is to shift the focus from merely preventing disruptions to the ability to withstand and recover from them. Perfect protection does not exist, so an entity must assume that disruptions will occur and ensure that critical functions continue or are restored in a controlled manner. For this reason, the regulation treats information security, business continuity, outsourcing and reporting as a single whole rather than as separate areas.

Scope and proportionality

DORA applies to a broad range of financial entities. For payments, the most relevant are credit institutions, payment institutions and e-money institutions, but the scope also includes, for example, investment firms, insurers and market infrastructures. In addition, the regulation establishes an oversight framework for certain critical ICT third-party providers serving the financial sector.

DORA brought one significant change for payment service providers: DORA replaced the major incident reporting under PSD2 for payment service providers within the scope of DORA. Incidents are therefore reported under DORA’s classification and reporting rules rather than through a separate PSD2 procedure.

The regulation follows the principle of proportionality. Implementation takes into account the entity’s size, risk profile and the nature and scale of its services. For certain smaller entities, the regulation allows a simplified ICT risk management framework. In Finland, compliance by financial entities is supervised by the Finnish Financial Supervisory Authority (Finanssivalvonta).

The five pillars

DORA is usually structured into five pillars that together form a comprehensive resilience framework:

Pillar	Key content
ICT risk management	A documented framework, management accountability, protection, detection, recovery and continuity.
Incident management and reporting	Detection and classification of ICT-related incidents and reporting of major incidents to the authority.
Resilience testing	A regular testing programme and, for designated entities, threat-led penetration testing (TLPT).
Third-party risk	A register of information on contracts, contractual provisions and exit strategies.
Information sharing	Voluntary arrangements for sharing cyber threat intelligence between entities.

The ICT risk management framework

The foundation of DORA is a documented ICT risk management framework. It is not a single security policy but a whole that covers strategies, policies, procedures, tools and responsibilities. A key principle is that the management body is accountable for ICT risk management and its adequacy; this responsibility cannot be passed entirely to technical units or providers.

The framework must cover the full lifecycle:

Identification: mapping critical functions, information assets and their dependencies.
Protection and prevention: access management, encryption, change management and vulnerability management.
Detection: monitoring of anomalous activity and alerting.
Response and recovery: continuity and recovery plans and their testing.
Learning: post-incident analysis and putting lessons into practice.

From a data protection perspective, DORA’s requirements directly support the security measures required by Article 32 GDPR. See also the guide Financial data privacy in open banking.

Incident classification and reporting

DORA requires an entity to have a process for detecting, recording and classifying ICT-related incidents. An incident is classified as major when it meets criteria defined in the technical standards, relating for example to the impact on clients, duration, geographical spread and critical services.

Major ICT-related incidents are reported to the competent authority in three stages. The time limits are based on Commission Delegated Regulation (EU) 2025/301:

Report	Time limit
Initial notification	Within 4 hours of classifying the incident as major and no later than 24 hours after the entity became aware of it
Intermediate report	Within 72 hours
Final report	Within one month

Short deadlines mean that reporting has to be planned in advance. Classification criteria, responsible persons, the decision chain and report templates must be ready before an incident occurs. In practice, the initial notification is often made with incomplete information and supplemented in the intermediate and final reports.

For payment service providers

Because DORA replaced the major incident reporting under PSD2 for payment service providers within its scope, earlier PSD2 reporting processes should be updated to DORA’s classification criteria and time limits.

Reporting is also a source of information for supervisors. When incident data is collected in a uniform format, the authorities can identify risks affecting the sector more broadly, such as the effects of a disruption at one provider on several entities. For an individual entity, uniform classification means that the same criteria can also be used in internal risk reporting and in management’s situational awareness.

Digital operational resilience testing

DORA requires a risk-based testing programme, which may include vulnerability assessments, network security assessments, scenario-based tests, performance tests and source code reviews. The scope of testing is proportionate to the entity’s size and risks.

Entities designated by the competent authorities must also carry out threat-led penetration testing (TLPT) at least every three years. TLPT simulates the behaviour of real attackers in the production environment and targets critical or important functions.

The value of testing lies in how findings are handled. Findings must be prioritised, remediation documented and its completion monitored.

Third-party risk and critical providers

Payment infrastructure increasingly relies on cloud services, software platforms and outsourced services. DORA does not prohibit outsourcing, but it emphasises that responsibility remains with the financial entity. The key obligations are:

Register of information: the entity must maintain a register of all its contractual arrangements for ICT services.
Contractual provisions: Article 30 of DORA sets out the minimum content of ICT service contracts, such as service descriptions, location information, availability requirements, audit rights and termination provisions.
Exit strategies: for critical or important functions, a plan must exist for switching provider or bringing the function back in-house.
Concentration risk: dependence on a single provider must be identified and assessed.

DORA also creates an oversight framework for critical ICT third-party providers. The European Supervisory Authorities published the first list of designated critical ICT third-party providers on 18 November 2025 and oversee these providers directly. Designation does not, however, remove the financial entity’s own responsibility for managing the risks.

In practice, DORA has meant for many entities a review of existing contracts and, where necessary, renegotiation. Large cloud and software vendors have often added financial-sector addenda to their standard contracts to cover the regulation’s requirements. The entity must nevertheless assess for itself whether the terms match its own risks and critical functions, as a standard addendum does not automatically guarantee adequacy.

Practical implementation in payment infrastructure

In payment services, resilience is directly visible to customers: if a payment fails or its status remains unclear, the impact is immediate. DORA’s principles should therefore be carried all the way down to the architecture. Key design principles are described in more detail in the technology area Transaction infrastructure.

Availability: an active-active architecture in which several sites or availability zones process traffic simultaneously.
Idempotency: safe retrying of payment requests after a disruption without duplicate charges.
Observability: metrics, logs and tracing that allow an incident to be detected and classified quickly, a precondition for meeting short reporting deadlines.
Exit plans: the technical feasibility of switching cloud provider or partially bringing services back, such as data portability and infrastructure as code.
Managing concentration risk: diversifying critical dependencies where this is justified and feasible.

Beyond architecture, resilience has to be rehearsed. Scenario-based exercises can simulate, for example, the loss of a cloud availability zone, the interruption of a connection to a clearing system or a disruption at a critical software vendor. Exercises often reveal gaps that are not visible in documentation, such as unclear responsibilities, missing contact details or overly optimistic recovery time estimates.

Checklist

The ICT risk management framework is documented and approved by the management body.
Critical and important functions and their dependencies have been mapped.
Incident classification criteria, responsibilities and report templates are in place.
The reporting process has been tested against the time limits.
A testing programme exists and the handling of findings can be tracked.
The register of information on ICT contracts is up to date.
Contracts for critical services contain the provisions required by Article 30.
Exit plans have been drawn up and their feasibility assessed.

Note

This checklist is a general aid. The exact content of the obligations depends on the entity’s type, size and services and must be confirmed against the regulation, the technical standards and guidance from the Finnish Financial Supervisory Authority.

Sources and further reading

Disclaimer

This guide has been prepared carefully from public sources, but regulation and service features change. Always check current information from official sources and the providers' own documentation. Corrections: support@brevixoo.com.