Article 23: Reporting obligations

To meet the article 23: reporting obligations requirement, you must be able to quickly identify “significant incidents” and notify the appropriate national CSIRT or competent authority without undue delay, then provide follow-up information and, where appropriate, inform affected service recipients. Build a timed incident reporting workflow with clear triggers, owners, and retained evidence. (Directive (EU) 2022/2555, Article 23)

Key takeaways:

• Define and operationalize what a “significant incident” means for your services, then train teams to apply it consistently. (Directive (EU) 2022/2555, Article 23)
• Implement a reporting playbook with roles, handoffs, and decision points so notifications happen fast and are consistent across jurisdictions. (Directive (EU) 2022/2555, Article 23)
• Retain exam-ready artifacts: incident timeline, triage rationale, submitted notices, and communications to customers where applicable. (Directive (EU) 2022/2555, Article 23)

Article 23 is an operations requirement disguised as a legal one. Supervisors will not grade you on whether you own the Directive text; they will grade you on whether your incident process reliably produces timely, accurate notifications with a defensible “why/why not” trail for each reportable event.

The practical challenge is repeatable classification. Most security teams can detect incidents; fewer can consistently decide which ones are “significant” for NIS 2 reporting and then package the right information to the right national authority quickly. That problem compounds if you operate in multiple EU Member States, run shared services across entities, or depend on third parties for core delivery (cloud, managed security, critical SaaS, telecom, OT support).

This page translates Article 23 into a requirement-level implementation blueprint: who must comply, what you must build, how to run it day to day, and what evidence you need ready for an exam or supervisory request. All legal references below are anchored to the Directive text. (Directive (EU) 2022/2555, Article 23)

Regulatory text

Provided excerpt (operator-relevant): Member States must ensure that essential and important entities notify their CSIRT or competent authority, “without undue delay,” of any incident with a significant impact on service provision (“significant incident”). Where appropriate, entities must also notify service recipients without undue delay when significant incidents are likely to adversely affect service provision. (Directive (EU) 2022/2555, Article 23)

What this means operationally

1. You need a decision mechanism to classify incidents as “significant” based on impact to your services. (Directive (EU) 2022/2555, Article 23)
2. You need a notification mechanism to the correct national reporting destination (CSIRT or competent authority, depending on the Member State’s approach). (Directive (EU) 2022/2555, Article 23)
3. You need a customer/recipient communications mechanism to notify recipients when the incident is likely to adversely affect them, and to do it promptly. (Directive (EU) 2022/2555, Article 23)
4. You must be able to prove you did the above, even when the incident was handled by a third party or happened in a shared environment. (Directive (EU) 2022/2555, Article 23)

Plain-English interpretation (what an examiner expects)

An examiner expects you to show:

• A documented definition of “significant incident” mapped to your services (not just a generic SOC severity scale). (Directive (EU) 2022/2555, Article 23)
• A single operational workflow that tells responders exactly:
  • who decides reportability,
  • who submits notifications,
  • who approves customer communications,
  • how to handle uncertainty in early hours. (Directive (EU) 2022/2555, Article 23)
• Evidence that the workflow is used in practice: completed templates, timestamps, and a defensible rationale when you chose not to notify. (Directive (EU) 2022/2555, Article 23)

Who it applies to (entity and operational context)

Entity scope: “Essential and important entities” in scope of NIS 2 as determined via Member State transposition and your classification. (Directive (EU) 2022/2555, Article 23; Directive (EU) 2022/2555)

Operational scope: This requirement applies whenever an incident affects (or is likely to affect) the provision of your in-scope services, including:

• incidents in production IT and OT environments supporting service delivery,
• incidents at third parties that provide a dependency for your service (cloud hosting, identity provider, managed service provider),
• incidents in shared corporate services if they materially affect regulated services (for example, central IAM or network). (Directive (EU) 2022/2555, Article 23)

Multi-country reality: Notification endpoints and procedures are set nationally; your operating model must route incidents to the right authority for each impacted jurisdiction. Treat “CSIRT vs competent authority” as a configurable routing step, not a policy footnote. (Directive (EU) 2022/2555, Article 23)

What you actually need to do (step-by-step)

Step 1 — Build an “obligation register” for reporting

Create a NIS 2 obligation register entry for Article 23 with:

• in-scope legal entities and services,
• jurisdictions of operation,
• reporting destinations (CSIRT or competent authority) per jurisdiction,
• primary and backup control owners (security ops + compliance/legal).
  This prevents the classic failure mode: everyone assumes someone else knows where to report. (Directive (EU) 2022/2555, Article 23)

Where Daydream fits: Many teams track obligations in spreadsheets that drift. Daydream can hold an obligation register with owners, jurisdictional notes, and milestones so reporting readiness work does not get lost between security and compliance handoffs.

Step 2 — Define “significant incident” for your services

You need a written classification standard that translates “significant impact on the provision of their services” into criteria your incident commander can apply. (Directive (EU) 2022/2555, Article 23)

Practical way to do it:

• Start with your service catalog (regulated services first).
• For each service, document impact dimensions you will use to determine “significant,” such as:
  • loss of availability of the service,
  • loss of integrity affecting outputs/customers,
  • compromise affecting confidentiality with service impact,
  • systemic effects (for example, common IAM outage).
• Add a “borderline” rule: when facts are unclear early, escalate to a named decision-maker and log the rationale. The law’s “without undue delay” standard makes “we waited for certainty” a weak position. (Directive (EU) 2022/2555, Article 23)

Step 3 — Codify an incident reporting workflow with timing triggers

Write a short playbook (aim for usability over length) with:

• Trigger: potential significant incident affecting an in-scope service. (Directive (EU) 2022/2555, Article 23)
• Roles: SOC/on-call, incident commander, compliance/legal reviewer, executive approver for recipient communications, third-party manager when a provider is involved.
• Routing: how you decide which Member State authority receives the notice. (Directive (EU) 2022/2555, Article 23)
• Templates: initial notification form, follow-up update form, and recipient notification template. (Directive (EU) 2022/2555, Article 23)
• Proof points: where timestamps come from (ticketing system, SIEM alert, email headers) and how they are retained.

Operational detail that prevents failures:

• Put the workflow inside the incident tooling (ticket type, required fields, approval steps). If it only exists as a PDF, responders will skip it under pressure.
• Establish a “single throat to choke” for submissions. Security investigates; a designated reporting owner submits to authorities to avoid conflicting statements.

Step 4 — Integrate third-party dependencies into incident reporting

Article 23 does not excuse you because “the cloud provider had the incident.” You still need to decide whether the impact to your service is significant and notify accordingly. (Directive (EU) 2022/2555, Article 23)

Minimum operational controls:

• Contractual requirement for critical third parties to notify you of incidents fast enough for you to meet your obligations.
• A vendor/third-party escalation path that lands directly in your incident queue.
• A dependency map that links each regulated service to critical third parties, so you can quickly assess service impact.

Step 5 — Run table-top exercises focused on reporting decisions

Do exercises that force real decisions:

• ambiguous early indicators,
• partial outages,
• third-party incidents with incomplete provider details,
• incidents spanning multiple Member States. (Directive (EU) 2022/2555, Article 23)

Capture outcomes as evidence: what was decided, by whom, with what information, and what would be improved.

Required evidence and artifacts to retain

Keep these artifacts in a central, access-controlled repository aligned to your retention policy:

1. Article 23 reporting playbook (current version + change history). (Directive (EU) 2022/2555, Article 23)
2. Significant incident classification standard mapped to your service catalog. (Directive (EU) 2022/2555, Article 23)
3. Incident logs and timelines showing detection, triage, escalation, and notification timestamps. (Directive (EU) 2022/2555, Article 23)
4. Copies of notifications submitted to CSIRT/competent authority and any follow-up communications. (Directive (EU) 2022/2555, Article 23)
5. Recipient notifications (when applicable) plus approval records and distribution list logic. (Directive (EU) 2022/2555, Article 23)
6. “Not reportable” memos for high-severity incidents that were reviewed and deemed not significant under your standard. These are critical in exams. (Directive (EU) 2022/2555, Article 23)
7. Third-party incident notices received from providers and your internal assessment of service impact. (Directive (EU) 2022/2555, Article 23)

Common exam/audit questions and hangups

Expect variations of:

• “Show me how you determine an incident is significant for NIS 2.” (Directive (EU) 2022/2555, Article 23)
• “Walk through the last major incident: when did you know, who decided, when did you notify, and what did you say?” (Directive (EU) 2022/2555, Article 23)
• “Which authority do you notify in each Member State where you operate, and how do you avoid misrouting?” (Directive (EU) 2022/2555, Article 23)
• “How do you handle incidents at third parties that affect your service?” (Directive (EU) 2022/2555, Article 23)
• “When do you notify service recipients, and who approves that communication?” (Directive (EU) 2022/2555, Article 23)

Hangups that create findings:

• Your SOC severity scale is presented as the “significant incident” definition, but it is not tied to service impact.
• Notification content varies widely between incidents because there is no template and no single owner.
• You cannot show when you became aware of the incident versus when you notified.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating “without undue delay” as “after we finish the investigation”	Supervisors expect early notification based on known facts. (Directive (EU) 2022/2555, Article 23)	Use an initial notification template designed for partial information and a follow-up update path.
No documented “not reportable” rationale	Exams test governance and consistency. (Directive (EU) 2022/2555, Article 23)	Require a short decision record for borderline cases, approved by the reporting owner.
Third-party incidents handled outside your incident process	You lose time and evidence; impact assessment becomes informal. (Directive (EU) 2022/2555, Article 23)	Create a third-party incident intake channel and link it to each regulated service dependency map.
Multi-jurisdiction confusion	Wrong destination or inconsistent statements across countries. (Directive (EU) 2022/2555, Article 23)	Maintain a jurisdictional routing matrix in the obligation register and embed it into the playbook.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so this section is limited to direct operational risk.

Risk to manage:

• Regulatory exposure: failure to notify, late notification, or inconsistent reporting can trigger supervisory action under national transposition of NIS 2. (Directive (EU) 2022/2555, Article 23; Directive (EU) 2022/2555)
• Customer and contractual exposure: delayed or unclear recipient communications can create downstream claims, termination rights, or loss of trust, especially where your service supports critical functions. (Directive (EU) 2022/2555, Article 23)
• Governance exposure: weak evidence (missing timelines, missing decision records) turns a manageable incident into a compliance problem because you cannot prove you acted appropriately. (Directive (EU) 2022/2555, Article 23)

Practical 30/60/90-day execution plan

Use phases (not day counts) to avoid false precision and to fit your change calendar.

First 30 days (Immediate readiness)

• Confirm NIS 2 in-scope entities/services and assign an Article 23 owner in compliance and in security operations. (Directive (EU) 2022/2555, Article 23)
• Stand up the Article 23 obligation register entry with jurisdiction routing and backups. (Directive (EU) 2022/2555, Article 23)
• Draft the significant incident classification standard tied to the service catalog; get sign-off from security and the business owner of each in-scope service. (Directive (EU) 2022/2555, Article 23)

Days 31–60 (Operationalization)

• Publish the incident reporting playbook with templates and an internal RACI. (Directive (EU) 2022/2555, Article 23)
• Implement the workflow in your ticketing/IR tooling (required fields, approval steps, evidence attachments). (Directive (EU) 2022/2555, Article 23)
• Add third-party incident intake and escalation, and test it with at least one critical third party. (Directive (EU) 2022/2555, Article 23)

Days 61–90 (Prove it works)

• Run a table-top focused on a cross-border, third-party-driven outage scenario; produce a completed notification pack as if it were real. (Directive (EU) 2022/2555, Article 23)
• Perform an evidence audit of the last material incident: can you reconstruct the timeline and decisions from artifacts alone? (Directive (EU) 2022/2555, Article 23)
• Finalize metrics for internal governance (for example, “time from detection to reportability decision,” tracked qualitatively or comparatively without publishing unsupported numeric targets). (Directive (EU) 2022/2555, Article 23)

Frequently Asked Questions

Do we have to report every security incident under Article 23?

No. Article 23 is triggered by an incident with a significant impact on the provision of your services, and you need a defensible method to decide significance. (Directive (EU) 2022/2555, Article 23)

Who submits the notification: the SOC, legal, or compliance?

Article 23 does not prescribe your internal org chart, but you need a defined owner who can submit promptly and consistently and coordinate inputs from security and legal. Document the handoffs in your playbook. (Directive (EU) 2022/2555, Article 23)

What if the incident is at a third party (cloud/MSP/SaaS) and we lack details?

You still assess whether your service is significantly impacted and notify without undue delay based on known facts, then send follow-up information as it becomes available. Build contracts and escalation paths so third-party facts flow into your process quickly. (Directive (EU) 2022/2555, Article 23)

Do we always have to notify our customers/service recipients?

No. Article 23 ties recipient notification to situations where significant incidents are likely to adversely affect the provision of the service, and it also frames this as “where appropriate.” Your playbook should include criteria and an approval path for these communications. (Directive (EU) 2022/2555, Article 23)

We operate in multiple EU countries. Do we report once or multiple times?

Article 23 points you to the relevant CSIRT or competent authority, which is implemented through Member State structures. Maintain a jurisdiction routing matrix and decision record for which authority you notified and why. (Directive (EU) 2022/2555, Article 23)

What evidence matters most in an exam for reporting obligations?

Auditors typically want timelines, the reportability decision rationale, copies of submissions, and proof of recipient communications when applicable. If you cannot show timestamps and approvals, you will struggle to prove “without undue delay.” (Directive (EU) 2022/2555, Article 23)