Article 23 DORA payment-related incident reporting: evidence

What Article 23 changes for payment-related incident reporting under DORA

Under Article 23 of DORA, credit institutions, payment institutions, account information service providers and electronic money institutions that used to report payment incidents under PSD2 now run those reports through DORA's Chapter III incident process. The extension covers operational or security payment-related incidents, and it applies to the major ones. Directive (EU) 2022/2556 added Article 96(7) to PSD2, so the PSD2 incident reporting rules in Article 96(1) to (5) no longer apply to providers covered by DORA. For a payment or e-money institution, the practical change is that the old PSD2 form and timetable give way to DORA's classification, materiality and reporting steps. Confirm your entity's category in Article 2(1) with your national competent authority before you map your existing procedures.

The main difficulty is that one regime now covers two kinds of event. ICT-related incidents, such as a failed core banking service caused by a software fault, sit alongside non-ICT operational or security payment incidents, such as a processing error in a manual reconciliation step or a fraud event that does not originate in a system component. Both must be recorded, classified and, where major, reported under the same process. Your incident procedures should therefore name the payment incidents that fall under Chapter III, define who decides whether an event is payment-related, and state how the materiality thresholds in Delegated Regulation (EU) 2024/1772 apply to payment events. Ask your competent authority which thresholds it expects you to apply to non-ICT payment incidents.

Two actions follow for the incident owner. First, update the incident register and tooling so that payment-related fields, such as the affected payment service, the transaction volume and the channel, are captured at detection and not reconstructed later. Second, check that your case management can produce the initial notification, intermediate and final reports from one record. Open-source case management such as DFIR-IRIS can hold assets, indicators, tasks, evidence and a timeline in a single case with an audit trail, which helps when the same payment incident must be explained under one regime. Have your team test the workflow against an illustrative payment outage before the first real report is due.

Which payment entities and incidents Article 23 reaches

Article 23 extends the Chapter III incident regime to operational or security payment-related incidents at four entity types. The cards below cover who falls in scope, what counts as a payment-related incident, how non-ICT failures are captured, and which internal teams and third parties must feed the process.

Credit institutions in scope

Article 23 reaches credit institutions covered by Article 2(1)(a), including banks that execute payment services. Check whether a payment flow runs through a credit institution's own licence or through a regulated payment service provider the bank serves. Map each licensed activity to the entity that holds it, because the reporting obligation follows the legal entity, not the group brand. Confirm this with your legal and regulatory team before building the process.

Payment institutions and e-money institutions

Article 2(1)(b) and (c) cover payment institutions and electronic money institutions. Many fintechs hold one licence for several payment services, so every service line should be inventoried against the incident process. An e-money issuer that also offers payment initiation should confirm which incidents it classifies under the payment regime and which fall under the general ICT regime. Document that decision in the scope record.

Account information service providers

Article 2(1)(d) brings account information service providers into scope. These firms often hold no payment funds, so their incidents tend to involve data access, consent flows and API availability rather than settlement. Check how consent failures, failed account data pulls and unauthorized access attempts are logged, and whether they meet the materiality thresholds in Delegated Regulation (EU) 2024/1772.

Payment-related incidents defined

Article 23 covers operational or security payment-related incidents, whether or not they stem from ICT. A payment-related incident is one that affects the initiation, execution, clearing, settlement or confirmation of a payment service, or the security of the data and access behind it. Write this definition into your incident policy so that a failed batch file, a misrouted transfer and an intrusion into a payment API each get a clear classification path.

Non-ICT operational failures in payment flows

Because the regime covers payment incidents whether ICT-related or not, a manual keying error, a staffing gap at a clearing desk or a failed courier-delivered settlement file can be in scope. These events rarely appear in SIEM or ticketing data. Set up a path, such as a payment operations log feeding the incident register, so that non-ICT failures are recorded and assessed the same way as system outages.

Payment operations and fraud teams

Payment operations, fraud monitoring and customer support usually see a payment problem first. Their alerts, customer complaints and reconciliation breaks are early indicators that the incident process needs. Agree in writing which team logs what, within what time, and who decides whether the event is an incident. Without this handoff, the classification clock may start late.

Payment processors and ICT providers

Card processors, core banking vendors, cloud hosts and payment gateways often detect a fault before the regulated entity does. Contracts should require them to notify the entity of incidents affecting payment services, to provide the data needed for classification and to support the reporting timeline. Confirm these notification terms with each provider and record them in the register of information where the service supports a critical or important function.

How payment institutions bring incident handling into the DORA regime

This sequence takes a payment institution from an inventory of its payment services to a tested process that classifies and reports operational or security payment-related incidents under the DORA incident chapter, replacing PSD2 reporting for those incidents.

Map payment services and their supporting systems
Start by listing every payment service the institution provides and the ICT systems, interfaces, databases, networks and third-party services that carry each one, from customer onboarding and authentication to settlement and reconciliation. Assign an owner to each service and link it to the critical or important functions and the ICT asset inventory already held under the ICT risk framework. The output is a payment service map that shows which systems, if disrupted, would produce an operational or security payment-related incident. Confirm the map with business owners before the next step.
Extend the Article 17 process to payment incidents
Update the ICT-related incident management process so it explicitly covers operational or security payment-related incidents, not only ICT incidents. Add payment-specific detection sources, such as payment gateway logs, fraud monitoring alerts and customer complaint channels, and confirm who receives them. Record the change in the incident management policy and the procedure that staff follow. The output is an approved revised process that names payment incidents in its scope and triggers.
Build a payment-related incident register
Create a single register in which every operational or security payment-related incident is logged, including incidents that prove not to be major. Each entry should record the affected payment services, the detection time, the systems involved, the clients and counterparties affected, and the classification decision. Access rights and retention should follow the institution's record-keeping rules. The output is a working register with a defined template, which later serves as the evidence base for reports and for supervisory review.
Classify incidents against the materiality thresholds
Apply the classification criteria and materiality thresholds set in Delegated Regulation (EU) 2024/1772 to decide whether a payment-related incident is major. Document the classification steps in a procedure that states who makes the decision, what data is needed, and how borderline cases are escalated to the management body or a designated senior officer. Test the procedure against a few past or hypothetical cases labeled as illustrative. The output is a written classification procedure and a record of each decision in the register.
Assign reporting roles and timelines
Name the people responsible for initial notification, intermediate and final reports, communication with affected payment service users, and liaison with the competent authority. Map each role to a backup and to the approval chain. Confirm the reporting timelines and report content against the current regulatory technical standards and the competent authority's instructions, since these are not restated here. The output is a responsibility matrix and a reporting calendar that the team can follow under time pressure.
Write the reporting playbook
Turn the classification procedure and role matrix into a step-by-step playbook covering detection, triage, classification, notification, report drafting, approval, submission and post-incident review. Include templates for each report stage, a contact list for the competent authority channel, and the points where the legal or compliance function must sign off. Ask the competent authority which submission channel and format it requires. The output is an approved playbook stored where on-call staff can reach it.
Test the process end to end
Run tabletop exercises and at least one simulated payment incident through detection, classification, reporting and post-incident review. Record timings, gaps, unclear decision points and any reporting content that could not be completed from the register. Fix the gaps, update the playbook and retest the changed steps. The output is an exercise report with findings, owners and due dates, plus evidence that the revised process worked. An independent assessor will look for this evidence, but the institution owns the conclusions.

Who owns Article 23 work in the organization, the partner and the auditor

The payment institution, credit institution, account information service provider or electronic money institution remains the legal owner of its reporting obligations. Its management body approves the incident management policy, sets the materiality judgment that feeds classification, and accepts the risk of any gaps. Compliance and operational risk teams decide whether a payment-related incident is operational or security related, record the timeline, and submit reports to the competent authority within the deadlines in the regulatory technical standards.

Policy and accountability: Approve the incident management process, name the owner for each reporting decision, and record who may classify an incident as major.
Classification decisions: Apply the criteria and thresholds in the regulatory technical standards and document the reasoning behind each judgment, including decisions not to report.
Reporting submissions: Own the initial, intermediate and final reports and confirm that the content matches the internal record.
Governance review: Review incident trends, post-incident lessons and open actions at management level.
Regulator relationship: Own correspondence with the competent authority and any follow-up requests.

Before engaging any partner, confirm internally who signs each report and who can be reached out of hours.

How an assessor tests Article 23 incident handling

This table compares what an assessor samples, checks and asks for when testing payment-related incident handling under Article 23, with the usual gaps found in each area. Read each row as a test the assessor will run, the evidence to have ready, and the point where organizations most often fail. The main takeaway is that assessors test the chain from detection through classification to notification, so the records must agree at every step.

Test area	What the assessor checks	Evidence requested	Common findings
Sampling of payment incidents	Whether the sample covers operational and security payment-related incidents across the in-scope services, including minor events that were closed without reporting	Full incident log extract for the review period, with the sampling basis documented by the assessor	Logs that hold only escalated incidents, so low-severity payment events are missing from the population
Register comparison against PSD2 legacy records	Whether incidents previously reported under PSD2 Article 96 now sit in the DORA process, and whether any old reporting channel is still in use	Legacy PSD2 incident reports, the DORA incident register, and a reconciliation showing how each record maps across	Duplicate or missing entries after the switch, and legacy reporting routines that continued without a documented decision
Classification against 2024/1772 thresholds	Whether each sampled payment incident was assessed against the materiality thresholds in Delegated Regulation (EU) 2024/1772 and the classification criteria, with reasons recorded	Classification worksheets, threshold assessments, and approvals by the person responsible for incident classification	Classification decided without a recorded threshold check, or threshold results that do not match the figures in the incident record
Timeliness of notifications	Whether initial, intermediate and final notifications for major incidents were sent within the deadlines set by the applicable rules, and whether the clock start is recorded	Timestamps for detection, classification and each submission, plus the notification approval trail	Clock start recorded inconsistently, or a notification sent late without a documented reason or escalation
Recurring and linked incidents	Whether repeated payment incidents are linked, aggregated where the rules require, and reviewed for root cause	Incident linkage records, root cause analyses and management reporting for the period	Recurring incidents treated as unrelated one-off events, so the aggregated picture never reaches management
Roles and approvals	Whether named roles own classification and reporting decisions for payment incidents, and whether those roles are trained and reachable	Role descriptions, RACI or equivalent, approval records and training attendance for incident staff	Responsibilities split between payment operations and the ICT function with no single accountable owner
Audit trail and record integrity	Whether records of payment incidents are complete, time-stamped and protected from unauthorized change	Case history with change logs, access records for the incident platform, and evidence handling records where forensics were used	Edits to closed incident records without a log entry, or exports that differ from the source system

Evidence that shows payment incidents are handled under DORA

Article 23 brings operational and security payment-related incidents into the same incident chapter as ICT incidents, so one set of records has to show both. The artifacts below connect: the register captures every event, classification shows why it was or was not major, submissions prove the reporting clock was met, and reviews and retention show the process learns and can be replayed.

Unified incident register

A single register that records every operational or security payment-related incident alongside ICT-related incidents, with the date detected, the affected payment service, the entity concerned and the owner. Article 23 means a payment incident that is not ICT-related still belongs in the same record, so assessors will look for gaps where payment events were logged in a separate ticketing queue. Check monthly that both categories flow into one place and that no payment event exists only in an email thread.

Classification records with reasoning

For each payment incident, a classification record that states the criteria applied, the evidence used, the decision on whether the incident is major, and the approver. The materiality thresholds that decide major status are set in Delegated Regulation (EU) 2024/1772, so the record should cite the threshold tested, not just the outcome. Re-check classifications when new facts emerge, because an incident first judged minor can become major as impact becomes clear.

Reporting submissions and acknowledgements

Copies of each initial notification, intermediate report and final report sent to the competent authority, together with the acknowledgements or reference numbers returned. For payment incidents, the authority may share major incident details with the ECB where the entity is a credit institution, payment institution or electronic money institution. Keep a log of who submitted each report, when, and through which channel, so the timing can be reconstructed. Confirm with your competent authority which submission channel and format it currently accepts.

Post-incident reviews and root cause follow-up

A written review for each major payment incident covering the timeline, root cause, control failures, customer and service impact, and the corrective actions with named owners and due dates. Assessors test whether lessons feed back into the ICT risk framework and into payment controls, not just whether a review exists. Track each action to closure and record why any action was closed without a fix. Reviews for significant or recurring incidents should be reopened when related events occur.

Evidence case files with audit trail

Case files that hold the alerts, logs, screenshots, communications and analysis for each incident, with a verifiable record of who accessed or changed each item. Open-source case management tools such as DFIR-IRIS keep assets, indicators, tasks and evidence in one case record with an audit trail, and log evidence with SHA-256 verification and chain of custody. Confirm that your chosen tool exports case data in a form your reporting team can use, and test that you can produce a case file on request.

Retention schedule and access controls

A written retention schedule that states how long incident records, submissions and case files are kept, where they are stored, who can read or amend them, and how deletion is authorized. Retention must cover the period in which the competent authority may ask questions, so confirm the required period with your authority and your national law rather than relying on a default. Review the schedule each year, test a restore of archived cases, and confirm access logs are kept for the same period.

How a payment incident moves from detection to a major report

For a credit institution, payment institution, account information service provider or electronic money institution, the path from a suspicious event to a regulator report runs through the same Chapter III machinery that governs ICT incidents, so the first decision is whether an event is an operational or security payment-related incident at all. The trigger can be a monitoring alert from the payment gateway, a failed settlement batch, a fraud team escalation or a complaint from a payment service user. Each of these should land in one intake queue with a timestamp, the affected payment service, the channel and the person who first recorded it. Confirm with your own legal and compliance team which payment flows fall inside scope, because Article 23 covers operational and security payment-related incidents whether or not they are ICT-related, and an incident that never touches an ICT system can still need a report.

Once an event is logged, the classification step decides whether it is major, and this is where the reporting clock starts to matter. Assign an incident owner, record the affected services and clients, and apply the materiality thresholds set in Delegated Regulation (EU) 2024/1772 to decide whether the event crosses them. The payment system and the case record should be separated by a clear trust boundary. The payment platform stays the system of record for transactions and is not edited during triage. Alerts and observations are copied into a separate case management record, which holds the investigation timeline, tasks and evidence. Only named analysts can write to the case, and every change should be attributable. Open-source case management tools such as DFIR-IRIS can hold this record, but you must confirm how your deployment handles access control and retention before relying on it.

Escalation and reporting then follow your documented process. A major classification triggers senior escalation, and the initial notification, intermediate report and final report are prepared from the same case data so that figures stay consistent across filings. Ask your competent authority which template, channel and deadlines apply to payment-related incidents, since the Article 23 route and the national practice may differ from the ICT route described in Article 19. Test this flow with a tabletop exercise before you need it, and record who signed off each submission. Where a third party runs parts of the payment chain, agree in advance how its logs and incident details reach your case record in time to meet the deadlines.

What meeting Article 23 costs in money and effort

This table lists the cost components of extending DORA incident handling to payment-related incidents, who is paid for each, and whether it is one-time or recurring. Read it as a checklist for a quote: the drivers column shows what moves each cost up or down. Figures are not supplied here, so ask each provider for a written scope before comparing.

Cost component	Who is paid	One-time or recurring	What drives it
Tooling or licenses	Software vendor or subscription provider	Recurring	Number of payment services in scope and seats for analysts. Self-hosted open source can remove license spend but not hosting or support.
Logging and case management engineering	Internal engineers or implementation partner	One-time, with occasional rework	Number of payment channels, log sources and systems that must feed one record of each payment-related incident.
Process design for payment incident classification	Internal risk and operations staff, or a consultant	One-time, then periodic review	How many payment flows the institution runs and how often thresholds in the technical standards are reviewed.
Evidence upkeep	Internal compliance or operations staff	Recurring	Incident volume, number of reporting entities in a group, and how often records must be reconciled for reports.
External review of procedures	Independent reviewer or advisor	Periodic	Complexity of the payment estate and whether the procedures have changed since the last review.
Competent authority supervision and sampling	Internal staff time to produce records on request	Recurring, driven by supervisory activity	Quality of the incident register and whether records can be produced quickly with audit trails.
Operational time during incidents	Internal responders, plus any outsourced support	Recurring with each incident	Incident frequency, severity, and whether reporting roles are staffed around the clock.

How DFIR-IRIS supports payment incident records

DFIR-IRIS is an open-source case management tool that can hold the working record of a payment-related incident from first alert to final report. The cards below cover what the tool does, where it fits in the Article 23 workflow, and what it cannot do on its own.

One case record per incident

DFIR-IRIS keeps each case as a single record that links affected assets, indicators of compromise, tasks and evidence. For a payment incident, this gives the team one place to show which payment systems, accounts or service providers were touched. Confirm that the fields you need for payment-specific assets exist in your configuration, or plan how to add them.

Alert triage from connected sources

The platform can triage alerts from SIEM, EDR and REST sources into cases. Routing alerts from payment switches, card processing platforms and fraud tooling into cases helps capture an incident's start time. Check which sources your environment can feed and how duplicate alerts are grouped before relying on the intake.

Consolidated investigation timeline

A consolidated timeline puts detection, containment, customer impact and notification events in one sequence. Article 23 reporting depends on being able to show when the incident was detected and how it developed. Ask who owns timeline entries and whether the team's notification steps are recorded in the same case.

Evidence with SHA-256 chain of custody

DFIR-IRIS logs evidence with SHA-256 verification and chain of custody, so a file can be shown to be unchanged since collection. This matters when logs from payment platforms may be requested by a competent authority. Confirm the retention and access rules for evidence in your own environment, because the tool records custody but does not set your policy.

Reports generated from case data

The platform can generate reports from case data, which reduces retyping when preparing incident summaries for management and reporting drafts. Reports are only as complete as the case record, so review each generated document against the source entries before it leaves the organization. Your reporting template and sign-off roles remain your responsibility.

Supporting evidence, not compliance

DFIR-IRIS helps produce records that support Article 23 obligations, but installing it does not satisfy the requirement. The competent authority assesses your incident process, classification and reporting. Before adoption, confirm the fit with your environment, hosting model and security team, and check the documentation for current capabilities.

Where payment institutions fall short on Article 23

Do payment incidents have to go through the DORA incident process?

Yes. Article 23 applies the Chapter III incident requirements to operational or security payment-related incidents at credit institutions, payment institutions, account information service providers and electronic money institutions, and it covers major ones specifically. Many teams keep payment incidents in a fraud or payments operations queue that never reaches the ICT incident register, classification or management reporting. To close this gap, route payment-related alerts, failed transfer complaints and card authorization outages into the same intake as other ICT incidents. Assign each one a classification under the criteria in Delegated Regulation (EU) 2024/1772, and record who decided whether the event is major. Confirm with your competent authority how it expects payment queues to link to the main process.

Can we keep reporting payment incidents under PSD2 after DORA applies?

No, not for entities that DORA covers. Directive (EU) 2022/2556 added Article 96(7) to PSD2, so the PSD2 incident reporting in Article 96(1) to (5) does not apply to payment service providers covered by DORA. These firms have one regime for all operational or security payment-related incidents, whether ICT-related or not. The gap usually appears when legacy PSD2 templates, mailboxes and runbooks keep running beside the DORA process, so one event is reported twice or in the wrong format. To close it, retire the PSD2 procedure, map each legacy template field to the DORA reporting content, and tell your competent authority which channel you now use. Keep historical PSD2 records for the periods they cover, and confirm retention periods with your legal team.

Do non-ICT payment failures fall under DORA reporting?

They can. Article 23 covers operational or security payment-related incidents whether or not they are ICT-related, so a failure caused by a manual reconciliation error, a correspondent process breakdown or a staff action may fall in scope. Teams often search only their ICT ticketing system, so these events never receive a classification. To close the gap, define in the payment incident procedure what counts as operational or security for each payment flow. Add a non-ICT category to the intake form and require the same classification fields used for ICT incidents. Test the procedure with an illustrative case, such as a batch of payments released twice after a manual override, and confirm that it reaches the same review and sign-off.

What timeline evidence do auditors and supervisors expect for payment incidents?

They expect a record showing when the incident was detected, classified, escalated and reported, with each time drawn from a system rather than memory. Reporting deadlines in Article 19 and the technical standards run from defined points, so an unsupported start time can make a timely report look late. Common gaps include handwritten timestamps, time zone mismatches between payment switches and ticketing tools, and no record of when a classification changed. To close them, use a case record with an audit trail, capture each source timestamp in UTC, and keep the export with the report. Open-source case tooling such as DFIR-IRIS keeps an audit trail and builds an investigation timeline from case data. Confirm that it fits your retention and access rules in the DFIR-IRIS documentation.

Who is accountable for reporting a major payment incident?

The financial entity remains accountable for reporting, even if part of the work is outsourced. Competent authorities then share details of major incidents at credit institutions, payment institutions and electronic money institutions with the ECB under Article 19(6)(b). The gap is often an unnamed owner, so a payments lead assumes IT will file and IT assumes the business will. To close it, name one accountable role for the initial notification, intermediate report and final report, and write down who approves each submission. If an outside party drafts reports, keep the approval step inside your organization and record the sign-off with the incident file.

How much does it cost to close these Article 23 gaps?

The cost depends on how many payment channels, systems and legacy PSD2 procedures your organization runs, and on how much of the work your own staff can absorb. Costs fall into three groups: internal staff time for procedure and classification decisions, engineering time to integrate intake, case records and timeline capture, and any outside help for scoping and testing. Some items are one-time, such as retiring PSD2 runbooks and building the intake. Others recur, such as classification reviews and evidence exports after each incident. Ask any provider for a quote built from a written scope that lists the payment flows, systems and deliverables included. No published figure applies to every institution, so confirm the scope before comparing quotes.

Can DeployOpen set up payment incident handling for our self-hosted systems?

DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Article 23 work, that can include routing payment-related events into a case platform, setting up case records and timeline capture, and updating incident runbooks. DeployOpen prepares systems and evidence, but it does not issue audit reports, attestations or certifications, and it does not decide whether an incident is major or file reports for you. Those decisions stay with your organization, and your competent authority or independent assessor reviews the result. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How DeployOpen prepares payment incident handling for DORA

DeployOpen works on the systems and records that a payment institution, e-money institution, credit institution or account information service provider uses to handle operational or security payment-related incidents under Article 23. We plan, implement and document self-hosted open-source platforms inside your own infrastructure, so the incident process and its evidence sit where your organization can control them.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope names which payment services, entity types and incident sources the Article 23 process covers.
We confirm which incidents count as operational or security payment-related incidents under your own classification procedure.

How we build

We implement a self-hosted case management platform for payment incident records, assets, tasks and timelines.
We connect alert sources such as SIEM, EDR and payment platform logs so incidents are triaged into one case record.
We configure evidence logging with hashing and chain of custody so incident records stay verifiable for reviews.

How we hand over

You receive documented procedures for detection, classification, escalation and reporting roles for payment incidents.
We deliver runbooks and test records showing how the platform supports initial, intermediate and final report preparation.
Handover includes access control, backup and upgrade notes, so your team can operate the platform after the engagement ends.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover platform maintenance, changes to classification criteria and periodic review of the incident process.
Confirm with your competent authority which reporting channels and formats apply before finalizing reporting templates.