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

On 7 May 2026 the Council and European Parliament reached a provisional agreement on the EU Digital Omnibus. The agreement is best known for what it did to the AI Act (deferring high-risk obligations to 2 December 2027 and 2 August 2028, with the Commission's classification guidelines published 19 May 2026). The provision that will reshape compliance operations for the rest of the decade is quieter and more consequential: a Single Entry Point for incident reporting, to be built and operated by the European Union Agency for Cybersecurity (ENISA), that consolidates the reporting obligations under NIS2, GDPR, DORA, eIDAS, and the CER Directive into one portal.

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 simplifies the regulator-facing layer (one filing, fanned out by ENISA to the relevant authorities). It does 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 all stay in place. What changes is that the fragmentation a company can tolerate upstream of the report has now been 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

• The Single Entry Point is established by a new Article 23a of the NIS2 Directive, operated by ENISA, building on the Cyber Resilience Act reporting platform; covers NIS2 (cyber), GDPR (personal data breach), DORA (major ICT incident + voluntary cyber threat for financial sector), eIDAS, and CER Directive
• Council and Parliament reached provisional trilogue agreement 7 May 2026; formal adoption targeted before 2 August 2026; SEP operational 18 months after entry into force, extendable to 24
• Future regimes (electricity, aviation) are planned to onboard via implementing acts; the SEP is designed to expand rather than to be replaced
• GDPR breach notification under the SEP: deadline extended from 72 hours to 96 hours; threshold raised to "high risk to the rights and freedoms of natural persons" with a transitional clause until the portal is established
• The "report once, share many" design simplifies the regulator's intake, not the operator's upstream work; the five regimes retain their distinct controls, evidence expectations, and timing
• The fragmentation cost is now front-loaded: an incident under the SEP has 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 is established by a new Article 23a of the NIS2 Directive. ENISA builds and operates the portal, building on the experience the agency has already developed running the single reporting platform under the Cyber Resilience Act. The platform sets interoperability, access, and compatibility requirements with European Business Wallets, enabling a single notification to satisfy multiple legal obligations.

The five regimes consolidated at launch are:

The Commission has also signaled that electricity and aviation regimes will 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 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. With formal adoption expected before 2 August 2026, the realistic operational date for the SEP is late 2027 to mid-2028. That is the planning horizon for the operator-side work.

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.

Before the SEP, the fragmentation was tolerable because each owner filed independently. Each report could be drafted on a separate timeline with separate language and separate evidence. Now, one ENISA filing has to satisfy all five regimes from the moment it is submitted. The fragmentation that used to live in the reporting layer has been 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 a GDPR 96-hour clock 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 will be specified by the Commission in implementing acts during the 18-month buildout. 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. Before the SEP, the GDPR breach register was its own artifact, the NIS2 incident log was its own, and so on. After the SEP, the same incident produces 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 SEP filing, and on which 24h / 96h / 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 is now 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 already acknowledges this risk by extending the operational window 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 18-month runway is the natural rehearsal window. Two simulation cycles are realistic: one in the first six months (paper-based, against the proposal text and the May 2026 trilogue agreement); 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 ENISA publishes implementing-act templates during the 18-month 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 18-Month Operator Plan

Three phases, mapped to the realistic SEP operational date.

The plan is calibrated to the 18-month statutory window. If ENISA invokes the 24-month extension, the plan stretches but the phasing does not change. The risk of starting later than this 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 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 do not disappear; their controls, evidence, and post-incident obligations all stay, and the fragmentation a firm could tolerate when each regime was filed separately becomes untenable when one ENISA filing satisfies all five.

The firms that build the crosswalk during the 18-month 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.