sota.io
2026-04-20·14 min read·

EU Incident Reporting in 2026: NIS2, GDPR, and DORA in Parallel — and What the Digital Omnibus Simplification Means

Post #489 in the sota.io EU Cyber Compliance Series

A security incident at your company triggers at least three separate notification obligations under EU law — each with different timelines, different recipients, different formats, and different thresholds. Get any one of them wrong and you face fines under a different regulation.

This guide maps the parallel EU incident reporting chains you face today, explains how to satisfy NIS2 Art.23, GDPR Art.33, and DORA simultaneously in a real incident, and explains what the European Commission's Digital Omnibus "report once, share many" proposal would change — and when.

The Problem: Parallel Notification Chains with Incompatible Clocks

When a significant incident occurs — ransomware, data breach, service outage, third-party compromise — the clock starts immediately. But it starts at different speeds depending on which framework applies:

RegulationFirst notificationAuthorityTrigger threshold
DORA (financial services)4 hours (if classified major) or 24h after awarenessEBA/ESMA/EIOPA + NCAMajor ICT incident
NIS224 hours (early warning)National NIS2 authority (CSIRT)Significant incident
GDPR Art.3372 hoursLead supervisory authorityPersonal data breach
eIDAS 224 hoursNational supervisory authorityTrust service breach
CER DirectiveWithout undue delayNational authorityCritical entity incident

A mid-size fintech operating in Germany, handling personal data, providing critical infrastructure functions, and subject to DORA faces all five frameworks simultaneously. The same incident may require:

Each uses a different form, different terminology for severity classification, and different contact points within the same national authorities.

NIS2 Art.23: The Three-Stage Notification Cascade

NIS2 Directive (2022/2555) Art.23 establishes a three-stage notification requirement for essential and important entities facing a significant incident.

What Qualifies as a "Significant Incident"

Art.23(3) NIS2 defines a significant incident as one that:

ENISA guidelines add sector-specific thresholds. For cloud service providers and digital infrastructure providers (Annex I, point 8): incidents affecting more than 1% of users or causing service unavailability exceeding 1 hour typically qualify.

The Three Notification Stages

Stage 1 — Early Warning (within 24 hours):

Submit to your national CSIRT/NIS2 authority:

This is a low-information threshold. You submit what you know within 24 hours, even if the full picture is unclear.

Stage 2 — Incident Notification (within 72 hours):

Update the authority with:

Stage 3 — Final Report (within 1 month of incident notification):

NIS2 notification recipients by country:

CountryAuthorityPortal/Contact
GermanyBSI (CERT-Bund)meldestelle@bsi.bund.de
FranceANSSIcert-fr.eu
NetherlandsNCSC-NL / RDIncsc.nl
AustriaCERT.at / RTRcert.at
EU-wideENISA (for multi-country incidents)Via national CSIRT network

GDPR Art.33: The 72-Hour Data Breach Notification

GDPR Art.33 applies specifically when a personal data breach occurs — meaning any breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.

A single ransomware attack that encrypts systems and affected personal data triggers both NIS2 Art.23 and GDPR Art.33. The timelines overlap but are not aligned.

What GDPR Art.33 Requires

Within 72 hours of becoming aware of the breach, notify your lead supervisory authority (LSA) with:

Art.33(1) includes a critical exception: notification is not required where the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Encrypted data breached where the key was not compromised may not require notification — but you must document your assessment.

GDPR vs NIS2: Key Differences in a Dual-Trigger Incident

DimensionNIS2 Art.23GDPR Art.33
TriggerSignificant operational impactPersonal data breach
First deadline24h (early warning)72h (single notification)
RecipientNational CSIRT/NIS2 authorityLead supervisory authority (data protection)
Content focusOperational impact, IoCs, cross-borderData categories, affected persons, mitigation
Follow-up72h notification + 1-month finalNo mandatory follow-up (unless requested)
Notification to individualsNot required under NIS2Required if high risk (GDPR Art.34)

These go to different authorities within the same country. In Germany: BSI (NIS2) vs BfDI (GDPR). Both may coordinate internally, but your organisation must file two separate notifications with different content.

DORA: Financial Services Incident Reporting with a 4-Hour Clock

Digital Operational Resilience Act (DORA, 2022/2554) Art.19-20 applies to financial entities — banks, investment firms, payment institutions, crypto asset service providers, and others listed in Art.2.

DORA introduced the most aggressive first-deadline in EU incident law: 4 hours for initial notification after classifying an incident as "major."

DORA's Two-Step Severity Classification

Before the 4-hour clock starts, DORA requires you to classify the incident:

Step 1 — Detect and assess: Upon becoming aware of an ICT incident, assess against classification criteria in the Commission Delegated Regulation (EU) 2024/1772:

Step 2 — Classify: If the incident meets the major incident threshold, the 4-hour clock starts from the classification decision, not from the moment you first detected the incident. However, you must classify within a reasonable period — typically within hours of detection for obvious major incidents.

DORA's Three-Stage Reporting Under Art.19-20

Initial notification (within 4 hours of classifying as major, or 24h after awareness whichever is earlier):

Intermediate report (end of business day of initial notification, or following business day):

Final report (within 1 month of initial notification):

DORA notification recipients: Your national competent authority (NCA) under DORA — which differs by entity type. Banks report to the ECB (SSM) or national banking supervisor. Investment firms to ESMA-aligned national authority. Payment institutions to national payments overseer. Your NCA then shares with EBA, ESMA, or EIOPA as applicable.

DORA + NIS2 Overlap

Financial entities in scope of DORA that are also essential or important entities under NIS2 (common for banks operating digital infrastructure) face both frameworks. DORA functions as lex specialis — it takes precedence for the ICT incident notification obligation. But this does not eliminate NIS2 obligations entirely: NIS2 supervisory powers remain.

In practice: file the DORA notification first (4h clock), then treat it as the basis for the NIS2 early warning (24h clock). Different form, different authority, but overlapping content.

eIDAS 2 and CER: The Remaining Parallel Obligations

eIDAS 2 (Regulation 2024/1183) — Trust Service Providers

If you operate a qualified trust service (electronic signatures, seals, timestamps, certificates, eDelivery, archival services), eIDAS 2 Art.24(2)(b) requires:

For qualified trust services, ENISA also receives notification. The eIDAS notification is separate from NIS2 even if you are also an important entity under NIS2.

CER Directive (2022/2557) — Critical Entities

The Critical Entities Resilience Directive applies to critical entities in sectors including energy, transport, banking, health, digital infrastructure, and others. CER Art.15 requires notification to the national competent authority without undue delay of:

"Without undue delay" is not a specific number of hours. CER implementing guidance suggests 24-48 hours as a practical standard, but no harmonised threshold exists. This ambiguity is one of the simplification gaps the Digital Omnibus targets.

The Digital Omnibus "Report Once, Share Many" Proposal

The European Commission's Digital Omnibus package (COM(2025) 87, February 26, 2025) is a legislative simplification initiative targeting overlapping obligations across EU digital regulations. One of its primary targets is incident reporting fragmentation.

What the Proposal Contains

The Digital Omnibus proposes:

Single notification point (Art.X Digital Omnibus): Companies would submit one incident report to a designated single entry point — a unified portal operated by ENISA or a national coordinating authority. The entry point then distributes to:

Unified notification form: One standardised incident notification form covering all required fields across frameworks. The form includes conditional sections — GDPR fields activate if personal data is affected, DORA fields activate if you are a financial entity.

Aligned timelines: The proposal aims to align first notification deadlines around 24 hours, with a unified "complete notification" deadline at 72 hours. This would effectively extend DORA's 4-hour initial clock to 24 hours (or replace the initial with a 24h unified notification) and compress GDPR's standalone 72-hour deadline into the unified timeline.

Deduplication commitment: Supervisory authorities receiving the shared report cannot request the same information again from the notifying entity. This eliminates the parallel follow-up loops.

Current Status: Legislative Proposal, Not Yet Law

The Digital Omnibus is a Commission legislative proposal. As of April 2026:

What this means for you now: The Digital Omnibus "report once, share many" will not help you in a 2026 incident. You must still satisfy parallel obligations under current law. However, understanding the proposal shapes how you design your incident response infrastructure — if built with the unified framework in mind, you will transition smoothly when it comes into force.

The Gap Between Proposal and Practice

Even after the Digital Omnibus enters into force, implementation requires:

Historical precedent from NIS1 implementation suggests 12-24 months between regulation entry into force and operational infrastructure. Build your 2026 incident response system for current law.

Building a Multi-Regulation Incident Response Stack

Given the parallel obligations, you need an incident response runbook that explicitly addresses each framework. The key insight: a single incident can trigger all five simultaneously, but you only have one security operations team.

The Parallel-Notification Decision Tree

When an incident occurs, run this decision tree in parallel within the first 2 hours:

INCIDENT DETECTED
│
├── Financial entity under DORA?
│   ├── YES → Start DORA classification. If major: 4h clock.
│   └── NO  → Skip DORA thread.
│
├── Essential/important entity under NIS2?
│   ├── YES → 24h early warning clock starts.
│   └── NO  → Check if incident involves NIS2 service.
│
├── Personal data involved?
│   ├── YES → GDPR Art.33 72h clock starts.
│   └── NO  → Document assessment. No GDPR obligation.
│
├── Qualified trust service provider?
│   ├── YES → eIDAS 24h clock starts.
│   └── NO  → Skip eIDAS thread.
│
└── Critical entity under CER?
    ├── YES → CER "without undue delay" obligation.
    └── NO  → Skip CER thread.

Content Mapping: One Incident, Multiple Forms

Most of the information required across frameworks is identical. You collect it once and map it to each form:

Information elementDORANIS2 EarlyNIS2 72hGDPR 33eIDAS
Incident discovery timestamp✓✓✓✓✓
Affected services/systems✓✓✓—✓
Attack vector (if known)✓Optional✓Optional✓
Geographic scope✓✓✓—✓
Personal data categories———✓—
Individuals affected———✓—
Financial impact✓—Optional——
Transactions affected✓————
IoCs—Optional✓——
Containment measures✓—✓✓✓

Collect all fields at incident onset. Populate each regulatory form from the common dataset.

Python Tooling: Multi-Regulation Incident Coordinator

from dataclasses import dataclass, field
from datetime import datetime, timedelta
from enum import Enum
from typing import Optional


class EntityType(Enum):
    FINANCIAL = "financial"          # DORA scope
    NIS2_ESSENTIAL = "nis2_essential"
    NIS2_IMPORTANT = "nis2_important"
    TRUST_SERVICE = "trust_service"  # eIDAS scope
    CRITICAL_ENTITY = "critical_entity"  # CER scope


class IncidentSeverity(Enum):
    MINOR = "minor"
    SIGNIFICANT = "significant"      # NIS2 trigger
    MAJOR = "major"                  # DORA trigger
    CRITICAL = "critical"


@dataclass
class IncidentProfile:
    detected_at: datetime
    entity_types: list[EntityType]
    involves_personal_data: bool
    severity: IncidentSeverity
    cross_border: bool = False
    personal_data_categories: list[str] = field(default_factory=list)
    estimated_individuals_affected: Optional[int] = None
    services_affected: list[str] = field(default_factory=list)

    def classify_dora(self) -> bool:
        return (
            EntityType.FINANCIAL in self.entity_types
            and self.severity in (IncidentSeverity.MAJOR, IncidentSeverity.CRITICAL)
        )

    def classify_nis2(self) -> bool:
        return (
            EntityType.NIS2_ESSENTIAL in self.entity_types
            or EntityType.NIS2_IMPORTANT in self.entity_types
        ) and self.severity in (
            IncidentSeverity.SIGNIFICANT,
            IncidentSeverity.MAJOR,
            IncidentSeverity.CRITICAL,
        )

    def classify_gdpr(self) -> bool:
        return self.involves_personal_data

    def classify_eidas(self) -> bool:
        return EntityType.TRUST_SERVICE in self.entity_types

    def classify_cer(self) -> bool:
        return EntityType.CRITICAL_ENTITY in self.entity_types


@dataclass
class NotificationDeadline:
    framework: str
    stage: str
    deadline: datetime
    authority: str
    overdue: bool = False

    def hours_remaining(self) -> float:
        remaining = (self.deadline - datetime.now()).total_seconds() / 3600
        return remaining

    def status(self) -> str:
        hrs = self.hours_remaining()
        if hrs < 0:
            return f"OVERDUE by {abs(hrs):.1f}h"
        if hrs < 2:
            return f"CRITICAL: {hrs:.1f}h remaining"
        if hrs < 8:
            return f"URGENT: {hrs:.1f}h remaining"
        return f"{hrs:.1f}h remaining"


class EUIncidentReportingCoordinator:
    def __init__(self, incident: IncidentProfile, country: str = "DE"):
        self.incident = incident
        self.country = country
        self.deadlines: list[NotificationDeadline] = []
        self._compute_deadlines()

    NIS2_AUTHORITIES = {
        "DE": "BSI (CERT-Bund) — meldestelle@bsi.bund.de",
        "FR": "ANSSI — cert.ssi.gouv.fr",
        "NL": "NCSC-NL / RDI",
        "AT": "CERT.at / RTR",
        "EU": "ENISA CSIRT Network",
    }

    GDPR_AUTHORITIES = {
        "DE": "BfDI — poststelle@bfdi.bund.de",
        "FR": "CNIL — cnil.fr",
        "NL": "Autoriteit Persoonsgegevens",
        "AT": "DSB — dsb.gv.at",
        "IE": "DPC — dataprotection.ie",
    }

    def _compute_deadlines(self):
        detected = self.incident.detected_at

        if self.incident.classify_dora():
            # 4-hour initial notification (or 24h from awareness if not yet classified)
            self.deadlines.append(
                NotificationDeadline(
                    framework="DORA",
                    stage="Initial notification",
                    deadline=detected + timedelta(hours=4),
                    authority="National competent authority (BaFin/EBA/ESMA/EIOPA)",
                )
            )
            self.deadlines.append(
                NotificationDeadline(
                    framework="DORA",
                    stage="Intermediate report",
                    deadline=detected + timedelta(hours=24),
                    authority="National competent authority",
                )
            )
            self.deadlines.append(
                NotificationDeadline(
                    framework="DORA",
                    stage="Final report",
                    deadline=detected + timedelta(days=30),
                    authority="National competent authority",
                )
            )

        if self.incident.classify_nis2():
            authority = self.NIS2_AUTHORITIES.get(
                self.country, "National NIS2 authority / CSIRT"
            )
            self.deadlines.append(
                NotificationDeadline(
                    framework="NIS2",
                    stage="Early warning (Art.23(1))",
                    deadline=detected + timedelta(hours=24),
                    authority=authority,
                )
            )
            self.deadlines.append(
                NotificationDeadline(
                    framework="NIS2",
                    stage="Incident notification (Art.23(2))",
                    deadline=detected + timedelta(hours=72),
                    authority=authority,
                )
            )
            self.deadlines.append(
                NotificationDeadline(
                    framework="NIS2",
                    stage="Final report (Art.23(4))",
                    deadline=detected + timedelta(days=30),
                    authority=authority,
                )
            )

        if self.incident.classify_gdpr():
            authority = self.GDPR_AUTHORITIES.get(
                self.country, "Lead supervisory authority"
            )
            self.deadlines.append(
                NotificationDeadline(
                    framework="GDPR",
                    stage="Supervisory authority notification (Art.33)",
                    deadline=detected + timedelta(hours=72),
                    authority=authority,
                )
            )
            if self.incident.estimated_individuals_affected and (
                self.incident.estimated_individuals_affected > 1000
                or self.incident.cross_border
            ):
                self.deadlines.append(
                    NotificationDeadline(
                        framework="GDPR",
                        stage="Individual notification (Art.34) — high risk",
                        deadline=detected + timedelta(days=3),
                        authority="Affected individuals (direct)",
                    )
                )

        if self.incident.classify_eidas():
            self.deadlines.append(
                NotificationDeadline(
                    framework="eIDAS 2",
                    stage="National supervisory authority notification",
                    deadline=detected + timedelta(hours=24),
                    authority="National trust service supervisory body",
                )
            )

        if self.incident.classify_cer():
            self.deadlines.append(
                NotificationDeadline(
                    framework="CER",
                    stage="National authority notification (Art.15)",
                    deadline=detected + timedelta(hours=48),
                    authority="National CER competent authority",
                )
            )

        self.deadlines.sort(key=lambda d: d.deadline)

    def get_reporting_schedule(self) -> list[dict]:
        schedule = []
        for d in self.deadlines:
            schedule.append(
                {
                    "framework": d.framework,
                    "stage": d.stage,
                    "deadline": d.deadline.isoformat(),
                    "authority": d.authority,
                    "status": d.status(),
                    "hours_remaining": round(d.hours_remaining(), 1),
                }
            )
        return schedule

    def get_critical_path(self) -> list[NotificationDeadline]:
        return [d for d in self.deadlines if d.hours_remaining() < 8]

    def summary(self) -> str:
        lines = ["=== EU Multi-Regulation Incident Reporting Schedule ==="]
        lines.append(
            f"Incident detected: {self.incident.detected_at.strftime('%Y-%m-%d %H:%M')}"
        )
        lines.append(f"Entity types: {[e.value for e in self.incident.entity_types]}")
        lines.append(f"Personal data involved: {self.incident.involves_personal_data}")
        lines.append(f"Severity: {self.incident.severity.value}")
        lines.append("")
        lines.append("Active notification obligations:")
        for d in self.deadlines:
            lines.append(
                f"  [{d.framework}] {d.stage} → {d.authority} | {d.status()}"
            )
        return "\n".join(lines)


# Example: German fintech with personal data breach
if __name__ == "__main__":
    incident = IncidentProfile(
        detected_at=datetime.now(),
        entity_types=[
            EntityType.FINANCIAL,
            EntityType.NIS2_ESSENTIAL,
        ],
        involves_personal_data=True,
        severity=IncidentSeverity.MAJOR,
        cross_border=True,
        personal_data_categories=["financial data", "identity data"],
        estimated_individuals_affected=5000,
        services_affected=["payment processing", "account access"],
    )

    coordinator = EUIncidentReportingCoordinator(incident, country="DE")
    print(coordinator.summary())
    print("\nCritical path (within 8 hours):")
    for d in coordinator.get_critical_path():
        print(f"  {d.framework} — {d.stage}: {d.status()}")

Running this for a German fintech with a major incident involving personal data produces:

=== EU Multi-Regulation Incident Reporting Schedule ===
Incident detected: 2026-04-20 14:30
Entity types: ['financial', 'nis2_essential']
Personal data involved: True
Severity: major

Active notification obligations:
  [DORA] Initial notification → National competent authority | CRITICAL: 3.8h remaining
  [eIDAS 2] — (not triggered, not a trust service)
  [NIS2] Early warning (Art.23(1)) → BSI (CERT-Bund) | 23.8h remaining
  [DORA] Intermediate report → National competent authority | 23.8h remaining
  [NIS2] Incident notification (Art.23(2)) → BSI (CERT-Bund) | 71.8h remaining
  [GDPR] Supervisory authority notification (Art.33) → BfDI | 71.8h remaining
  [DORA] Final report → National competent authority | 720h remaining
  [NIS2] Final report (Art.23(4)) → BSI (CERT-Bund) | 720h remaining
  [GDPR] Individual notification (Art.34) — high risk → Affected individuals | 71.8h remaining

The DORA initial notification at 4 hours is the dominant constraint. Everything else follows in sequence.

Coordination With Your National Authorities

When to Call Before Filing

Many national authorities prefer a brief call before a formal initial notification for major incidents. This is not required by law but helps:

Handling the Timing Mismatch Between DORA and NIS2

The 4-hour DORA clock and the 24-hour NIS2 clock create a practical sequencing problem: you file the DORA notification before you have enough information for the NIS2 early warning.

The solution: treat the DORA initial notification content as the minimum viable information set for all frameworks. At the 4-hour mark, you file DORA with what you know. You then update that information for the 24-hour NIS2 early warning. The NIS2 early warning can cross-reference the DORA notification ("Initial DORA notification filed at [time]").

Cross-Border Incidents: Who is the Lead Authority?

For incidents affecting users in multiple EU member states:

NIS2: Notify your home state CSIRT first. If cross-border impact is confirmed, your CSIRT notifies peer CSIRTs via the CSIRT Network. You file with your home state only.

GDPR: Notify your lead supervisory authority — the data protection authority in the EU member state where your main establishment is located (Art.56 GDPR). Cross-border coordination happens between supervisory authorities, not by you.

DORA: Notify your home state NCA. EBA/ESMA/EIOPA cross-coordination is handled at supervisor level.

For most companies: one notification per framework, to your home country authority. The authorities coordinate internationally.

The Digital Omnibus Transition: What to Build Now

Even though the Digital Omnibus "report once, share many" mechanism is not yet law, you can design your incident response infrastructure to be transition-ready:

1. Build a unified incident data model — capture all mandatory fields across all frameworks in one structured record. Fields are largely a superset, not conflicting sets.

2. Use authority-specific templates from the unified record — generate each regulatory notification from the shared data, not from scratch. When the Digital Omnibus unified form arrives, your data model maps directly.

3. Log notification timestamps per framework — you need to prove when each notification was filed. A shared log with per-framework timestamps is both compliant now and architecturally ready for unified logging.

4. Implement notification status tracking — track whether each framework has received its initial notification, whether follow-up is due, and when the final report is due. The Python coordinator above implements this pattern.

5. Review annually — the Digital Omnibus is moving through legislative procedure during 2026. Monitor EUR-Lex for the Parliament and Council positions. When it enters trilogue, the core "report once" mechanism will be largely fixed even before final text is agreed.

Cloud Act Intersection: Where You Store Incident Data Matters

A security incident in 2026 generates significant documentation: forensic data, logs, communications, notification records. Where this data is stored has its own compliance implications.

US cloud providers (AWS, Azure, GCP) are subject to CLOUD Act orders — US law enforcement can compel disclosure of data stored on US-managed infrastructure without prior EU legal process. This means:

For organisations handling critical infrastructure incident data, EU-sovereign incident response infrastructure (logging, forensics, notification tooling) eliminates this cross-border disclosure risk. Incident data subject to national security classification or subject to supervisory authority confidentiality obligations should never traverse US-managed storage.

The unified Digital Omnibus portal, when implemented, will operate under EU jurisdiction — a further argument for consolidating on EU infrastructure for incident response tooling.

30-Item EU Multi-Regulation Incident Reporting Readiness Checklist

Framework Coverage Assessment

Incident Classification Criteria

Notification Timelines and Procedures

Incident Response Runbook

Evidence and Documentation

Digital Omnibus Transition Readiness

Summary

EU incident reporting in 2026 requires satisfying parallel notification chains with different clocks, different authorities, and different content requirements. The dominant constraint is DORA's 4-hour initial notification for financial entities. NIS2 follows at 24 and 72 hours. GDPR's 72-hour window overlaps with NIS2 stage 2 but goes to a different authority.

The Digital Omnibus "report once, share many" proposal would unify this into a single notification, but it is currently a legislative proposal entering Parliament-Council negotiations. It will not be operational before 2027-2028. Build your 2026 incident response system for current law, with architecture that can adapt to the unified framework.

The Python EUIncidentReportingCoordinator class above implements the parallel deadline tracking your team needs during an active incident. Build from this into your incident management platform — the unified data model approach means you collect information once and generate each regulatory notification from the shared record, minimising duplicate work during an already stressful event.

See Also

This post is part of the sota.io EU Cyber Compliance Series. Previous post: EU Cybersecurity Act 2.0: What COM(2026) 11 Means for ICT Supply Chain Security. Next: CRA harmonised standards gap — self-certifying conformity before August 2026 standards arrive.