DORA incident reporting
Under DORA a major ICT incident goes to the supervisor in three reports, and the first clock starts the moment the firm classifies the incident as major. The hard part is not the filing but the classification: the test has thresholds with numbers in them, and the answer decides whether a 90-minute outage is a report or a log entry. DORA in Germany covers the regulation; the subject here is the test, the deadlines and the German route.
The classification test, with its thresholds
An incident is major when it affects critical services and either the data losses threshold is met on its own, or two or more of the other thresholds are met at the same time. Commission Delegated Regulation (EU) 2024/1772 sets them out, and the numbers are specific: more than 10 percent of the clients using the affected service or more than 100,000 clients; more than 30 percent of financial counterparts; more than 10 percent of the daily average number or value of transactions.
The remaining criteria follow the same pattern. Duration longer than 24 hours or service downtime longer than two hours for a service supporting a critical function. Geographical spread into two or more member states. Economic impact, meaning costs and losses above 100,000 euros. Reputational impact, which includes media coverage and repetitive complaints from different clients. Data losses count where there was an adverse effect on compliance or business objectives, or a successful unauthorized access.
The three reports and the clock on each
Article 19 of DORA requires an initial notification, an intermediate report and a final report. The initial notification is due within four hours of the firm classifying the incident as major, and in any case no later than 24 hours after it became aware of the incident. Slow classification buys no time, because the 24-hour limit runs from awareness.
The intermediate report follows within 72 hours of the initial notification, and it goes in even when nothing has changed, with a further intermediate report whenever the status changes materially. The final report is due no later than one month after the latest intermediate report and carries the root cause, the remediation and the actual impact. A firm whose incident is still open at the one-month mark files the final report when the analysis is complete and keeps the supervisor informed in the meantime.
Where the report goes in Germany
In Germany the reports go to BaFin, through its reporting platform MVP, in the templates the implementing standards set. The forms are structured, so the content a firm can supply in the first hours determines what it can file, and firms that prepare the field list in advance spend the first four hours on the incident instead of on the form.
The practical consequence is organizational. The decision that an incident is major cannot wait for a committee, so it is delegated to a named role with written criteria, and the ICT incident process carries a route to the reporting function that runs at night and on weekends. Cybersecurity in German finance covers the threat picture behind these reports.
Recurring incidents that add up to a major one
A single short outage may sit below every threshold while the same fault recurring weekly does not. DORA requires recurring incidents that are individually minor to be assessed together where they have the same apparent root cause, and the aggregate can meet the classification test even though no single occurrence did.
This is the case firms miss, because each occurrence closes in the incident system before anyone adds them up. The control is a periodic review of closed incidents grouped by root cause, which also produces the evidence a supervisor asks for when it wants to know why an obvious pattern was never reported.
Significant cyber threats, reported voluntarily
Article 19(2) of DORA allows a firm to notify the competent authority of a significant cyber threat where it considers the threat relevant to the financial system, to service users or to clients. The notification is voluntary and there is no deadline attached to it.
What makes it useful is the direction of travel. A threat one firm sees early, a campaign targeting a specific core banking product or a compromised supplier, reaches the authority before it becomes several incidents. Firms that use the channel also tend to receive the sector picture back, which is the practical argument for using it.
Telling the clients
Article 19(3) of DORA requires the firm to inform its clients without undue delay where a major ICT incident has or may have an impact on their financial interests, and to tell them what measures have been taken to mitigate it. This duty is separate from the supervisory report and runs on its own judgment of client impact.
The wording of that message is prepared in advance for the same reason as the report template. A firm drafting customer communication during an outage produces either silence or a statement it later corrects, and both are the kind of reputational impact that counts toward the classification thresholds.
Payment incidents and the PSD2 route
Payment service providers had an operational incident reporting duty before DORA, under the EBA guidelines on major incident reporting under PSD2. DORA's regime replaced that reporting for the incidents in its scope, so a payment institution now files the ICT incident under DORA and does not duplicate it.
What remains separate is the content specific to payments: the transaction volumes affected, the payment instruments involved and the clearing or settlement consequences. Payments regulation in Germany covers how the supervisory duties for a payment institution fit together.
One event, three notifications: NIS2 and GDPR
A ransomware attack on a German bank can trigger three duties at once. DORA requires the ICT incident report to BaFin. Where personal data was affected, Article 33 of the GDPR requires notification to the data protection authority within 72 hours. And an entity in scope of the NIS2 implementation has its own reporting line with a 24-hour early warning.
The three have different addressees, different clocks and different content, and DORA applies as sector-specific law where it overlaps. The way firms handle it is one incident record that produces three outputs, instead of three teams reconstructing the same timeline.
What counts as a major ICT-related incident under DORA?
An incident affecting critical services where either the data losses threshold is met, or two or more of the other materiality thresholds are met together. Those thresholds are set in Commission Delegated Regulation (EU) 2024/1772 and cover clients and transactions affected, reputational impact, duration over 24 hours or critical-service downtime over two hours, spread into two or more member states, data losses, and costs and losses above 100,000 euros.
What are the DORA reporting deadlines?
Four hours from classifying the incident as major for the initial notification, and in no case later than 24 hours after becoming aware of the incident. 72 hours after the initial notification for the intermediate report, filed even if nothing has changed. One month after the last intermediate report for the final report, with the root cause analysis and the actual impact.
Does a near miss have to be reported?
No. An incident that did not affect critical services and crossed no threshold stays in the firm's own records, and DORA expects it to be recorded there. Two things change that: a near miss that recurs with the same root cause can aggregate into a major incident, and a significant cyber threat may be notified voluntarily under Article 19(2) even though nothing happened yet.
DORA incident reporting and Finance Loop
Finance Loop is the meeting place for the people who classify and file these reports in German finance. Finance Loop events bring ICT risk, incident response and compliance together with the BaFin and Bundesbank staff who read the same reports on the other side.
Finance Loop is a professional network and has the goal of driving the adoption of emerging technologies in finance, such as AI, tokenization, stablecoins, and DeFi. Finance Loop helps its members build skills and personal networks in these fields: Investment & Digital Assets, Payments & Digital Money, Digital Infrastructure & Sovereignty, and Risk & Compliance.