# Case Study: DORA Incident Reporting and Register Cleanup for a Payment Institution

Source: https://www.cyadviso.com/payment-institution-dora-incident-reporting-register-case-study
Last reviewed: 2026-05-05
Tags: Case Study, DORA, Incident Reporting

Anonymised payment institution case study: DORA incident reporting workflow, timestamp evidence, Register of Information cleanup and supplier escalation model.

---

**Last reviewed: 5 May 2026**

**Key takeaways**

- Payment institutions need incident reporting and Register of Information evidence that reflects their licensed services and ICT dependencies.
- DORA has applied since 17 January 2025, so case-study value comes from operating records, not readiness claims.
- Partners ask whether incident classification, supplier mapping and remediation can be shown quickly.
- Fastest path for a PI: map payment services -> classify ICT providers -> test incident workflow -> maintain an evidence index.

This is an anonymised engagement note for a payment institution. Client identity, jurisdiction, providers, systems and incident details are withheld. The note describes a remediation pattern, not a public supervisory outcome.

## Short answer

A payment institution needed two DORA evidence gaps fixed together:

- incident classification and reporting evidence;
- ICT third-party register quality.

Those two areas are connected. Many payment incidents involve suppliers, processors, cloud services, SaaS tooling or integration dependencies. If the supplier map is weak, incident classification is slower and final reporting becomes harder to defend.

## Client context

The client had payment operations, engineering, compliance and supplier-management processes in place, but they were not tightly connected.

The team could identify incidents and suppliers. The problem was evidence quality:

| Area | Weak pattern |
|---|---|
| Incident timeline | Detection, classification and approval timestamps not consistently preserved |
| Reporting decision | Major ICT incident rationale not recorded in a standard format |
| Supplier escalation | Provider notification paths varied by team |
| Register quality | ICT providers were not consistently linked to services and functions |
| Final reporting | Root cause and remediation evidence required manual reconstruction |

## Work delivered

The engagement combined incident reporting and Register of Information cleanup.

| Workstream | Output |
|---|---|
| Incident intake | Standard event intake and triage record |
| Classification | DORA major ICT incident decision tree and rationale template |
| Escalation | Internal and supplier escalation matrix |
| Timeline evidence | Detection, awareness, classification, approval and submission timestamp fields |
| Register cleanup | ICT provider list, service mapping and criticality rationale |
| Remediation | Action tracker linking incidents, suppliers and control gaps |

## Incident reporting model

The first design choice was to create one incident record with structured decision points.

| Decision point | Evidence retained |
|---|---|
| Detection | When the event was detected or became known |
| ICT relevance | Why the event is or is not ICT-related |
| Major classification | Criteria considered and decision owner |
| NCA route | Authority/channel to verify before filing |
| Supplier involvement | Provider, service, impact and notification status |
| Management escalation | Who was informed and when |
| Closure | Root cause, remediation and lessons learned |

The aim was not to automate every judgement. The aim was to stop important decisions from living only in chat messages and memory.

## Register cleanup model

The Register of Information work focused on operational usability, not only completion.

| Register field | Why it mattered |
|---|---|
| ICT service description | Shows what the provider actually does |
| Supported function | Links provider to payment operations and resilience |
| Criticality rationale | Explains why enhanced oversight is or is not needed |
| Contract owner | Makes remediation assignable |
| Technical owner | Supports incident escalation |
| Subcontractor note | Flags hidden dependency and concentration risk |
| Review date | Shows the record is current |

## What changed

The client gained a clearer operating link between incidents and suppliers.

After the engagement, the team could answer:

- Which provider supports the affected service?
- Is the affected function critical or important?
- Who owns escalation to the provider?
- Was the incident classified as major, and why?
- Which timestamps support the reporting decision?
- Which remediation actions remain open?
- Does the Register of Information need updating after the event?

That made the evidence stronger for DORA, partner-bank due diligence and internal management review.

## What was deliberately not claimed

This work did not guarantee that a future event would or would not be reportable. DORA incident classification depends on the facts of the incident and the applicable technical standards and local authority process.

The engagement created a better decision and evidence model so that classification can be made faster and defended more clearly.

## Reusable lessons

| Lesson | Practical impact |
|---|---|
| Incident logs need decision fields | Raw timelines are not enough |
| Supplier mapping speeds classification | Provider impact is often part of the facts |
| The Register should be event-aware | Incidents can reveal stale supplier data |
| Final reports need evidence from day one | Root cause and remediation cannot be reconstructed easily |
| Legal, compliance and engineering need one record | Parallel notes create contradictions |

## Related reading

- [DORA Incident Reporting 2026: Timeline, Classification and Evidence](/dora-incident-reporting)
- [DORA Register of Information: 2026 Guide for ICT Third-Party Risk](/dora-register-of-information)
- [DORA vs PSD2/PSD3: 2026 Guide for EU Payment Institutions and EMIs](/dora-vs-psd2-psd3)
- [DORA Business Continuity and Disaster Recovery: Articles 11-12 Guide for 2026](/dora-business-continuity-and-disaster-recovery)
- [DORA National Competent Authorities: Selected Jurisdiction Guides for EU Fintechs](/dora-national-competent-authorities)
- [See all CyAdviso case studies — EMI, PI and CASP engagement proofs](/case-studies)

## Primary sources

- [Regulation (EU) 2022/2554 — DORA, EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554)
- [European Banking Authority — Digital Operational Resilience Act](https://www.eba.europa.eu/activities/direct-supervision-and-oversight/digital-operational-resilience-act)
- [EBA — Joint Technical Standards on major incident reporting](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/joint-technical-standards-major-incident-reporting)

## FAQ

### Why combine incident reporting and Register cleanup?

Payment incidents often involve ICT providers. If provider records are incomplete, the team loses time identifying service impact, escalation owners, contract obligations and remediation evidence.

### Does this decide whether an incident is reportable?

No. Reportability depends on the incident facts, DORA classification criteria, technical standards and local authority process. The engagement creates the evidence model for making and recording that decision.

### What timestamps should be retained?

At minimum, retain detection or awareness time, classification time, internal approval time, authority submission time where applicable, supplier notification time and key remediation timestamps.

### What Register fields matter most for incidents?

Service description, supported function, criticality, contract owner, technical owner, provider contact route, subcontractor dependency and latest review date are especially useful during an incident.

### Is this only useful for DORA?

No. The same evidence helps partner-bank assurance, customer due diligence, internal audit, BCDR reviews and post-incident management reporting.

---

Authored by Andrey Gubarev — CISO for EU fintechs (CISM, CDPSE, SABSA).
CyAdviso · DORA / ICT risk / vCISO programmes for EU-licensed fintechs.
Canonical HTML: https://www.cyadviso.com/payment-institution-dora-incident-reporting-register-case-study