One incident, four clocks: NIS2, DORA, CRA and GDPR reporting

A single cyber incident can trigger four reporting clocks. This playbook compares the deadlines, walks you through classification and lists the Belgian, Dutch and Luxembourg recipients.

This playbook is for the people on the bridge call when something goes wrong: the incident manager, CISO, DPO, legal counsel and, in financial entities, the ICT risk function. It sets out the reporting rules for a single EU cyber incident side by side, with a decision flow and the Belgian, Dutch and Luxembourg recipients. At the end you will have a decision sheet you can rehearse in a tabletop and use for real. It covers reporting only; the technical handling sits in your incident response plan.

Before you start

Record which regimes apply, somewhere you can open during an outage. Are you an essential or important entity under your national NIS2 law? A financial entity under DORA? A manufacturer of products with digital elements under the CRA? The GDPR almost always applies. Then agree the roles:

• Reporting lead (CISO or ICT risk officer): owns classification and the clocks.
• DPO: decides on GDPR Article 33 and 34 notifications.
• Legal counsel: reviews wording, liability and law-enforcement constraints.
• Submitter and deputy: hold active accounts on each portal (CCB platform, NCSC portal, ENISA Single Reporting Platform, financial supervisor channel).
• Approver: a management body member informed at each submission.

The four clocks compared

Regime	What triggers it	First report	Follow-up	Final report	Recipient
NIS2 (Art. 23)	A significant incident: severe operational disruption or financial loss, or considerable damage to others	Early warning within 24h of becoming aware	Incident notification within 72h (24h for trust service providers); intermediate report on request	One month after the incident notification, or a progress report if the incident is still ongoing	National CSIRT or competent authority
DORA (Art. 19; Del. Reg. 2025/301)	A major ICT-related incident under Del. Reg. 2024/1772	Initial notification within 4h of classifying the incident as major, and never later than 24h after awareness	Intermediate report within 72h of the initial notification	One month after the latest updated intermediate report	Financial competent authority
CRA (Art. 14)	An actively exploited vulnerability, or a severe incident affecting the security of the product	Early warning within 24h of becoming aware	Notification within 72h	Vulnerability: 14 days after a fix or mitigation is available. Incident: one month after the 72h notification	CSIRT coordinator, via the ENISA Single Reporting Platform
GDPR (Art. 33/34)	A personal data breach	Notify the supervisory authority within 72h of becoming aware, unless the breach is unlikely to result in a risk	Information may be provided in phases	No fixed final report; document the breach internally	Data protection authority; data subjects without undue delay if the risk is high

Sources: NIS2 Article 23^[1], DORA timelines^[4], CRA Article 14^[5], GDPR^[7].

Step 1: Start the awareness clock and log it

Every regime counts from awareness, so make that moment explicit: the point at which you are reasonably certain a security event has occurred with possible impact. Record date, time and time zone in the incident log when the incident manager declares the incident.

• Record who became aware first and how (a SOC alert, a supplier notice, a customer complaint).
• Calculate every possible deadline straight away and put it on the bridge call agenda.
• Flag weekends and public holidays. DORA lets some entities file by noon on the next working day, but not credit institutions or entities that are also NIS2 essential or important entities^[4].

Step 2: Test NIS2 significance

Under NIS2, an incident is significant if it has caused, or is capable of causing, severe operational disruption of your services or financial loss to you, or if it affects others by causing considerable material or non-material damage^[1]. Implementing Regulation (EU) 2024/2690 sets binding numbers only for digital infrastructure and digital providers: DNS and TLD providers, cloud and data centre providers, content delivery networks, managed (security) service providers, online marketplaces, search engines, social networks and trust service providers^[2].

• For these entities, the general criteria are: a direct financial loss above EUR 500,000 or 5% of annual turnover, whichever is lower; exfiltration of trade secrets; death or considerable damage to health; or successful, suspectedly malicious unauthorised access that could cause severe operational disruption.
• Incidents that recur within six months with the same apparent root cause count together.
• Then check the service-specific thresholds in Articles 5 to 14 (for example, unavailability for cloud services).
• In Belgium, the CCB publishes guidance for other sectors that uses a lower financial threshold of EUR 250,000. Where the guidance and the EU regulation differ, the regulation prevails^[8].

Step 3: Classify under DORA (financial entities only)

DORA has its own test, set out in Delegated Regulation (EU) 2024/1772^[3]. An incident is major if it affects critical services and one of two conditions is met. Either there was successful, malicious, unauthorised access to network and information systems that may lead to data losses, or at least two other materiality thresholds are met.

• Clients and transactions: more than 10% of the clients using the service, or more than 100,000 clients; or more than 10% of the daily average transactions.
• Duration and downtime: the incident lasts more than 24 hours, or a service that supports critical or important functions is down for more than 2 hours.
• Geographical spread: impact in two or more Member States.
• Economic impact: costs and losses above EUR 100,000.
• Reputational impact and data losses: qualitative tests. Examples are media coverage, repeated client complaints, or impact on data availability, integrity or confidentiality.

Classification as major starts the 4-hour clock; if classification only happens after 24 hours, you file within 4 hours of it^[4]. DORA is lex specialis to NIS2, so financial entities report under DORA; check national arrangements for any copy to the CSIRT.

Step 4: Check the CRA if you make products

From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of their products with digital elements^[6]. The rest of the CRA applies from 11 December 2027. This is a product obligation: it applies even if your own network was never touched, for example when your firmware is exploited at a customer’s site.

• Submit one notification through ENISA’s Single Reporting Platform. It goes to the CSIRT designated as coordinator in the Member State of your main establishment (in Belgium, the CCB), and ENISA receives it at the same time.
• Send the early warning within 24 hours and the notification within 72 hours. The final report is due 14 days after a corrective measure is available (for vulnerabilities) or one month after the notification (for severe incidents).
• Inform the users affected, and tell them which mitigations they can apply^[5].

Step 5: Decide on GDPR notification

If personal data was destroyed, lost, altered, disclosed or accessed without authorisation, the controller must notify its lead supervisory authority within 72 hours of becoming aware, unless the breach is unlikely to result in a risk; if the risk is high, inform the individuals without undue delay^[7]. Processors inform the controller without undue delay. NIS2 and DORA reports do not replace the GDPR notification.

• Assess risk from the data subject’s point of view.
• Record every breach internally, including those you do not notify, with your reasoning.

Step 6: Submit, align and diarise the follow-ups

Use one fact sheet as the source for every report: timeline, affected services, suspected cause, cross-border impact, measures taken and indicators of compromise. Formats differ per portal; the facts must not.

• File the first report on time even if it is short. Mark unknowns as “under investigation”.
• Put the follow-up deadlines in the incident log. They run from different start points: the NIS2 final report runs from the 72-hour notification, and the DORA final report from the latest intermediate report.
• If you cannot meet a DORA deadline, tell the authority before it expires and explain why.
• Tell management, and record that you did.

Step 7: Close out and learn

After the final reports, review the reporting itself: were the clocks met, was classification fast enough, did the portals and accounts work? Feed the lessons into this playbook and your tabletop scenarios. The companion template includes the decision sheet, a deadline calculator, a Benelux contact list and a submission log.

How this connects to other frameworks

ISO/IEC 27001:2022 controls 5.24 to 5.28 require an incident management process but set no external deadlines; this playbook is the regulatory layer on top. CyFun and NIS2 Article 21 expect documented incident handling, and DORA Article 17 requires an incident management process that feeds the classification in Step 3. In Secrato, the playbook and decision sheet are evidence on the incident-handling controls in the Unified Control Library, so one assessment counts for NIS2, DORA, ISO 27001 and GDPR.

Frequently asked questions

Do we file a NIS2 early warning if we are not yet sure the incident is significant?

The early warning is meant to be fast and light. If significance looks likely, file and correct later; that is far easier to explain than a missed deadline.

We are a bank in Belgium. Do we report to both the NBB and the CCB?

DORA takes precedence for financial entities, so the DORA report to your financial supervisor is the primary obligation. Check current NBB and CCB guidance on how DORA reports are shared with the CSIRT. Do not assume you have to file a separate NIS2 notification.

Does a ransomware attack on our ERP system count under the CRA?

Only if the attack exploits a vulnerability in a product with digital elements that you manufacture, or if it is a severe incident affecting the security of that product. An attack on your own internal systems falls under NIS2 and the GDPR, not the CRA.

Which tools help with NIS2 incident reporting within 24 hours?

A decision timeline that tells the team which clock has started, and one place for the incident facts. Our free incident notification decision timeline sheet covers the first part. A GRC platform such as Secrato keeps incident records linked to the affected controls, risks and evidence, so the early warning, the notification and the final report draw on the same information.