One Incident, Several Clocks: Aligning GDPR, NIS2, DORA and Swiss Breach Reporting

Security insightsOctober 20, 2026

A single incident can trigger GDPR, NIS2, DORA and Swiss reporting deadlines at once, each with its own trigger and recipient. Here is how they compare and what to prepare this week.

Abstract navy illustration of an ordered grid where three rows of teal-to-blue squares fill to different lengths, each ending in a ring, suggesting parallel reporting timelines

A single ransomware intrusion at a European company can start several legal clocks at once. If personal data is involved, the GDPR applies. If the company is an essential or important entity, NIS2 applies. If it is a bank, insurer or other financial entity, DORA sets its own deadlines. If it operates critical infrastructure in Switzerland, or processes data about people there, Swiss law adds another report.

Each regime has its own trigger, its own recipient and its own idea of when the clock starts. Teams that discover this during an incident lose hours they cannot get back. The work that saves those hours is unglamorous: one shared timeline, one fact sheet, and clear owners for each filing, agreed in advance.

The clocks side by side

These are the baseline obligations as written. NIS2 is a directive, so check your national transposing law for local detail.

GDPR (controllers). Notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in a risk to individuals (GDPR Article 33). Information may be provided in phases, and every breach must be documented, reported or not.
GDPR (individuals). Where the breach is likely to result in a high risk, tell the people affected without undue delay (GDPR Article 34).
NIS2 (significant incidents). An early warning within 24 hours of becoming aware, an incident notification within 72 hours, intermediate reports on request, and a final report no later than one month after the notification (NIS2 Article 23).
DORA (major ICT-related incidents). An initial notification within four hours of classifying the incident as major, and no later than 24 hours after becoming aware of it. An intermediate report follows within 72 hours of the initial notification, and a final report within one month of the latest intermediate report (Delegated Regulation (EU) 2025/301, Article 5).
Switzerland (critical infrastructure). Since 1 April 2025, operators must report cyberattacks to the NCSC within 24 hours of discovery and complete the report within 14 days. Fines for failing to report have applied since 1 October 2025 (NCSC announcement).
Switzerland (personal data). Under Article 24 FADP, controllers report a breach to the FDPIC as soon as possible if it is likely to result in a high risk to the people concerned (FDPIC guidelines).

Where teams get caught out

Different triggers. "Becoming aware" under the GDPR and NIS2 is not the same moment as "classifying as major" under DORA. DORA still caps the initial notification at 24 hours after awareness, so a slow classification decision does not buy extra time. If an incident is only classified as major later, the four-hour clock runs from that classification.

Different thresholds. A significant incident under NIS2 turns on severe operational disruption, financial loss or considerable damage to others. A GDPR breach turns on risk to individuals. An outage with no data exposure can be reportable under NIS2 or DORA and not under the GDPR, and a small exfiltration of customer records can be the reverse.

Waiting for certainty. The FDPIC is explicit that where a high risk cannot be ruled out quickly, controllers must not wait. In a ransomware case, an initial analysis will often have to assume a likely high risk, and a report should be filed before anyone decides whether to pay a ransom (FDPIC guidelines).

Silent processors. Under Swiss law, a processor must tell the controller about any data security breach, whatever the risk. Your contracts and supplier contacts need to make that path fast, because your own clock may already be running.

Missing a deadline quietly. DORA expects a financial entity that cannot meet a deadline to tell its authority before the deadline expires, with reasons. Silence is the worst option under every regime.

Encryption changes the assessment

How well data was encrypted, and who held the keys, often decides whether a breach is reportable at all. Under the GDPR, telling affected individuals is not required where the controller had applied measures, such as encryption, that make the data unintelligible to anyone not authorised to access it (GDPR Article 34). The FDPIC's guidelines go further for Swiss reporting: loss of effectively encrypted data does not need to be reported under Article 24, while pseudonymised data is still personal data and may be reportable.

That only holds if you can show it. In the first hours of an incident, someone will ask whether the attacker could also reach the keys. Have these answers ready before you need them:

Which data stores are encrypted, with which keys, and where those keys live.
Whether key access is logged separately from the systems that hold the data.
Whether the compromised accounts or hosts had any path to decrypt.

A checklist for this week

Map your regimes. List which of the GDPR, NIS2, DORA, the Swiss reporting obligation and the FADP apply to each legal entity, with the competent authority and the reporting portal for each.
Build one timeline. Write the deadlines into a single incident template, with T0 defined per regime: awareness, classification or discovery.
Name the owners. Decide who classifies the incident, who signs each filing and who talks to each authority. Include a deputy for weekends.
Pre-draft the fact sheet. Collect the fields every report asks for: what happened, when, systems and data affected, likely consequences, and measures taken or planned. Fill it once, then adapt it for each recipient.
Check your processors. Confirm that contracts require prompt breach notice and that you have a working out-of-hours contact for each critical supplier.
Prepare your encryption evidence. Document which stores are encrypted, who holds the keys and how key access is logged, so the reporting assessment can rely on facts.
Rehearse it. Run a one-hour tabletop on a ransomware scenario and time how long the first early warning takes to draft and approve.

What may change

In November 2025 the European Commission proposed a Digital Omnibus that would create a single entry point, run by ENISA, so that one notification could be routed to authorities under NIS2, the GDPR, DORA, eIDAS and the CER Directive. It would also extend the GDPR window to 96 hours and limit authority notification to high-risk breaches (Jones Day).

Commentary from mid-2026 still treats this as a proposal, and the portal would only be ready months after adoption (Considerati). The underlying obligations would stay the same. Until it is in force, plan around today's deadlines and recipients.

Conclusion

Multiple reporting clocks are manageable when they are planned together: one timeline, one fact sheet, clear owners and evidence you can trust. The organisations that report well are rarely the ones with the best lawyers on the day. They are the ones that rehearsed.

Key custody is part of that evidence. If you are reviewing how encryption keys are held and logged, OXU KMS is Oten's key management service, built to make encryption simple and secure by design.