Every financial entity already handles incidents. What DORA changes is the reporting: a defined test for when an incident is major, a fixed sequence of reports to the competent authority, and deadlines short enough that the classification decision has to be made while the incident is still running.
The failure mode is predictable. The technical response goes well, and the reporting starts late because nobody was sure whether the incident qualified, or who was allowed to decide.
This article covers DORA's incident chapter, Articles 17 to 23: what counts as a major ICT-related incident, how classification works, the three reports, what you need from your ICT providers, and a runbook that holds up under time pressure.
What DORA means by a major ICT-related incident
DORA defines an ICT-related incident as a single event, or a series of linked events, unplanned by the financial entity, that compromises the security of network and information systems and has an adverse impact on the availability, authenticity, integrity or confidentiality of data, or on the services the entity provides.
A major ICT-related incident is one with a high adverse impact on the network and information systems that support critical or important functions. Only major incidents must be reported. Every incident must still be recorded.
Article 18 sets the criteria for classifying incidents:
The number or relevance of clients or financial counterparts affected, and where relevant the amount or number of transactions affected, and whether the incident caused reputational impact.
The duration of the incident, including service downtime.
The geographical spread, particularly if more than two member states are affected.
Data losses affecting availability, authenticity, integrity or confidentiality.
The criticality of the services affected, including transactions and operations.
The economic impact, direct and indirect, in absolute and relative terms.
The regulatory technical standards on classification turn these criteria into thresholds and set out how they combine to make an incident major. The standards also cover significant cyber threats, which entities may report voluntarily. Read the current standard text when you write your classification procedure. The thresholds are the part people most often paraphrase wrongly.
The incident management process behind the reports
Article 17 requires a documented ICT-related incident management process to detect, manage and notify incidents. It is part of the ICT risk management framework described in our article on the DORA ICT risk management framework, and it must:
Put early warning indicators in place.
Record all ICT-related incidents and significant cyber threats.
Identify, track, log, categorize and classify incidents by priority, severity and the criticality of the services affected.
Assign roles and responsibilities for different incident types and scenarios.
Set communication plans for staff, external stakeholders and the media, and for notifying clients, internal escalation and counterparts.
Report at least major incidents to relevant senior management, and inform the management body of at least major incidents and their impact and response.
Establish response procedures to mitigate impact and restore services in a timely way.
Notice that the record-keeping obligation is wider than the reporting one. A supervisor reviewing your process will look at the minor incidents you did not report and check the classification you gave them.
The three reports
Article 19 requires financial entities to report major ICT-related incidents to their relevant competent authority. The sequence is:
Initial notification. The first report, made after the incident is classified as major.
Intermediate report. Submitted once the status of the original incident has changed significantly, or its handling has changed based on new information. It is followed by updated notifications whenever a relevant status update is available, and on the authority's specific request.
Final report. Submitted when the root cause analysis is complete, whether or not mitigation measures have already been implemented, and when actual impact figures are available to replace estimates.
The content of each report and the deadlines are set in technical standards, not in the regulation's text. The initial notification is due within hours, and the later reports follow on a schedule measured from earlier milestones. Build your runbook from the current standards and record the version you used.
Article 19 adds two related duties. Where a major incident affects the financial interests of clients, the entity must inform them without undue delay, including what it has done to mitigate the adverse effects. And entities may notify significant cyber threats voluntarily when they consider the threat relevant to the financial system, its users or clients.
What you need from your ICT providers
Many major incidents start at a provider. If your payment processing runs on a third party's platform, its outage is your incident, and you report it on your own clock.
DORA's contract requirements address this directly. Article 30 requires every contract for ICT services to commit the provider to assist when an ICT incident related to its service occurs, at no additional cost or at a cost determined in advance. For services supporting critical or important functions, the contract must also set notice periods and reporting obligations, including notice of any development that might materially affect the provider's ability to deliver.
In practice, write down what you need from each provider when something breaks, and make sure the contract delivers it in time:
When the incident started and when the provider detected it
Which services, regions and customers are affected
Whether data was lost, altered or exposed
What the provider believes the cause is, and how confident it is
What mitigation is in progress and the expected recovery time
A named contact available for the duration of the incident
A provider notice that arrives a day later and says "degraded performance" does not support an initial notification. Test this before you need it. Include a provider outage scenario in your exercises, and check how long it takes to get each item on that list.
A runbook that meets the deadlines
The runbook should turn the regulation into a sequence someone can follow at 2 a.m. without reading the regulation:
Detect and log. Every ICT-related incident gets a record with a timestamp for detection, whether or not it looks serious.
Assess against the criteria. A named classifier scores the incident against each Article 18 criterion and the thresholds in the standards, and records the score, even when the answer is "not major".
Classify and start the clock. If major, the classifier records the time of classification and notifies the reporting owner.
Gather provider facts. If a third party is involved, invoke the contract assistance clause and request the facts listed above.
File the initial notification. Use the authority's current template and submission channel. Keep a copy and the submission confirmation.
Inform affected clients where their financial interests are affected.
Track status changes. Each significant change triggers an intermediate report or an update. Note each one in the incident record.
Complete the root cause analysis and file the final report with actual figures.
Run the post-incident review required by the risk management framework, and record what changed as a result.
Keep an evidence pack per major incident: the classification record, every report submitted with its timestamp, provider correspondence, client notices and the post-incident review. That pack answers most supervisory follow-up before it is asked.
How DORA reporting relates to other duties
A single incident can trigger more than one regime. If personal data is involved, the GDPR's 72-hour notification to the supervisory authority under Article 33 runs separately from DORA, to a different authority, on its own test. Your runbook should check both.
For financial entities in DORA's scope, DORA's incident reporting applies in place of the equivalent NIS2 obligations, because NIS2 treats DORA as a sector-specific act. Where your group also contains entities outside DORA's scope, those entities may still fall under NIS2 and its own timelines. Which regime governs a given entity and incident is a question to confirm with counsel. For how DORA's requirements reach the providers on the other side of this process, see DORA explained for ICT service providers.
How TrustLynce helps
TrustLynce's continuous monitoring routes control failures to their owners, which feeds the detection and logging steps of the runbook. Third-party risk management keeps the vendor inventory, risk tiers and review history, so you know which providers support critical functions when an incident starts at a supplier.