DORA Incident Reporting Essentials Explained

TL;DR: To meet DORA incident reporting requirements, you need to do preparation work before your organisation experiences a security incident.

In this article, we outline the basics of DORA incident reporting and provide guidance on meeting DORA incident reporting requirements.

However, this is not just an article about DORA incident reporting.

Being able to report security incidents is one of the core security capabilities for any organisation that wants to grow its operations.

If your company plans on:

• Doing business in a regulated industry.
• Processing customer data.
• Avoiding fines from various regional regulators…

Then you need to be able to report security incidents fast and accurately.

For example, the General Data Protection Regulation (GDPR) says you have 72 hours to report certain breaches. If people are at high risk, you must let them know as soon as possible.

Under NIS2 (in the EU), key service providers have just 24 hours to notify authorities.

And under DORA, which applies to financial firms, reporting is even stricter, with detailed timelines for initial, intermediate, and final reports.

Every regulation has its own rules, but the “how to” for reporting is similar.

Set up (and test) internal processes and tech, train your team, and ensure you know who needs to report what, to whom, and how. The work of reporting a cybersecurity incident happens long before the incident itself.

DORA incident reporting requirements are a fantastic opportunity to prepare your organisation for a security incident.

That’s why we focused on DORA for this article about cybersecurity incident reporting.

You can apply the following principles to DORA incident reporting or any other cybersecurity regulation or reporting framework.

DORA Incident Reporting Basics

The Digital Operational Resilience Act (DORA) imposes specific incident reporting requirements on financial entities in the European Union.

If covered by DORA, you must report all major ICT incidents through an initial, intermediate, and final report.

DORA incident reports must include detailed information on the incident's causes, impact, and mitigation measures.

There are DORA incident reporting templates available; however, as we explain below, these are merely forms to fill out. DORA does not tell you how to find the data you need to complete them.

DORA Incident Reporting vs Other Regulatory Incident Reporting Timelines

DORA has strict timelines (24 hours, 72 hours, and one month for initial, intermediate, and final reports, respectively) for reporting significant cyber incidents to financial regulators.

But how does this compare to other regulations?

Here’s a quick comparison table of the different reporting obligations and timelines for some common frameworks.

What Is a DORA Incident?

Under DORA, when you experience an incident, you need to:

• Classify it as either major or not.

If you classify an incident as major, you then need to:

• Report it to the authorities with the relevant information about it. You need to be able to do this fast.

There are standard templates for incident reporting provided through the Draft Implementing Technical Standards (ITS), which cover:

• Initial notification (submitted within 24 hours of detecting the incident).
• Intermediate report (submitted within 72 hours).
• Final report (submitted within one month).

Whether you are able to do the above will depend on the preparation work you’ve done.

Not having done your prep work in advance means you might struggle to classify an incident as major or report on it with sufficient details.

Each incident “stage” has specific fields you need to fill out.

For example, during the initial notification period (24 hours), you need to report on the incident’s:

• Possible causes, immediate impacts, and systems affected.
• Method of discovery.
• Origin (i.e., whether it came from a third party).
• Impact (both on your business continuity and the wider financial market).

Further reporting over the next 72 hours needs to provide more details, including:

• The number of transactions impacted.
• Data losses and impact on data integrity (especially on sensitive data).
• Threats and techniques used by the threat actor.
• Impact on infrastructure components and hardware.
• And much more.

A highly detailed final report, including a root cause analysis, needs to be completed within 30 days.

We highly recommend you check out the templates starting on page 30 here to get an idea of the level of detail required in these reports.

DORA Incident Reporting Requirements

As we’ve explained, DORA’s incident reporting templates tell you what to report, not how to obtain the necessary data. It’s assumed you already have all the required data available.

• The DORA incident response templates assume that you already have systems and processes in place that can provide the required data to complete them.

This means that meeting DORA incident reporting requirements is up to your organisation.

DORA incident reporting requires having an extensive and highly functional security posture, including an asset inventory, records of third-party dependencies, impact assessment systems, threat detection and response, and the ability to measure impact.

We would advise organisations, at a minimum, to deploy (and keep up to date) the capabilities we list in the table below:

Without these basic capabilities, filling out DORA incident reporting templates within the required reporting timelines can be very difficult.

Note: You may already possess some or all of these capabilities, but have you tested them under a realistic incident scenario to determine your reporting time? Ask us about our purple team and gold team services.

Can’t I just use a DORA incident classification tool or formula?

Under DORA, financial entities must classify ICT-related incidents based on criteria such as the number of affected customers, transaction impact, reputational damage, incident duration, geographical spread, data integrity loss, service criticality, and economic impact.

To help with this, there are DORA incident classification tools and formulas available online.

However, for many organisations, the problem with being able to classify an incident is not the formula, but the variables within the formula.

Take this part of one formula available online as an example:

• “The number of affected clients is higher than 10% / higher than 100,000 / affected financial counterparts is higher than 30%.”

But what if you don’t have the records you need to make this calculation? Without the right inputs, it's not possible to accurately calculate whether an incident is major or not.

So, what do you need to classify a DORA incident correctly?

We recommend that companies focus on these three things:

• Accurate client records.
• Up-to-date asset inventories.
• A map of third-party dependencies.

Why DORA Reporting Is Best When You Get It Right the First Time

For this article, we asked SECFORCE’s Head of Consulting Services, Nikos Vassakis, to give his core tip for DORA incident reporting.

He says that, “Getting the incident report right the first time is critical. You ideally don’t want to have to "revise" your story later.”

The reason why is that regulatory bodies rely on the reported data to gauge systemic risk.

Downplaying an incident may lead to inadequate remedial measures, while overplaying an incident can result in the deployment of disproportionate resources.

Either scenario could prompt regulators to scrutinise the institution’s internal controls and incident management processes.

Even if you make adjustments to DORA incident classifications (such as reclassification from major to non-major or vice versa) due to new information coming to light, substantial discrepancies in initial reporting can lead to questions about the reliability of the entity’s incident response processes.

This can have long-term regulatory and operational implications.

The Only DORA Reporting Shortcut Is Cyber Resilience

If you have a major incident and need to report on it, you must have everything else in place to be able to do this.

You don’t want to be figuring things out during an active incident, especially when the same team or stakeholders responsible for responding to it must also be completing the incident report.

That’s why cyber resilience is critical - you need systems, data, and processes ready before an incident occurs.

SECFORCE helps financial entities build, refine, and test their detection and reporting capabilities and processes.

If you want to be confident that you can meet the 24-hour, 72-hour, and 30-day report timelines without scrambling, talk to us about our DORA compliance solutions.

We’ll make sure you're ready long before an incident happens.

Contact us today.