EU Digital Omnibus: Single Incident Reporting Point Simplifies Process But Leaves Compliance Complexity Intact

On 19 November 2025, the European Commission published the Digital Omnibus Package, a legislative bundle aimed at reducing the compliance overhead created by five overlapping digital regulations — NIS2, GDPR, DORA, CER, and eIDAS — each of which imposes its own incident notification obligations on organisations operating in the EU. The centrepiece is a Single Entry Point (SEP): one notification interface designed to satisfy all five regimes simultaneously under the banner "report once, share many." The proposal is genuinely useful for reducing administrative friction. It is not, however, a substantive harmonisation of the underlying legal requirements — and Swiss financial institutions and digital service providers with EU-market exposure need to understand that distinction before assuming that Digital Omnibus compliance equals Digital Omnibus simplicity.

What the Digital Omnibus Actually Does

The SEP is designed to collect a single incident notification and route it to the competent authorities of each applicable regime simultaneously. In scope: NIS2 Directive notifications, GDPR personal data breach notifications, DORA major ICT incident reports and voluntary significant cyber threat notifications, eIDAS notifications, and CER Directive incident reports. Aviation and electricity sector regimes are expected to be onboarded via implementing acts after the core regulation enters into force.

The only substantive change to notification timelines in the package is the GDPR's personal data breach deadline, which moves from 72 hours to 96 hours. This single extension is presented as alignment with NIS2's initial notification window — but NIS2's 24-hour early warning obligation already sits well below both. The GDPR change is the exception; every other notification timeline in every other regime remains unchanged.

The SEP will become operational 18 months after the regulation enters into force, with a possible extension to 24 months if the Commission's technical assessment determines that the platform does not yet meet integrity, reliability, or confidentiality standards. Organisations should not design incident response workflows around the SEP before those implementing acts are published.

The Gap Between 'Report Once' and 'Comply Once'

The Commission is explicit: "The underlying legal requirements for incident reporting will not change." The SEP is a routing mechanism. Organisations using it will still need to understand and apply five different incident classification standards because the authorities receiving the routed notification will each apply their own.

The practical consequence is significant. Under DORA, a financial entity must report a "major ICT incident" within 4 hours of classification, submit an intermediate report within 72 hours, and a final report within one month. Under NIS2, the initial obligation is an early warning within 24 hours of "awareness of a significant incident," with a fuller notification within 72 hours. GDPR requires notification within 96 hours (proposed) of becoming aware of a breach "likely to result in a risk to the rights and freedoms of natural persons." CER uses "without undue delay" — undefined in numeric terms.

A single event — for example, a ransomware attack encrypting customer data at a financial institution — could simultaneously trigger DORA's 4-hour major ICT incident clock, NIS2's 24-hour early warning obligation, and GDPR's 96-hour breach notification window. Each of those clocks starts from a different trigger condition and requires a different level of information in the initial submission. The SEP does not resolve this: it accepts one submission form, but that form still needs to contain information sufficient for three different regulatory standards.

Organisations that front-load compliance investment into building SEP-compatible submission processes — rather than incident classification capability — will discover that the hard problem remains exactly where it was before the package was published.

Swiss Exposure: FINMA and nDSG Outside the Scope

Switzerland is not an EU member state, and the Digital Omnibus does not apply directly to Swiss-domiciled entities. The relevant EU obligations apply to Swiss organisations through their EU-market activities: subsidiaries registered in EU member states, financial institutions passporting services into the EU under bilateral arrangements, or digital service providers with EU customer bases meeting NIS2's applicability thresholds.

Critically, neither FINMA's incident notification obligations under Rundschreiben 2023/1 (Operational Risk and Resilience) nor the nDSG (Federal Act on Data Protection) notification requirements to the FDPIC are included in the SEP's scope — nor could they be. Swiss regulatory obligations flow to Swiss authorities through Swiss legal frameworks. The SEP will never serve as a substitute for FINMA notification or FDPIC breach reporting.

The operational risk for Swiss financial institutions managing a single incident response function that covers both FINMA and EU-regime obligations is notification routing confusion under pressure. A major ICT incident at a Swiss bank with EU subsidiaries triggers FINMA RS 2023/1 notification requirements for the parent, DORA notification for the EU subsidiary, potentially NIS2 if the subsidiary operates critical infrastructure, and nDSG for any Swiss personal data involved. These four notification obligations flow to four different authorities on four different timelines. The SEP handles one of those four. The other three require separate, parallel processes.

Compliance Planning During the Implementation Window

The 18-to-24-month gap before SEP operationalisation is not dead time. It is the most valuable window available for organisations to fix the substantive compliance problems that the SEP cannot fix for them.

The highest-value investment is incident classification capability: building the internal process to triage an event against each applicable regime's threshold simultaneously within the first hour of detection. This requires tabletop exercises that simulate multi-regime incidents, decision trees that map event types to applicable regimes, and clear internal ownership of each notification track. The SEP submission itself, once the platform exists, will take minutes. The classification decision — which determines whether a notification is required at all, and when the clock starts — is the operationally demanding step.

Organisations should also monitor the Digital Omnibus legislative process. The European Parliament and Council will amend the Commission's proposal during the ordinary legislative procedure, and key parameters — timelines, thresholds, SEP scope — may change materially before the regulation enters into force. Committing to SEP-specific technical implementations before the final text is adopted carries real redesign risk.

• Map every EU-regulated entity in your corporate structure and document which of NIS2, DORA, GDPR, CER, and eIDAS applies to each — the SEP is only useful if your internal scope analysis is accurate before you submit anything.
• Do not conflate the proposed 96-hour GDPR deadline with DORA's 4-hour initial notification window; build separate internal escalation tracks for each timeline rather than treating the SEP as a single synchronised clock.
• Build and maintain parallel notification workflows for FINMA (RS 2023/1) and nDSG (FDPIC) obligations — these are legally independent of EU regimes and FINMA will not accept SEP submission as evidence of Swiss notification compliance.
• Use the 18-to-24-month SEP implementation window to run multi-regime tabletop exercises: simulate a ransomware event that simultaneously triggers DORA, NIS2, GDPR, and FINMA obligations, and stress-test your team's ability to triage under each standard concurrently.
• Monitor the Digital Omnibus legislative process through the Bird & Bird, Taylor Wessing, and Slaughter and May trackers; key parameters will shift during the Parliament and Council amendments and implementation decisions should not be locked in before the final text is adopted.

The Digital Omnibus represents a genuine and welcome acknowledgement by the European Commission that the accumulated weight of EU digital regulation creates real operational burden. Regulatory simplification of this kind is a political achievement — and it matters. But for Swiss security and compliance teams advising boards on EU regulatory exposure, the message is precise: the number of portals through which you report is a secondary question. The primary question — whether your incident classification capability can identify the correct threshold for the correct regime within the correct time window — remains exactly as demanding as it was before 19 November 2025. The SEP will eventually help with the final step. The hard work of getting there is still yours to do.