Incident workflowEU

NIS2 incident clock triage workflow

Use this workflow when a security event might be a NIS2 significant incident and the organisation needs to decide what clock is running, who must act, and what evidence belongs in the file.

Built for incident response, legal, compliance, customer communications, service owners, and management-body reporting teams that need a shared Article 23 triage record.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Sections
6

Structured answer sets in this page tree.

Primary sources
7

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

NIS2 Article 23 reporting runs from awareness of a , not automatically from the first alert, ticket, or confirmation of root cause. Preserve every earlier timestamp, because it shows how quickly the entity assessed the event. This workflow helps teams record awareness, test significance, route staged notifications, and continue containment and recovery. Before using it, check whether an equivalent sector-specific Union act applies to the same activity under NIS2 Article 4.

Section 1

Start the clock file before the facts are complete

Open the clock file when an event could have a significant impact on an in-scope service. Decide whether the entity has enough information to treat the event as a potential NIS2 and preserve the awareness timeline; a final report can be developed later.

Separate four timestamps: first technical signal, human triage, entity awareness of the , and each authority submission. Article 23 deadlines run from awareness of the significant incident. For provider types covered by Commission Implementing Regulation (EU) 2024/2690, recital 31 says awareness follows an initial assessment that gives the entity a reasonable degree of certainty that a significant incident has occurred. Other entities should check national law and authority guidance rather than assuming that recital controls their case.

Confirm scope before treating the clock as a legal deadline. Article 23 applies to essential and important entities through the Member State law implementing NIS2. A voluntary vulnerability disclosure, near-miss report, or sector-specific report may use a different trigger and route; do not merge it into the Article 23 clock unless the applicable law requires that result.

  • Open a clock record for major service disruption, suspected malicious activity, financial-loss indicators, third-party harm, or possible cross-border impact.
  • Record the affected legal entity, service, Member State route, system, supplier, customer group, and current incident commander.
  • Keep known facts, estimates, unknowns, and planned updates in separate fields.
  • If the event is closed below the significant-incident threshold, keep the non-reporting rationale and the facts available at the time.
Section 2

Run the Article 23 significance triage

Use the significance triage to decide whether Article 23 is in play. Under NIS2, a is tied to severe operational disruption, financial loss for the entity, or considerable material or non-material damage affecting other natural or legal persons.

The triage should produce a defensible yes, no, or continue-monitoring decision. It should not wait for perfect forensic certainty, and it should not turn every security alert into a reportable incident without linking the facts to the Article 23 impact test.

  • Service impact: what service is affected, how important is it to the entity's provision of services, and is disruption actual or reasonably expected?
  • Severity and duration: what is known about outage, degradation, data exposure, safety, operational dependence, or recovery uncertainty?
  • Financial loss: what loss indicators are known or reasonably estimated from downtime, remediation, service credits, fraud, or interrupted operations? For providers covered by Regulation 2024/2690, use its definition and threshold rules rather than an improvised loss list.
  • Third-party damage: could customers, recipients, suppliers, patients, citizens, or other legal persons suffer considerable material or non-material damage?
  • Cross-border impact: could affected services, recipients, infrastructure, or suppliers involve two or more Member States?
Section 3

Map the reporting clocks before drafting the message

When the triage points to a , move immediately to the staged Article 23 clock. The early warning is due without undue delay and in any event within 24 hours of awareness. The incident notification is due without undue delay and in any event within 72 hours of awareness.

Use the 24-hour step to alert the or competent authority with the information needed at that point, including whether malicious or unlawful acts are suspected and whether there may be cross-border impact. Use the 72-hour step to update the early warning with an initial severity and impact assessment and available indicators of compromise.

  • 24-hour early warning: awareness timestamp, affected service, initial incident summary, suspected malicious or unlawful cause where applicable, and possible cross-border impact.
  • 72-hour incident notification: updated facts, initial severity and impact assessment, available indicators of compromise, and unresolved information gaps.
  • Intermediate report: prepare status updates if the or competent authority requests them.
  • Final report: due not later than one month after the incident notification, covering severity, impact, likely threat type or root cause, mitigation, and cross-border impact where applicable.
  • Ongoing incident path: if the incident is still ongoing when the final report would be due, provide a progress report and then a final report within one month of handling the incident.
Section 4

Assign authority, recipient, and escalation owners

The triage record should identify who owns each external communication path. Article 23 notification goes to the or, where applicable, the competent authority. Recipient communications are a separate decision when significant incidents are likely to adversely affect the provision of services or when recipients can take measures or remedies in response to a significant cyber threat.

Do not leave cross-border, law-enforcement, trust-service-provider, or public-disclosure questions until after the deadline. Article 23 includes routes for single points of contact, other affected Member States and ENISA, law-enforcement guidance where criminal activity is suspected, and public awareness where necessary or in the public interest.

  • Authority owner: confirms the national or competent-authority portal, form, backup contact, and submission receipt process.
  • Recipient owner: decides whether affected service recipients need measures, remedies, or threat information in clear language.
  • Legal owner: checks sector-specific Union law, trust-service-provider handling, law-enforcement guidance, confidentiality, and privilege questions.
  • Cross-border owner: flags affected Member States, shared infrastructure, multinational customers, and supplier dependencies.
  • Management owner: receives concise status updates without slowing containment, eradication, recovery, and reporting work.
Section 5

Preserve the evidence that explains the clock decision

A usable clock file shows what the team knew, when it knew it, why the incident was or was not treated as significant, and what was submitted or communicated at each reporting point. The record should support live response first and later review second.

For entities covered by Commission Implementing Regulation (EU) 2024/2690, align the triage evidence with the required incident-handling policy: incident categorisation, escalation, communication plans, assigned roles, response documents, documentation, reporting, and post-incident improvement.

  • Clock evidence: detection source, initial assessor, awareness decision, authority-deadline calculations, and submission timestamps.
  • Impact evidence: service metrics, outage or degradation windows, affected recipients, financial-loss indicators, material or non-material damage indicators, and cross-border facts.
  • Response evidence: containment decisions, mitigation measures, indicators of compromise, root-cause hypotheses, supplier inputs, and unresolved uncertainty.
  • Communication evidence: authority submissions, acknowledgements, recipient notices, management updates, and public-disclosure decisions.
  • Review evidence: post-incident lessons, policy or runbook changes, control updates, and reasons for reopening or closing the clock file.
Section 6

Clock-triage closure checklist

Close the clock triage only after the team can explain the decision from the record alone. If the event remains uncertain, keep the file open with a named owner, next fact needed, and next review time.

The closure decision should also consider whether the incident triggers post-incident review, risk-assessment updates, business-continuity changes, supplier follow-up, or management-body reporting. The implementing regulation repeatedly ties significant incidents to review and update duties for incident handling, risk treatment, continuity, crisis management, and related controls.

What timestamp starts the NIS2 incident clock?

Article 23 deadlines run from becoming aware of the . For provider types covered by Commission Implementing Regulation (EU) 2024/2690, recital 31 treats awareness as the point when an initial assessment gives the entity a reasonable degree of certainty that a significant incident has occurred. Other entities should preserve their assessment timeline and apply the relevant national rule or authority guidance.

Should the team wait for root cause before opening the clock file?

No. The clock file should open when the event could be a . The final root cause can be updated later through the incident notification, requested intermediate reports, final report, or progress report path.

  • The awareness timestamp and Article 23 deadline calculations are recorded and approved.
  • The significance decision is linked to service disruption, financial loss, third-party damage, and cross-border indicators.
  • The authority route, recipient route, legal route, and management route each have an owner.
  • Known facts, estimates, unknowns, and corrections are separated across every draft and submission.
  • The file states whether the workflow is closed, still monitoring, converted to the Article 23 reporting workflow, or reopened after new facts.
Recommended next step

Prepare the awareness clock, reporting route, and evidence fields before the incident

Sorena can help convert this NIS2 incident-clock workflow into cited templates, escalation rules, owner assignments, and evidence requests that incident teams can use under time pressure.

Primary sources

References and citations

eur-lex.europa.eu
Referenced sections
  • Primary legal source for Article 23 significant-incident reporting, notification clocks, recipient communications, cross-border handling, and final-report content.
"Reporting obligations"
ciras.enisa.europa.eu
Referenced sections
  • ENISA incident-reporting portal context for national authority reporting and aggregated incident analysis.
"national authorities"
eur-lex.europa.eu
Referenced sections
  • Supports post-incident review and updates after significant incidents for covered digital and ICT service entities.
"significant incidents"
Related guides

Explore more topics

Are managed service providers in scope of NIS2?
NIS2 scope answer for managed service providers and managed security service providers, including service definition, size-cap checks, entity status, and jurisdiction evidence.
EU NIS2 Directive applicability test for entity scope
Stepwise NIS2 applicability test for Annex I and Annex II sectors, medium and large entities, size-independent cases, essential or important classification, jurisdiction, and evidence.
EU NIS2 Directive deadlines and compliance calendar | Article 23 clocks
NIS2 compliance calendar for EU transposition, Article 3 and 27 registration updates, Article 23 incident reports, technical measures, and the 2027 review.
NIS2 24-hour early warning: what to send and when
Under NIS2 Article 23, covered essential and important entities submit an early warning within 24 hours of becoming aware of a significant incident.
NIS2 72-hour incident notification FAQ
NIS2 incident-notification deadline, required initial assessment, evidence, follow-up, and the 24-hour trust-service-provider exception.
NIS2 Annex I and Annex II Sector Scoping Guide
Map NIS2 Annex I and Annex II sectors, entity types, size-cap rules, and essential versus important entity classification with official EU sources.
NIS2 Article 21 control baseline and evidence checklist
Build a NIS2 Article 21 control baseline from the Directive's minimum cybersecurity risk-management measures, proportionality test, supplier duties, and evidence expectations.
NIS2 Article 21 control-by-control evidence checklist
Map NIS2 Article 21 risk-management measures to evidence records for governance, incident handling, continuity, supply chain, testing, cyber hygiene, cryptography, access, assets, and authentication.
NIS2 Article 21 Gap Assessment Workflow: controls, evidence, and owners
Assess NIS2 Article 21 cybersecurity risk-management gaps by mapping current controls to Article 21(2), ownership, evidence, supplier risk, and management review.
NIS2 Article 23 incident notification workflow
Map NIS2 Article 23 reporting duties for significant incidents: 24-hour early warning, 72-hour notification, intermediate reports, final report, recipients, and evidence.
NIS2 Compliance Checklist: scope, controls, reporting
This NIS2 compliance checklist helps confirm scope, entity classification, management-body duties, Article 21 controls, Article 23 reporting, and evidence.
NIS2 Compliance Guide: scope, controls, reporting, and evidence
A practical NIS2 compliance guide for mapping entity scope, Article 21 risk measures, Article 23 incident reporting, management accountability, and evidence records.
NIS2 Country Implementation Matrix: Authorities, Portals, and Local Deltas
Build an operational NIS2 country matrix for applicable national law, competent authorities, registration, incident portals, local implementation deltas, evidence, and review dates.
NIS2 entity classification FAQ
Plain-English FAQ comparing NIS2 essential entities and important entities, with Article 3 classification rules, shared Article 21 and 23 duties, supervision differences, and evidence to keep.
NIS2 Entity Classifier Workflow: essential vs important entity scoping
Classify whether an EU service is out of scope, an important entity, an essential entity, or needs national-authority review under the NIS2 Directive.
NIS2 entity supervision guide
Compare NIS2 essential and important entities by scope, Article 21 and 23 duties, Article 32 and 33 supervision, evidence, jurisdiction, and penalties.
NIS2 essential vs important entities: Article 3 scope and supervision guide
Classify NIS2 essential and important entities using Article 3, Annex I and II sector scope, size-cap rules, registration evidence, and the Article 32/33 supervision split.
NIS2 FAQ: scope, Article 21 controls, incident reporting, and penalties
NIS2 FAQ on entity scope, essential and important classification, Article 21 measures, Article 23 reporting, national implementation, and evidence.
NIS2 Incident Reporting Workflow: 24-hour, 72-hour, and final report steps
Build a NIS2 Article 23 incident reporting workflow with significance triage, CSIRT or authority notification steps, recipient communication, cross-border checks, and evidence records.
NIS2 Management Body Accountability: board duties, training, and evidence
A guide to NIS2 Article 20 management body accountability: approval of Article 21 measures, oversight, national liability rules, training, reporting lines, and evidence.
NIS2 Member State Transposition: What Teams Must Check
How to handle NIS2 Member State transposition: use Article 41 as the EU baseline, then verify national law, authority routing, registration, and incident-reporting details.
NIS2 National Transposition Tracker: EU Member State Evidence Register
Track NIS2 national transposition with Commission country pages, Article 41 dates, reasoned-opinion flags, source wording, authority contacts, and legal review triggers.
NIS2 penalties and fines: Article 34 maximum levels and factors
NIS2 Article 34 fine levels, calculation factors, enforcement measures, GDPR overlap, and national-law checks for essential and important entities.
NIS2 Registration and Authority Notification Guide
Map NIS2 Article 3 entity-list duties, Article 27 registry submissions, competent-authority contacts, and national registration portal evidence without inventing country deadlines.
NIS2 Requirements: scope, Article 21 controls, reporting, and evidence
Map NIS2 requirements for essential and important entities: scope classification, management-body duties, Article 21 cybersecurity measures, Article 23 incident reporting, and evidence records.
NIS2 Size Cap Rule and Special Scope Cases
Apply the NIS2 medium-size test, group-data rules, regardless-of-size cases, exclusions, and essential-versus-important classification.
NIS2 size-cap rule: when medium and large entities are in scope
Plain-language FAQ on the NIS2 size-cap rule: medium and large Annex I or II entities, SME thresholds, regardless-of-size exceptions, and evidence to keep.
NIS2 Supply Chain Security Program: Article 21 Guide
Apply NIS2 Article 21 to direct suppliers and service providers, and distinguish its general duty from Regulation 2024/2690's digital-entity controls.
NIS2 vs CER Directive comparison: cyber obligations and critical-entity resilience
Compare NIS2 and the CER Directive using cited rows for scope, triggers, evidence, incident handling, supervision, and shared critical-entity work.
NIS2 vs DORA: scope, overlap, and evidence for EU cyber compliance
Compare NIS2 and DORA for EU cyber compliance: covered entities, when DORA replaces NIS2 duties for financial entities, incident reporting, evidence, and supervisory handoffs.
NIS2 vs GDPR breach reporting: EU deadlines and overlap
Compare NIS2 significant-incident reporting with GDPR personal-data-breach reporting, including scope, 24-hour and 72-hour clocks, evidence, and overlap.
NIS2 vs ISO/IEC 27001: legal duties, ISMS evidence, and reuse limits
Compare NIS2 legal obligations with ISO/IEC 27001 ISMS requirements: scope, Article 21 controls, incident clocks, SoA evidence, audits, and certification reuse.
NIS2 vs ISO/IEC 27017: legal duties, cloud controls, and reuse limits
Compare NIS2 legal obligations with ISO/IEC 27017 cloud-service controls: entity scope, Article 21 measures, incident clocks, shared responsibility, evidence, and assurance limits.
NIS2 vs NIS1: what changed in EU cybersecurity compliance
Compare NIS2 with the repealed NIS1 Directive: expanded sectors, essential and important entities, management-body duties, Article 21 controls, Article 23 reporting, and supervision.