The EU's Single Entry Point Solves the Regulator's Problem. The Operator Still Needs a Crosswalk.

Start with a distinction that most coverage collapses. The Digital Omnibus is not one legislative file. It is two, and only one of them has become law.

The Digital Omnibus on AI is the AI file. It went through trilogue on 7 May 2026, was approved by Parliament on 16 June 2026 and adopted by the Council on 29 June 2026, was published in the Official Journal as Regulation (EU) 2026/1744 on 24 July 2026, and entered into force on 27 July 2026. It defers the AI Act's high-risk obligations to 2 December 2027 (Annex III) and 2 August 2028 (Annex I). The Commission's draft high-risk classification guidelines, published 19 May 2026, are out for consultation, with final adoption expected end-2026.

The Digital Omnibus Regulation, COM(2025) 837 is the data and cyber file: GDPR, ePrivacy, NIS2, and DORA. It is a different instrument, and it is still under negotiation, under examination by the European Parliament's ITRE and LIBE committees, with the EDPB and EDPS having issued a critical joint opinion. Adoption is not expected before late 2026 at the earliest.

Everything in this article turns on the second file. The Single Entry Point for incident reporting, the proposed GDPR notification change, and the proposed new NIS2 Article 23a all sit in COM(2025) 837, which has not been adopted. Nothing described below is in force today. What follows is a reading of the proposal and a plan for the operator work it would require, not a description of current obligations.

Under the proposal, the European Union Agency for Cybersecurity (ENISA) would build and operate a Single Entry Point that consolidates the reporting obligations under NIS2, GDPR, DORA, eIDAS, and the CER Directive into one portal. That is the provision that would reshape compliance operations for the rest of the decade, quieter than the AI file and more consequential.

The EU communication around the SEP frames it as simplification. For the operators on the other side of the portal, it is something narrower and more demanding. The SEP would simplify the regulator-facing layer (one filing, fanned out by ENISA to the relevant authorities). It would not touch the five underlying regimes. The controls each one requires, the evidence each one consumes, the triggers each one defines, and the post-incident obligations each one imposes would all stay in place. What would change is that the fragmentation a company can tolerate upstream of the report gets compressed: when ENISA delivers a single filing to five authorities, that filing has to be coherent across all five views from the moment it is submitted.

The companies that build the upstream crosswalk now will file once and pass enforcement on the first incident after the SEP goes live. The companies that wait will discover the cost of fragmentation in the middle of an incident, with five different teams owning five different pieces of the same report.

Key Takeaways

• Two files, not one. The Digital Omnibus on AI was adopted 29 June 2026 and is in force as Regulation (EU) 2026/1744 from 27 July 2026; it covers the AI Act only. The Digital Omnibus Regulation, COM(2025) 837, which contains the Single Entry Point and the GDPR change, is still under negotiation in the European Parliament's ITRE and LIBE committees
• The Single Entry Point would be established by a proposed new Article 23a of the NIS2 Directive, operated by ENISA, building on the Cyber Resilience Act reporting platform; it would cover NIS2 (cyber), GDPR (personal data breach), DORA (major ICT incident + voluntary cyber threat for financial sector), eIDAS, and CER Directive
• No adoption date is fixed for COM(2025) 837 and none is expected before late 2026 at the earliest; the SEP would then go operational 18 months after entry into force, extendable to 24, which puts the realistic operational date at 2028 to 2029
• Future regimes (electricity, aviation) would onboard via implementing acts; the SEP is designed to expand rather than to be replaced
• The proposal would extend the GDPR breach-notification deadline from 72 hours to 96 hours and raise the threshold to "high risk to the rights and freedoms of natural persons," with a transitional clause until the portal is established. Until the Digital Omnibus Regulation is adopted, GDPR Article 33's 72-hour deadline continues to apply unchanged. Do not plan against 96 hours
• The "report once, share many" design would simplify the regulator's intake, not the operator's upstream work; the five regimes would retain their distinct controls, evidence expectations, and timing
• The fragmentation cost gets front-loaded: an incident under the SEP would have to produce a single coherent filing that satisfies five regimes from the moment it is submitted, not five separate filings that can be drafted on five separate timelines

What the Single Entry Point Actually Does

The mechanism would be established by a proposed new Article 23a of the NIS2 Directive, inserted by the Digital Omnibus Regulation, COM(2025) 837. That article is a proposal under negotiation, not law. Under it, ENISA would build and operate the portal, drawing on the experience the agency has already developed running the single reporting platform under the Cyber Resilience Act. The platform would set interoperability, access, and compatibility requirements with European Business Wallets, enabling a single notification to satisfy multiple legal obligations.

The five regimes that would be consolidated at launch are below. The middle column is the law as it stands today, which is what applies until COM(2025) 837 is adopted. The right column is what the proposal would change.

The Commission has also signaled that electricity and aviation regimes would onboard via implementing acts after launch. The SEP is designed to expand, not to be replaced. Companies in scope of NIS2, DORA, GDPR, eIDAS, or CER today should expect that the universe of regimes consolidated through the same portal will grow over the lifetime of the platform.

The implementation window in the proposal is 18 months from entry into force, extendable to 24 if ENISA's portal does not meet the Commission's integrity, reliability, and confidentiality standards by the original target. That clock has not started, because COM(2025) 837 has not been adopted. Adoption timing is not yet known and is not expected before late 2026 at the earliest. Taking the earliest plausible adoption and adding the 18-to-24-month build, the realistic operational date for the SEP is 2028 to 2029. Every date below is therefore expressed relative to adoption rather than as a fixed calendar quarter.

The Five-Regime Crosswalk Problem

The framing of the SEP as "simplification" is correct from the EU's perspective and incomplete from the operator's. The regulator-side simplification is real: a national CSIRT under NIS2, a data protection authority under GDPR, a financial-services competent authority under DORA, an eIDAS supervisory body, and a CER-regime authority will all receive the same incident notification through ENISA's fan-out, rather than waiting for five separate filings prepared on different timelines.

What this means for the operator is that the five regimes are now consolidated at the filing layer only. Upstream of the filing, the five underlying obligation surfaces remain:

• Five different incident triggers. NIS2 asks about significant impact on the provision of services. GDPR asks about risk to rights and freedoms of natural persons. DORA asks about major ICT incidents and operational impact. eIDAS asks about trust-service availability and integrity. CER asks about disruption of essential services. A single event can trigger any combination of the five, including all of them at once.
• Five different evidence taxonomies. NIS2 wants service-impact data and corrective actions. GDPR wants categories and approximate numbers of data subjects, categories of personal data, likely consequences, and measures taken. DORA wants ICT-asset criticality, financial-sector impact, and concentration data. eIDAS wants trust-service-specific impact. CER wants critical-service continuity data.
• Five different post-incident obligations. NIS2 final report at one month. GDPR data-subject notification when high risk. DORA root-cause analysis and intermediate updates. eIDAS service-restoration timelines. CER lessons-learned mechanism.
• Five different governance owners inside the firm. The CISO holds NIS2. The DPO holds GDPR. The CIO, CRO, or COO holds DORA. An identity or trust-services owner holds eIDAS. Business continuity or operations holds CER. These five owners report to different executives, use different incident-management tools, and produce evidence in different formats.

Today, without the SEP, the fragmentation is tolerable because each owner files independently. Each report can be drafted on a separate timeline with separate language and separate evidence. Once the SEP is live, one ENISA filing has to satisfy all five regimes from the moment it is submitted. The fragmentation that lives in the reporting layer gets pushed upstream into the control set itself.

For the cross-framework view of how NIS2, DORA, CRA, the revised CSA, and the EU AI Act each evaluate different dimensions of the same vendor and the same operational footprint, see five frameworks, one vendor: how cross-framework exposure compounds. The SEP makes the cross-framework question operational rather than analytical.

What the Crosswalk Looks Like

A controls crosswalk is the matrix that solves the fragmentation. Each row is an operational control. Each column is a regime. Each cell describes the evidence the control produces for that regime, in that regime's language. Built right, a single incident traversed through the matrix yields all five filings in one motion.

Below is a working example. The full crosswalk a regulated mid-market firm typically needs runs 20 to 40 rows; this seven-row excerpt covers the most common SEP-filing surfaces.

The pattern that emerges: the rows are highly correlated, not parallel. Detection timing is the same physical event; severity classification asks five different questions about the same incident; affected-party identification differs in unit (users, data subjects, clients, relying parties, essential-service recipients) but is fed by the same underlying logs. Evidence assembly is the heaviest cell on most incidents, and it is also the cell where harmonization pays off most. A single evidence pack structured to populate all five columns at once eliminates four rounds of "translate the same facts into a different form."

The control owners change across the rows. Detection lives with the SOC and IR team. Classification needs CISO + DPO + GC triage in one room. Notification under the SEP is a single button. Customer comms requires a coordinated voice across legal, marketing, customer success, and the operating teams. Post-incident review needs the same five-regime view applied retrospectively. Without a crosswalk to anchor the workflow, each row becomes its own coordination exercise. With a crosswalk, the five rows collapse into one operational sequence.

What Changes for IT

For the technology function, the SEP creates three concrete operational shifts.

Logging and telemetry need a single source of truth. Five regimes drawing on five different log sources, five different SIEM views, or five different ticketing systems is the upstream version of the fragmentation problem. The detection timestamp that anchors a NIS2 24-hour clock has to be the same timestamp that anchors the GDPR clock (72 hours today under Article 33, 96 hours only if and when the Digital Omnibus Regulation is adopted) and a DORA initial-classification clock. In practice this means the SOC needs one canonical incident record that owns the timeline, with all five regime views computed from it rather than maintained in parallel.

Asset criticality has to be tagged once and consumed five times. DORA asks about ICT-asset criticality. CER asks about essential-service criticality. NIS2 asks about service significance. eIDAS asks about trust-service availability. A single asset register, tagged with each regime's criticality view, is the controls-layer equivalent of the SEP's reporting-layer consolidation. For the runtime side of this (guardrails, kill switches, AI-specific telemetry that feeds the same incident record) see AI governance as an operating system, not a policy PDF.

Incident-management tooling has to produce SEP-compatible output. Whatever the firm uses (ServiceNow IRM, Jira, a custom playbook engine), the workflow has to terminate in a structured artifact that maps to the ENISA filing template. The template would be specified by the Commission in implementing acts during the 18-month buildout that follows adoption. Firms that wait until the template is published to retrofit their tooling will be 6-12 months behind. Firms that map their tooling to the proposal text now will have the workflow tested by the time the template lands.

What Changes for Legal and the General Counsel

For Legal and the GC office, the SEP raises three governance issues that did not exist before consolidation.

A regulatory exposure register that crosses all five regimes. Today the GDPR breach register is its own artifact, the NIS2 incident log is its own, and so on. After the SEP, the same incident would produce a single filing that is consumed by five authorities. The post-filing audit trail (what was filed, when, against which regime, what follow-up was provided) has to be unified. Legal owns this register and has to be able to produce it on demand for any of the five authorities. The methodology page describes this as the "regulatory exposure register" artifact in the GC translation row of the Connect-to-Translate workflow.

Privilege and disclosure across regimes. A finding that triggers a NIS2 notification is also disclosable under GDPR if it affects personal data and may be material under DORA if it affects ICT services. The disclosure choices the GC makes for one regime can foreclose options under another. Pre-incident, this means working through the disclosure decision tree before the incident hits, not during it. Post-incident, it means the GC sits at the classification table, not downstream of it.

Contractual obligations to customers and counterparties under each regime. SaaS agreements typically reference GDPR breach-notification commitments; DORA-regulated financial counterparties have ICT-third-party-risk provisions that require specific notification timing and content; NIS2 customers expect service-impact updates under their own downstream regulatory obligations. The crosswalk needs a contractual-exposure column attached to each row so the GC knows which customer and counterparty notifications fire on which trigger.

What Changes for BCP and Incident Response

For business continuity and incident response, the SEP is both a consolidation opportunity and a single-point-of-dependency risk. Both effects deserve a concrete operational response.

One incident-response playbook, structured around the crosswalk. The current state for most regulated mid-market firms is five parallel playbooks (or, more commonly, three playbooks plus two retrofits) that each describe how to handle the same physical incident from a different regime's view. Under the SEP, that has to collapse into one playbook with a single decision tree that classifies the incident against all five regime triggers in one pass. The tree should produce four outputs in sequence:

1. Severity classification: does this hit any of the five regime triggers, and which combination?
2. Filing trigger: does the classification require a filing, and on which clock? NIS2 24h, GDPR 72h under Article 33 as it stands today (96h only if the Digital Omnibus Regulation is adopted), or the DORA-specific clock.
3. Internal notification fan-out: who inside the firm needs to know in what order (board chair, audit committee, CFO, GC, CISO, DPO, operating partner if PE-backed)?
4. External notification fan-out: beyond ENISA via the SEP, who else needs to hear (customers, counterparties, insurers, public)?

The contact tree has to reflect SEP architecture. Pre-SEP, the contact tree had five external endpoints (one per regime authority). Post-SEP, the external authority endpoint collapses to one (the ENISA portal), and the contact tree's complexity moves to the internal side. The roles the IR plan needs to name:

• Incident commander: single point of accountability for the incident, typically CISO or deputy.
• Crosswalk owner: the person who classifies the incident against all five regime triggers in one pass. In practice this is a CISO + DPO + GC role played by the most senior individual available at the time of detection.
• SEP filer: the role authorized to submit through the ENISA portal. Often the CISO's deputy or a designated compliance officer; needs production access to the portal and the evidence pack at submission time.
• Customer comms owner: the role coordinating downstream notification to customers, counterparties, and the public; typically a head of customer success or communications with GC sign-off.
• Board liaison: the role briefing the board chair and audit-committee chair; typically the GC or CEO depending on materiality.

The ENISA portal becomes a BCP dependency. When the SEP is the single regulator-facing endpoint for five regimes, its availability during a major incident matters. The Digital Omnibus Regulation proposal already acknowledges this risk by allowing the operational window to extend from 18 to 24 months if ENISA cannot meet integrity, reliability, or confidentiality standards. In practice, firms should treat the SEP the way they treat any critical third-party regulator endpoint: documented fallback (offline submission via national authority if the portal is unavailable, with retroactive SEP filing), tabletop exercises that include "the portal is down" as a scenario, and clarity on which authority remains the legally responsible recipient if the SEP fails. The Commission has signaled fallback provisions; the operational detail will arrive in implementing acts.

Tabletop exercises before the portal goes live. The runway between now and go-live is the natural rehearsal window, and it is longer than it looked six months ago. Two simulation cycles are realistic: one against the COM(2025) 837 proposal text as it stands, run before adoption; a second after the Commission publishes the implementing-act templates (against the actual portal schema). Both exercises should test the four-output decision tree above, the crosswalk, and the contact tree under three scenarios: a personal-data breach with NIS2 service impact, a major DORA ICT incident affecting trust-service availability, and a third-party SaaS compromise that triggers GDPR, NIS2, and DORA simultaneously.

How Our Method Builds This Crosswalk

The crosswalk is exactly the artifact our engagement methodology is built to produce. The four stages (Anchor, Mine, Connect, Translate) are designed to surface cross-framework exposure and produce the audience-specific artifacts each function needs to act on it.

In the SEP-readiness case, the four stages map directly:

• Anchor. The strategic objective is "one SEP filing satisfies five regimes." The success criterion is a controls crosswalk with named owners, evidence templates aligned, and a tested incident-response playbook before the portal goes live. The stakeholder map names the CISO, DPO, CIO/CRO, GC, head of internal audit, and the board's audit committee.
• Mine. The external footprint is the five-regime exposure surface: which NIS2 essential or important entity classification applies, which DORA tier the firm is in, which GDPR cross-border lead authority it reports to, which eIDAS trust services it provides or relies on, which CER critical-entity designation applies. The Mine stage also captures the firm's current incident history across all five regimes (loss runs, prior breaches, notifications filed, near-misses logged) as the baseline.
• Connect. The crosswalk itself is the Connect-stage artifact. Each finding in the Mine stage is pulled through the seven workstreams on the methodology page (tech and architecture, cybersecurity and privacy, regulatory, commercial, finance, legal, operations) and laid out in the rows-and-columns matrix above. The "Method by workstream" matrix on the methodology page generalizes this; the SEP crosswalk is a specific instance.
• Translate. From the same body of analysis, the GC receives a regulatory exposure register that maps each row to contractual obligations and disclosure choices. The CISO and DPO receive a harmonized playbook and decision tree. The board receives a two-page exposure brief with the SEP-readiness state and residual gaps. The CFO receives an impact model of the cost of fragmentation versus the cost of building the crosswalk. The operating partner of a PE-backed firm receives a Day-100 plan to align portfolio companies onto a common SEP-ready baseline.

The crosswalk is not a one-off deliverable. It is a living artifact, maintained as new evidence accumulates, as COM(2025) 837 moves through negotiation and its text changes, as ENISA publishes implementing-act templates during the post-adoption buildout, and as the regimes themselves are updated (the next major moves on NIS2 and DORA review cycles, and the AI Act high-risk obligations entering application 2 December 2027). For the boardroom view of the same evidence pack, see from AI principles to proof of control; for the runtime-layer controls that feed the crosswalk, see AI governance as an operating system; for the NIS2-specific national-implementation lens (Sweden), see Sweden's Cybersecurity Act and NIS2.

The Operator Plan, Anchored to Adoption

Three phases. Because COM(2025) 837 has not been adopted and adoption timing is not yet known, the windows below are expressed relative to adoption rather than as fixed calendar quarters. Phase 1 is the only phase that does not depend on the legislative outcome, which is why it starts now.

The plan is calibrated to the 18-month window that would run from entry into force. If ENISA invokes the 24-month extension, the plan stretches but the phasing does not change. On current expectations the portal is a 2028-to-2029 event, so the pressure is not the deadline; it is that Phase 1 takes about nine months regardless and pays for itself against the regimes already in force. The risk of starting later is straightforward: when the portal goes live and the first major incident hits, an organization without a crosswalk is filing five times under the cover of "one filing," and the inconsistencies between the five views are visible to ENISA, the relevant authorities, and any subsequent regulatory or judicial review.

Closing

The Digital Omnibus Regulation describes the SEP as simplification. From the regulator's vantage, that is accurate. From the operator's, the work moves upstream. The five regimes consolidated at the filing layer would not disappear; their controls, evidence, and post-incident obligations would all stay, and the fragmentation a firm can tolerate when each regime is filed separately becomes untenable when one ENISA filing satisfies all five.

Two things follow. The portal is further away than the coverage suggested, because the file that creates it has not been adopted and the AI file that was adopted does not contain it. And the obligations in force today are unchanged: GDPR Article 33 still runs on 72 hours, and NIS2, DORA, eIDAS, and CER still take their own separate filings.

The firms that build the crosswalk during that runway will file once and pass enforcement on the first incident after go-live. The firms that wait will discover the cost of fragmentation in the middle of an incident, with five teams owning five pieces of the same report and no single artifact that ties them together. The cost is paid either way; the question is whether it is paid in calm preparation or in a live regulatory event.

The Five-Regime Crosswalk Worksheet is built around the matrix and the methodology described above. It includes the seven-control template, the regime mapping for each row, the workstream attribution from the methodology, and the tabletop scenarios for the two simulation cycles. It is designed to be the first artifact a CISO, DPO, GC, or operating partner uses when starting the SEP-readiness program.