NIS2 and GDPR Incident Reporting: One Breach, Two Clocks

At 02:10 on a Saturday, your client's file server starts encrypting. By 08:00 you know three things: the attacker is inside, customer records sit on that server, and the clock started when you became aware. A 24-hour NIS2 early warning is due. A 72-hour GDPR notification is probably due as well. They go to different authorities, and neither replaces the other.

This is the double reporting problem for NIS2 incident reporting and GDPR breach notification. It lands on the MSP first, because the MSP usually holds the logs.

NIS2 and GDPR incident reporting: two regimes, one incident

NIS2 (Directive (EU) 2022/2555) and the GDPR (Regulation (EU) 2016/679) protect different things. NIS2 protects the continuity and security of services. The GDPR protects people whose personal data is exposed. One incident can breach both.

NIS2 Article 23 runs a three-step cascade for a significant incident: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report no later than one month after that notification. GDPR Article 33 asks for one notification to the data protection authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to individuals. Article 34 adds a duty to inform the individuals when the risk is high.

The two clocks often start at the same moment. They do not end at the same moment. The 24-hour NIS2 warning falls due first, so it goes out first.

One report cannot satisfy both

A filing with the cybersecurity authority does not discharge the GDPR duty. A GDPR notice does not start or stop the NIS2 cascade. The recipients differ, the triggers differ, and the content differs. The NIS2 report asks about operational impact and technical indicators. The GDPR report asks about data categories, number of data subjects and likely consequences for them.

NIS2 does recognise the overlap. Its recitals call for cooperation between the competent authorities and the data protection authorities, and Article 35 deals with infringements that involve personal data. That cooperation is between the authorities. It does not shorten your client's workload.

The incident timeline for a breach that touches personal data

Treat the first 72 hours as one operation with two outputs.

In practice that means three habits:

1. File the NIS2 early warning first, even if incomplete. It is a flag, not a finished analysis. Say what you know, mark what you do not.
2. Capture the facts once. Timeline, affected systems, data categories, estimated number of data subjects, containment steps. Both reports reuse that record.
3. Classify twice. "Significant incident" under NIS2 and "risk to individuals" under the GDPR are different tests. An incident can pass one and fail the other.

For the NIS2 side in detail, see NIS2 incident reporting: the 24-hour, 72-hour and one-month deadlines.

What the national laws add

The deadlines come from the EU texts. The portal, the authority and the form come from national law, and the GDPR side always goes to the national data protection authority.

• Germany: reporting runs through the BSI portal under § 32 BSIG as amended by the NIS2 Implementation Act. The GDPR notification goes to the competent data protection authority.
• Netherlands: the Cyberbeveiligingswet has applied since 15 August 2026. The NCSC acts as the CSIRT. Personal data breaches go to the Autoriteit Persoonsgegevens.
• Italy: Article 25 of Legislative Decree 138/2024 requires notification to the ACN through CSIRT Italia. The GDPR notification goes to the Garante.
• Poland: the amended national cybersecurity system act has applied since 3 April 2026. The competent CSIRT (NASK, GOV or MON) receives the NIS2 report. UODO receives the GDPR one.
• France and Spain: no national NIS2 law is in force. The GDPR still applies in full, so the 72-hour notice to the CNIL or the AEPD is a hard obligation today. See where the three missing laws stand.

A French or Spanish client has no NIS2 statutory clock yet. It has a GDPR clock. If it supplies an entity in a transposed country, its customer's contract may impose NIS2-style reporting in a shorter window.

A single entry point is proposed, not in force

The European Commission's Digital Omnibus proposes a single entry point for incident reports, operated by ENISA, through a new Article 23a in NIS2. As reported in July 2026, the proposal would also move GDPR breach notification to a "high risk" threshold and extend its deadline from 72 to 96 hours. The incident reporting provisions were still under negotiation between Parliament and Council, and the single entry point would apply 18 months after entry into force, extendable to 24.

Do not design a client process around it. The reportability tests would stay separate even under the proposal. Build for the law that applies today and keep the process modular so a new portal changes one step, not all of them.

What to put in place before the incident

MSPs get blamed for slow reporting even when the client owns the duty. The client's management remains responsible. Your job is to make the duty executable.

• A one-page decision sheet: who decides "significant", who decides "personal data breach", and who signs off within hours.
• Pre-filled contact details for the CSIRT or authority and the data protection authority, per country.
• A shared incident record with fields that map to both reports.
• A rule that the early warning goes out on the 24-hour mark, whatever the state of the analysis.
• A written reason whenever the team decides not to notify. Regulators ask for it.

This is Article 21(2)(b) territory. Our guide to NIS2 incident handling shows why the handling process fails audits more often than the reporting step.

Check the gap before the Saturday call

If you cannot say today who files the early warning for each client, and who files the GDPR notice, you have found the gap. Run a NIS2 Quick Scan to see where a client's incident handling and reporting readiness stand against the Article 21 measures.

Then write down the two clocks, name the two owners, and test the process once before it is real. For the wider MSP picture, see NIS2 for MSPs and MSSPs.