Regulated environments: DORA major ICT incident reporting

Why this lesson

Everything so far is good practice. In a regulated company some of it is also the law. If you work at a bank, an insurer, an investment firm or a payment company in the EU, a big enough outage starts a second clock next to your update cadence: a regulator must be notified within hours, then again within days, then again within a month, in a set format. Missing it is a compliance failure on top of the outage.

This lesson is that rulebook: the EU's Digital Operational Resilience Act (DORA), how it decides whether an incident is "major", and the reporting deadlines - plus what it changes for the incident commander, who is usually not the one filing the report but is the one holding the facts and the timestamps.

What you need to know already: 37.2 (severity), 37.8 (communication), 37.22 (the timeline). Not the DevOps DORA metrics (37.27) - different thing, same four letters.

The regulation and its detail rules

• Regulation (EU) 2022/2554 - DORA itself - was published in the Official Journal on 27 December 2022 and has applied since 17 January 2025. It covers EU financial entities (credit institutions, payment and e-money institutions, investment firms, insurers, crypto-asset service providers, trading venues and more - Article 2 lists them), and the oversight of critical ICT providers that serve them.
• Article 17: every financial entity must "define, establish and implement an ICT-related incident management process to detect, manage and notify ICT-related incidents", record all incidents, and make sure root causes are identified, documented and addressed. That process needs roles, communication plans and reporting to senior management - the things this chapter has been teaching.
• Article 18: classify incidents by six criteria (below).
• Article 19: report major ICT-related incidents to the competent authority (the national supervisor; for the biggest banks the report also goes to the European Central Bank): an initial notification, an intermediate report, a final report. Significant cyber threats may be notified voluntarily. And when a major incident affects clients' financial interests, the entity must inform those clients "without undue delay", with what it is doing about it.

The details are in "level 2" rules adopted by the European Commission:

Commission Delegated Regulation (EU) 2024/1772   RTS: classification criteria and
                                                 materiality thresholds
Commission Delegated Regulation (EU) 2025/301    RTS: content and time limits of the
                                                 three reports
Commission Implementing Regulation (EU) 2025/302 ITS: the standard forms and templates

(RTS = regulatory technical standards, ITS = implementing technical standards - binding EU law, written by the European supervisory authorities.)

When is an incident "major"?

The RTS 2024/1772 turns Article 18's criteria into thresholds. Its Article 8 rule: an incident is major when it affected critical services and either

• there was a successful, malicious, unauthorised access to the network and information systems that may result in data losses, or
• two or more of the other materiality thresholds are met.

"Critical services" means ICT services that support critical or important functions, financial services that need authorisation, or systems hit by a successful malicious access. The thresholds (Article 9), in short:

clients, counterparts  more than 10% of the clients using the affected service, or more
and transactions       than 100,000 clients; or more than 30% of financial counterparts;
                       or more than 10% of the daily average number (or value) of
                       transactions; or relevant clients or counterparts affected
reputational impact    in the media; repeated complaints from different clients;
                       cannot meet regulatory requirements; likely to lose clients
duration and downtime  the incident lasts longer than 24 hours, or a critical service
                       is down longer than 2 hours
geographical spread    impact in two or more EU Member States
data losses            an adverse impact on the availability, authenticity, integrity
                       or confidentiality of data
economic impact        costs and losses over EUR 100,000 (incurred or likely)

Recurring incidents count too: incidents that are not major alone, but happened at least twice within 6 months with the same apparent root cause, and together meet the criteria, are reported as one major incident. Entities check for them monthly.

Work one through. A payment institution's card payments fail for 2 h 40 min; 14% of its clients use card payments and were affected; customers in the Netherlands and Belgium; no data affected; costs about EUR 60,000; no press.

critical service affected?     yes - payment processing supports a critical function
clients > 10% of the service   yes (14%)
downtime > 2 h, critical svc   yes (2 h 40 min)
2+ Member States               yes (NL, BE)
data losses                    no
economic > EUR 100,000         no (EUR 60,000)
reputational                   no
=> critical service + three thresholds (two needed): MAJOR

Notice that DORA-major and your severity are different scales. This incident was probably a SEV2 inside the company (core journey down for a subset). A short SEV1 - everyone down for 40 minutes, in one country, no data lost - can be not major if only one threshold is met. Your process needs both: the severity for running the response, and a regulatory classification made by the people who own it (risk, compliance) from the facts the IC provides.

The clocks

The RTS 2025/301, Article 5, sets the time limits:

initial notification   as early as possible, and within 4 hours of classifying the
                       incident as major - and no later than 24 hours after becoming
                       aware of it
intermediate report    within 72 hours of submitting the initial notification - even
                       if nothing changed - and updated whenever the status changes
final report           no later than one month after the (latest updated) intermediate
                       report, once the root-cause analysis is done and real impact
                       figures replace the estimates

Two moments start the clocks, and both need a timestamp on your timeline: when the entity became aware of the incident (often the page, or the first report) and when it classified it as major. If classification happens more than 24 hours after awareness, the 4 hours run from the classification.

Weekends and bank holidays: if a deadline falls on one in the entity's Member State, the report may go in "by noon of the next working day". This relief does not apply to credit institutions, central counterparties, operators of trading venues, or entities that are essential or important under the NIS2 directive. For a bank, a Saturday deadline is a Saturday deadline. And if a deadline will be missed anyway, the entity must tell the authority, with the reasons, no later than the deadline itself.

The same example, with times (the lab writes UTC):

aware                 Tue 15 Sep 2026 09:20   (the page)
classified major      Tue 15 Sep 2026 11:05
initial due           Tue 15 Sep 2026 15:05   (11:05 + 4 h; earlier than aware + 24 h)
initial submitted     Tue 15 Sep 2026 14:40
intermediate due      Fri 18 Sep 2026 14:40   (submission + 72 h)
intermediate sent     Thu 17 Sep 2026 10:00   (status changed: the fix is in)
final due             Sat 17 Oct 2026 10:00   (one month after the latest intermediate)
                      -> a payment institution may file by Mon 19 Oct 12:00 (noon of the
                         next working day); a bank may not

You can check date arithmetic like this with date (chapter 0 used it for the incident clock); GNU date understands "+72 hours" and "+1 month":

$ date -u -d '2026-09-15 14:40 UTC +72 hours' '+%a %d %b %Y %H:%M'
Fri 18 Sep 2026 14:40
$ date -u -d '2026-09-17 10:00 UTC +1 month' '+%a %d %b %Y %H:%M'
Sat 17 Oct 2026 10:00

What it changes for the incident commander

The IC does not usually file the report - a risk, compliance or security function does - but the IC's room is where the facts and timestamps are born. In a DORA-scoped company the incident process adds a few things:

• a regulatory check in the first hour of every SEV1/SEV2: page the on-call compliance or risk contact, give them the impact facts (clients affected, services, countries, data, duration so far), and record their classification and its time on the timeline (incident note / incident decide);
• the awareness time is a fact on the timeline, not a matter of opinion - the scribe records when the first alert or report arrived;
• the comms plan includes clients whose financial interests are affected (Article 19(3)), not only the status page;
• the postmortem doubles as the basis of the final report: root cause analysis done, actual impact numbers, and the measures taken.

DORA overlaps with other clocks you may meet in the same incident: a personal data breach under the GDPR must reach the data protection authority within 72 hours of becoming aware (GDPR Article 33), and NIS2 has its own regime for other sectors. The compliance team owns the map; the IC makes sure they are in the room early.

In an interview

For a platform or SRE role at a European bank or payment company, expect "what does DORA mean for incident response?". A good Mid-level answer: classification by the RTS thresholds (critical services plus data loss through malicious access, or two other thresholds), the three reports (4 h from classification / 24 h from awareness, 72 h, one month), the weekend rule and who cannot use it, and that the IC's job is accurate facts and timestamps for the people who file.

What you can now do

• say what DORA (EU 2022/2554) requires of an incident process, and since when
• classify an incident as major or not with the RTS 2024/1772 thresholds
• compute the initial, intermediate and final report deadlines from RTS 2025/301, including the weekend rule and its exclusions
• explain why DORA-major is a different scale from your severity, and what the IC adds to the process