A cited-source comparison of DORA major ICT-related incident reporting and PSD2 major operational or security payment-related incident reporting.
Use it to separate which incident clock, report template, competent authority route, and evidence pack applies when a payment-service incident is also an ICT incident.
Since DORA became applicable on 17 January 2025, payment service providers within DORA report under DORA rather than the PSD2 Article 96 incident-reporting route. The same event may also be a major ICT-related incident, but the two classifications have separate definitions and must be recorded separately.
Side-by-side comparison
DORA major ICT-related incident reporting vs PSD2 payment-incident reporting
Use these rows to decide whether an incident belongs in the DORA incident-reporting chapter, a payment-incident analysis, or both evidence labels inside one coordinated incident file.
DORA covers financial entities and requires major ICT-related incidents to be classified, reported to the relevant competent authority, and handled through DORA report stages and templates.
Second framework
PSD2 operational or security payment incidents
For DORA-scoped payment service providers, DORA states that PSD2 incident reporting ceases and that operational or security payment-related incidents are handled under the DORA reporting chapter.
DORA major ICT-related incident reporting vs PSD2 payment-incident reporting
Financial entities under DORA, including payment institutions, electronic money institutions, account information service providers, credit institutions, and other listed financial entities when an ICT-related incident affects their services, operations, clients, counterparts, data, or critical functions.
Payment-service operational or security incidents for payment service providers. For payment service providers that are within DORA, the supported rule is that PSD2 incident reporting gives way to DORA reporting for those incidents.
For a DORA-scoped payment service provider, classify the incident under DORA first and preserve a payment-related incident label where the facts show payment-service operational or security impact.
DORA uses the financial-entity scope in Article 2 and Article 23. The payment-service fallback matters only for credit institutions, payment institutions, account information service providers, and electronic money institutions that are inside DORA.
DORA states that the PSD2 Article 96 reporting requirement ceases for payment service providers that fall within DORA. It does not establish a universal replacement rule for every entity or every national notification connected with payment services.
Confirm the entity's DORA status and the competent authority's current filing route. If DORA does not displace a requirement, check the applicable national PSD2 implementation and any separate sectoral notification duty rather than assuming a legacy form still applies unchanged.
DORA has specified clocks: initial report as early as possible, within four hours after major classification and no later than 24 hours after awareness; intermediate report within 72 hours after the initial notification; final report within one month after the intermediate report or latest updated intermediate report.
The former PSD2 route used its own major operational or security incident analysis under Article 96 and EBA guidance. For DORA-scoped payment service providers, the DORA classification RTS and reporting RTS now control the Union-level incident report.
Use the DORA clock for in-scope payment service providers. Keep the awareness time, major-classification time, submission times, threshold calculations, estimates based on comparable periods, and any delay explanation in the incident file.
DORA uses standard templates for initial, intermediate, and final reports, with data fields completed according to the reporting stage and submitted through the secure electronic channels made available by the competent authority.
DORA removes PSD2 Article 96 reporting only for payment service providers within DORA. Other reporting duties, including national, prudential, data-protection, law-enforcement, or customer-communication duties, require their own legal analysis.
Build the regulator report around the DORA template when DORA applies, then record every additional notification separately with its own trigger, recipient, deadline, and submission evidence.
Keep DORA classification evidence, incident logs, affected clients and transactions, downtime, Member State impact, data-loss assessment, critical-service impact, cost and loss estimates, business-continuity activation, report templates, and final root-cause and remediation evidence.
Where DORA does not displace a payment-services reporting duty, keep the entity-scope analysis, payment-service impact, applicable national PSD2 provision, current authority instructions, and submission evidence.
Use shared facts, but label each item. One incident file can support both views only if it shows the DORA classification basis and the payment-service impact separately.
DORA reports go to the relevant competent authority. Where an entity is supervised by more than one national competent authority, Member States designate a single competent authority for Article 19 reporting. Significant credit institutions report to the national competent authority, which transmits the report to the ECB.
Where DORA does not displace a payment-services reporting duty, the applicable national PSD2 implementation and competent-authority instructions determine the filing route and timing.
Do not send duplicate DORA reports merely because an entity has multiple authorisations. Confirm the relevant DORA competent authority and separately identify any surviving national or sectoral notifications.
PSD2 remains relevant outside the reporting requirement that DORA expressly displaces, and national law remains relevant to supervision and sanctions. The applicable authority and measure depend on the entity, breach, and Member State.
Tie each filing and control to its governing provision and competent authority. Do not infer that a DORA submission closes a different national or sectoral duty.
One incident can sit in both ICT and payment files, but DORA and PSD2 should not be treated as interchangeable. DORA Article 23 is a scope rule, not a blanket replacement for all payment incidents.
For a payment service provider within DORA, use the DORA reporting chapter for . If DORA does not displace a requirement, verify the national PSD2 rule and current authority instructions.
Decide entity scope, classify the incident under each applicable DORA category, and list any additional notification duties. Shared facts can be reused, but each legal conclusion needs its own evidence.
If the payment service provider is within DORA, classify the event as a payment-related incident and, separately, as an ICT-related incident. Report it when the applicable DORA major-incident test is met.
If DORA does not displace the reporting duty, determine the applicable national PSD2 rule, competent-authority guidance, form, and clock. Do not rely on a historic EBA process without checking its current status.
Financial entities under DORA, including payment institutions, electronic money institutions, account information service providers, credit institutions, and other listed financial entities when an ICT-related incident affects their services, operations, clients, counterparts, data, or critical functions.
Payment-service operational or security incidents for payment service providers. For payment service providers that are within DORA, the supported rule is that PSD2 incident reporting gives way to DORA reporting for those incidents.
For a DORA-scoped payment service provider, classify the incident under DORA first and preserve a payment-related incident label where the facts show payment-service operational or security impact.
DORA uses the financial-entity scope in Article 2 and Article 23. The payment-service fallback matters only for credit institutions, payment institutions, account information service providers, and electronic money institutions that are inside DORA.
DORA states that the PSD2 Article 96 reporting requirement ceases for payment service providers that fall within DORA. It does not establish a universal replacement rule for every entity or every national notification connected with payment services.
Confirm the entity's DORA status and the competent authority's current filing route. If DORA does not displace a requirement, check the applicable national PSD2 implementation and any separate sectoral notification duty rather than assuming a legacy form still applies unchanged.
DORA has specified clocks: initial report as early as possible, within four hours after major classification and no later than 24 hours after awareness; intermediate report within 72 hours after the initial notification; final report within one month after the intermediate report or latest updated intermediate report.
The former PSD2 route used its own major operational or security incident analysis under Article 96 and EBA guidance. For DORA-scoped payment service providers, the DORA classification RTS and reporting RTS now control the Union-level incident report.
Use the DORA clock for in-scope payment service providers. Keep the awareness time, major-classification time, submission times, threshold calculations, estimates based on comparable periods, and any delay explanation in the incident file.
DORA uses standard templates for initial, intermediate, and final reports, with data fields completed according to the reporting stage and submitted through the secure electronic channels made available by the competent authority.
DORA removes PSD2 Article 96 reporting only for payment service providers within DORA. Other reporting duties, including national, prudential, data-protection, law-enforcement, or customer-communication duties, require their own legal analysis.
Build the regulator report around the DORA template when DORA applies, then record every additional notification separately with its own trigger, recipient, deadline, and submission evidence.
Keep DORA classification evidence, incident logs, affected clients and transactions, downtime, Member State impact, data-loss assessment, critical-service impact, cost and loss estimates, business-continuity activation, report templates, and final root-cause and remediation evidence.
Where DORA does not displace a payment-services reporting duty, keep the entity-scope analysis, payment-service impact, applicable national PSD2 provision, current authority instructions, and submission evidence.
Use shared facts, but label each item. One incident file can support both views only if it shows the DORA classification basis and the payment-service impact separately.
DORA reports go to the relevant competent authority. Where an entity is supervised by more than one national competent authority, Member States designate a single competent authority for Article 19 reporting. Significant credit institutions report to the national competent authority, which transmits the report to the ECB.
Where DORA does not displace a payment-services reporting duty, the applicable national PSD2 implementation and competent-authority instructions determine the filing route and timing.
Do not send duplicate DORA reports merely because an entity has multiple authorisations. Confirm the relevant DORA competent authority and separately identify any surviving national or sectoral notifications.
PSD2 remains relevant outside the reporting requirement that DORA expressly displaces, and national law remains relevant to supervision and sanctions. The applicable authority and measure depend on the entity, breach, and Member State.
Tie each filing and control to its governing provision and competent authority. Do not infer that a DORA submission closes a different national or sectoral duty.
One incident can sit in both ICT and payment files, but DORA and PSD2 should not be treated as interchangeable. DORA Article 23 is a scope rule, not a blanket replacement for all payment incidents.
For a payment service provider within DORA, use the DORA reporting chapter for . If DORA does not displace a requirement, verify the national PSD2 rule and current authority instructions.
Decide entity scope, classify the incident under each applicable DORA category, and list any additional notification duties. Shared facts can be reused, but each legal conclusion needs its own evidence.
If the payment service provider is within DORA, classify the event as a payment-related incident and, separately, as an ICT-related incident. Report it when the applicable DORA major-incident test is met.
If DORA does not displace the reporting duty, determine the applicable national PSD2 rule, competent-authority guidance, form, and clock. Do not rely on a historic EBA process without checking its current status.
Practical triage rule for DORA and PSD2 incident reporting
Check whether the payment service provider falls within DORA and identify the relevant competent authority.
Classify the event separately as an operational or security payment-related incident and as an ICT-related incident; apply the relevant major-incident thresholds to each classification.
When DORA applies, use its report stages, time limits, template, and competent-authority submission route.
List any other national or sectoral notification duties and keep separate evidence for their triggers, recipients, clocks, and submissions.
PSD2 Article 96 was the EU-level payment-services incident-reporting route. DORA now brings major ICT-related incidents, voluntary significant cyber-threat notifications, and into its harmonised reporting chapter for the payment-sector entities listed in Article 23.
For a credit institution, payment institution, account information service provider, or electronic money institution within DORA, first decide whether the event is an operational or security payment-related incident and whether it is major under the DORA classification rules. Then assess separately whether it is also a major ICT-related incident. Do not assume that meeting one classification automatically meets the other.
DORA Article 17 requires an ICT-related incident management process that records incidents and significant cyber threats, assigns roles, escalates major incidents, and supports response and recovery.
DORA Article 18 sets classification criteria for ICT-related incidents, including affected clients or transactions, duration, geographical spread, data losses, criticality of affected services, and economic impact.
DORA Article 23 applies the reporting chapter to operational or security payment-related incidents concerning credit institutions, payment institutions, account information service providers, and electronic money institutions.
Delegated Regulation (EU) 2024/1772 requires a major incident to affect critical services and either meet the data-loss threshold or at least two of the other materiality thresholds. Teams must apply the regulation's detailed criteria and payment-specific fields to the actual facts.
DORA reporting is staged through an initial notification, an intermediate report, and a final report. Financial entities use the prescribed DORA template and the secure electronic channels made available by the competent authority.
The initial notification is due as early as possible, within four hours after classification as major and no later than 24 hours after awareness of the incident. The intermediate report is due within 72 hours after the initial notification, even if the incident has not recovered. The final report is due no later than one month after the intermediate report or, when an updated intermediate report was submitted, no later than one month after the latest update.
Initial notification: incident reference, detection and classification information, description, classification criteria, impacted Member States, discovery route, origin where available, business-continuity activation, and reclassification information where applicable.
Intermediate report: occurrence and recovery timing, classification detail, incident type, threat techniques where applicable, affected business processes and infrastructure, client financial impact, other-authority reporting, temporary recovery measures, and indicators of compromise where applicable.
Final report: root causes, resolution timing, permanent resolution, resolution-authority information where applicable, direct and indirect costs and losses, recoveries, and recurring-incident information where applicable.
A payment incident can share facts with an ICT incident, but the evidence labels should stay separate. ICT classification evidence must show how DORA Article 18 and Delegated Regulation (EU) 2024/1772 were applied. Payment-incident evidence must show why the event affected the availability, authenticity, integrity, or confidentiality of payment-related data, systems, or services, and how the payment-specific major-incident test was applied.
Keep enough evidence to explain both the incident decision and the report content: logs, service downtime records, transaction impact, affected clients or financial counterparts, Member State impact, data-loss analysis, business-continuity activation, customer communications, other-authority reporting, root-cause analysis, remediation, and cost or loss estimates.
Label whether the incident was classified as a major ICT-related incident, a major operational or security payment-related incident, both, or neither.
Record the awareness time, classification time, report submission times, any delay explanation sent to the competent authority, and any reclassification from major to non-major.
Keep the template fields and source citations with the incident file so later reviewers can see why each reported field was required.
Turn this comparison into a report-ready incident workflow
Sorena can help structure DORA incident classification, payment-incident triage, report-stage evidence, and source citations for teams preparing regulator-facing incident records.