Article 23(4)(b) NIS2 72-hour incident notification

What Article 23(4)(b) asks for within 72 hours of awareness

Once an entity has confirmed a significant incident, its incident notification is due without undue delay and in any event within 72 hours of becoming aware of it. The notification updates the early warning sent under Article 23(4)(a), so it must read as a continuation of that filing, not a new report. It has to give an initial assessment of the incident, covering its severity and impact and, where available, indicators of compromise. The point of the step is to let the CSIRT or competent authority judge whether the incident has cross-border effects and whether other Member States or ENISA need to be told. Without that assessment, authorities cannot coordinate a response or decide whether the public needs warning.

The difficulty is that the 72-hour clock runs while the incident is still changing. Scope often grows after the early warning, affected systems are still being identified, and the first impact estimate is made with incomplete logs. The early warning itself was usually filed under the 24-hour limit with little information, so the notification has to correct or extend earlier statements without contradicting them. Teams should decide in advance who owns the severity and impact judgment, who approves the filing, and how uncertain facts are labeled as provisional. Reusing the early warning reference and keeping a dated record of each version of the assessment makes later reports easier to check.

No certificate is issued for this step. Nobody certifies that a notification was adequate. National competent authorities judge compliance through inspections, security audits, information requests and, where needed, enforcement, so the evidence that matters is the notification itself, its timestamps and the internal record showing how severity and impact were determined. Ask your legal and incident response advisers which national CSIRT or authority receives your filings and confirm its submission format and channel, since the Commission may set detailed formats through implementing acts under Article 23(11).

Which entities, incidents and systems the 72-hour notification covers

The 72-hour notification applies only once an incident is significant and the entity is in scope of its national law. Each card below is a scoping decision that changes who reports, what counts, and which systems must be traced before the clock starts.

Essential and important entities

Article 23 applies to entities classed as essential or important under Article 3, as implemented in each Member State's law. Both classes owe the same reporting duty, but supervision differs, so the classification drives how closely an authority will check the notification. Confirm your classification with the national competent authority or your legal counsel, and check whether a sector-specific law displaces NIS2 for your entity.

The 24-hour rule for trust services

Trust service providers must notify significant incidents affecting their trust services within 24 hours of becoming aware of them, not 72 hours. Any organization that offers trust services and runs a 72-hour process will miss this shorter deadline. Set the trust service scope in your incident procedure and test the faster path with a tabletop exercise.

Significant incidents under Article 23(3)

The 72-hour clock starts only for a significant incident, meaning one that meets the Directive's two-part test. For the digital entity types listed in Implementing Regulation 2024/2690, the quantified thresholds decide significance. Map each service to those criteria before an incident happens, so the team can answer the significance question within hours rather than days.

Incidents affecting two or more Member States

The notification must give enough information for the CSIRT or authority to judge cross-border impact. Where an incident concerns two or more Member States, the national body informs the other states and ENISA. Record where your users, data and infrastructure sit, so you can identify affected Member States early in the report.

Managed and third-party systems

An incident in a provider's platform can become your significant incident if it affects your service, your data or your users. Contracts should require suppliers to tell you quickly enough to meet your own deadline, and your logs should cover the hosted systems they touch. Confirm what each provider can see and share, because the 72 hours run from when you become aware.

Channel and format set nationally

The national authority or CSIRT sets the reporting channel, the format and the procedure for notifications, and the Commission may add implementing acts on the type of information. Do not assume a single EU portal or template. Ask your competent authority for its submission channel, required fields and any registration you must complete before the first incident.

How an assessor tests the 72-hour notification

This table sets out what an assessor checks for the Article 23(4)(b) notification, the evidence each check expects and the findings that most often cause problems. Read each row as a test: the question asked, the record that answers it and the gap that usually surfaces. The main takeaway is that the 72-hour clock can only be proven if the awareness time was recorded when it happened.

Test area	What the assessor checks	Evidence expected	Common finding
Awareness time	The time the entity became aware of the significant incident, which starts the 72-hour clock	Timestamped detection or triage record in the case system, with the person who logged it	Awareness time not recorded, or back-filled after the fact
Submission timing	Whether the notification was sent without undue delay and within 72 hours of awareness	Submission log showing date, time and channel, compared with the awareness record	Clock start is unclear, so the timing cannot be shown
Update to the early warning	Whether the notification updates the early warning where one was sent	Copy of the early warning alongside the notification, with the changes identified	Notification repeats the early warning without an updated assessment
Severity and impact	Whether an initial assessment of severity and impact is stated	Assessment worksheet or case record showing the basis for each rating and its date	Ratings given without rationale or left as placeholders
Indicators of compromise	Whether available IOCs are included, or the reason none were available is stated	IOC list exported from the case or threat intelligence platform, with hashes, addresses or domains	IOCs omitted without explanation, or unverified indicators presented as confirmed
Cross-border information	Whether information needed to determine any cross-border impact was included where relevant	Impact analysis listing affected Member States and services, with the reasoning recorded	No check made for cross-border effects on incidents touching other countries
Trust service provider path	Whether a trust service provider applied the 24-hour rule instead of 72 hours	Sector classification record and a notification timeline showing the 24-hour deadline was used	Provider applied the 72-hour deadline by default
Approval and sign-off	Who approved the submission and whether that approval was recorded before it was sent	Approval record with name, role, time and version of the notification	No record of who approved the submission

Implementing the 72-hour notification step by step

This sequence turns the Article 23(4)(b) notification into a repeatable process, so the incident lead can submit an update to the early warning with a documented severity and impact assessment and a record of every decision. Each step names the artifact that proves it was done.

Record the time of awareness
The incident lead writes down the moment the entity became aware of the significant incident, in UTC, with the name of the person who recorded it and the source of the first signal. Article 23(4)(b) measures the 72-hour window from that point, so this timestamp is the anchor for every later deadline. The output is a dated entry in the incident record that the rest of the file refers back to. Confirm with your national authority how it expects awareness to be defined, because that definition controls the clock.
Confirm the significance decision
The incident lead, with the legal or compliance owner, checks the early warning decision against the significance criteria that apply to the entity, including any thresholds set by Implementing Regulation (EU) 2024/2690 for the entity type. They record which criteria were met and why, and they note any open questions. The output is a signed significance note that states the criteria, the facts relied on and the decision. Without this note, the notification has no documented basis.
Pull the early warning and open the case
The team retrieves the early warning already submitted under Article 23(4)(a) and opens or links a single case in the incident management system, so that all facts, tasks, assets and evidence sit in one record. The notification must be consistent with the early warning and update it, so the case should reference the same identifiers. The output is a case record that carries the early warning reference, the awareness timestamp and the assigned owners.
Complete the initial severity and impact assessment
The incident lead and technical responders describe what the incident affected, which services, users, data and dependencies, how long the disruption lasted or is expected to last, and how severe the impact is at this stage. The assessment is labeled as initial and states what is still unknown. The output is a written severity and impact section with a version date, linked to the timeline in the case record. Reassessment is expected as facts change, so each version should be kept.
Extract indicators of compromise with confidence notes
Responders extract indicators of compromise such as file hashes, IP addresses, domains, URLs and account names from logs, endpoint tools and the case evidence, and they record a confidence level and the source of each indicator. Indicators that cannot be confirmed are marked as suspected rather than removed. Sharing is controlled, so the team checks the handling rules before any export. The output is an indicator list with source, timestamp, confidence and handling marking, which can be included where available in the notification.
Check cross-border impact and public information needs
The incident lead reviews whether services, users or other entities in other Member States are affected, and whether the incident could affect public awareness. Where cross-border effects are possible, the notification must give the information that lets the authority determine that impact. Any question about informing the public is raised with the authority after consultation, because Article 23(7) gives the decision to the authority. The output is a short note listing Member States considered, the reasoning and any questions to ask the authority.
Approve and submit the notification
The accountable manager reviews the draft against the authority's template, confirms the content matches the case record, and approves submission through the channel the authority specifies. The national authority's template and channel take precedence over any internal format. The output is the submitted notification, the approval record and the transmission receipt or reference number. Confirm the submission time is before the 72-hour limit measured from awareness.
Log the submission and schedule follow-up
The team records the submission time, the reference number, the people involved and any authority acknowledgement in the case record, then schedules the next reporting steps and any requests for information. Changes after submission are logged as new versions rather than overwritten, so the file shows what was known at each point. The output is an updated case with a complete audit trail that a supervisor can review. Your internal policy should state who is responsible for keeping this log current.

What the notification must contain beyond the early warning

The 72-hour notification is not a second copy of the early warning. Under Article 23(4)(b), it updates the early warning where one was sent and adds an initial assessment of the incident, covering its severity and impact, and, where available, indicators of compromise. The early warning was written to say that a significant incident exists and to start the conversation with the CSIRT or competent authority. The notification has to show what the incident actually did: which services, systems and users were affected, how far the impact has spread, whether data integrity or availability was lost, and whether any cross-border effect is visible. Incident response leads should assign one person to own this update and should keep a dated log of the facts that changed between the two submissions.

Indicators of compromise are the part teams most often delay, because they wait for a complete forensic picture. The Directive asks for them only where available, so the practical rule is to submit what is confirmed at the deadline, label unconfirmed items as such, and commit to a follow-up through the intermediate or final report. Hashes, domains, IP addresses and file paths from the case record can be pulled from the incident platform, for example from the asset and IOC records in DFIR-IRIS, and checked against the evidence log before they go out. Entities should define in advance who can release IOCs, how they are formatted, and whether they will be shared with other entities, since sharing indicators with outside parties is a separate decision.

Two points need a check before any template is finalized. First, the Commission may adopt implementing acts under Article 23(11) that set the type of information, the format and the procedure for notifications, so the fields and channel must be confirmed against the current national rules and the authority's own forms. Second, after consulting the entity, the CSIRT or authority may inform the public, or require the entity to do so, where public awareness is needed to prevent or handle the incident or is otherwise in the public interest (Article 23(7)). The notification should therefore state whether customers or users are already affected, what they should do, and who will speak for the organization, so that a public-communication request can be answered within the same working day.

Which evidence shows the 72-hour notification was met

An authority reviewing a 72-hour notification will reconstruct the timeline from records, not from memory. The cards below cover the artifacts that establish when the entity became aware, what it reported, how it assessed the incident and who approved the submission.

Timestamped awareness record

This record fixes the moment the entity became aware of the significant incident, which starts the 72-hour clock under Article 23(4)(b). Capture it from the alerting or ticketing system with the time zone and the source of the alert, not from a later reconstruction. Check that the awareness time matches the early warning timestamp and that any gap between detection and triage is explained in writing.

Submission copies and receipts

Keep the exact text of the early warning and of the notification as submitted, together with the submission receipt, portal confirmation or transmission log from the competent authority or CSIRT. The notification must update the early warning, so the two documents should be readable side by side. Confirm with your national authority which channel and format it accepts.

Severity and impact assessment

The notification must include an initial assessment of severity and impact. Record the method used, the scoring inputs, the assessor's name and role, and the date of each revision. An auditor will test whether the assessment was made on the information available at the time and whether later changes are versioned rather than overwritten.

IOC list with sources and confidence

Where indicators of compromise are available, the notification should include them. Keep each indicator with its source feed or analyst, the date observed, a confidence rating and the sharing restriction applied. Indicators that could not be verified in time should be labeled as unverified rather than omitted, so the record shows what was known when the deadline passed.

Cross-border impact determination

Document whether the incident affects another Member State, which entities or services are involved and how that conclusion was reached. Article 23 requires entities to provide information that lets the authority determine cross-border impact. A short, dated determination memo signed by the responsible officer shows the question was asked even when the answer is that no other state is affected.

Approval record and case timeline

Retain the approval of the notification by the person authorized to submit it, with the time of approval, and link it to the case timeline. The timeline should show every action between awareness and submission, including who did what and when, drawn from the case management record and its audit trail. Confirm your internal approval rule with legal counsel before the first incident.

What meeting the 72-hour notification costs in money and effort

This table breaks down what the 72-hour notification step costs in licenses, staff time, evidence upkeep, exercises and outside help, and marks each item as one-time or recurring. Read it as a checklist for building a quote: the drivers column shows what raises each cost and the reduction column shows what keeps it down. No prices are given because none are supplied; ask each provider for the figures against your own scope.

Cost component	Who is paid and for what	One-time or recurring	What drives it up or down
Case management tooling	Software vendor or self-hosted platform setup. DFIR-IRIS (LGPL-3.0-or-later) carries no license fee, but hosting, integration and hardening are still billed as services.	One-time setup, recurring hosting and support	Up: number of SIEM, EDR and REST sources feeding cases. Down: self-hosted tools with no license spend, reused case templates.
Threat intelligence and IOC tooling	Platform setup and connector work for MISP and OpenCTI, plus any commercial feed subscriptions you choose to buy.	One-time integration, recurring feed subscriptions	Up: IOC volume and complexity, number of sharing groups. Down: limiting feeds to sources you will actually use in notifications.
Engineering and incident lead time per notification	Internal analysts or an outsourced managed SOC billing hours per incident to produce the severity, impact and IOC assessment.	Recurring, per incident	Up: number of incidents, cross-border impact needing analysis for several Member States. Down: pre-agreed notification content and clear decision rights.
Staffing across time zones	Internal rota or a retainer with a provider covering nights and weekends, so the 72-hour clock is watched at all hours.	Recurring	Up: staff spread over many time zones, thin on-call coverage. Down: a single rota with defined escalation and one named owner per shift.
Notification templates and evidence upkeep	Internal compliance or security staff, or an implementation partner, keeping templates, timelines and audit logs current.	One-time drafting, recurring maintenance	Up: frequent changes to the national reporting channel or the CSIRT requirements. Down: templates tied to the Article 23 content and reviewed after each exercise.
Exercises that rehearse the 72-hour clock	Internal time for tabletop and simulated incidents, or an external provider running them and writing the findings.	Recurring, usually scheduled	Up: number of scenarios, cross-border simulations, scope of technical drills. Down: short, focused tabletop exercises run against the same template.
External review or testing	An independent reviewer or tester checking that notifications and logs meet the requirement. DeployOpen prepares systems and evidence, but only an independent assessor issues reports.	One-time review, periodic re-testing	Up: broader scope and more systems in evidence. Down: a narrow, written scope agreed before work starts.
After-hours retainer	A provider on call to help draft and submit the early warning and 72-hour notification outside working hours.	Recurring, fixed or per-call	Up: response time expectations, number of entities or Member States covered. Down: defined response windows and a clear trigger for calling the retainer.

Which self-hosted open-source tools support the notification record

An Article 23(4)(b) notification has to reflect what the team actually knew at the 72-hour mark, including severity, impact and indicators of compromise. The two tools below cover the case record and the indicator side, and the reader must confirm each one fits their environment and license obligations.

DFIR-IRIS as the case record

DFIR-IRIS keeps one case that holds assets, indicators, tasks and evidence, with an audit trail of changes. For a 72-hour notification, that trail lets the team show when each fact was established and what the initial severity assessment was based on. Check whether your alert sources (SIEM, EDR, REST feeds) can feed cases and who is authorized to edit the record.

Timeline and reports from case data

DFIR-IRIS builds a consolidated investigation timeline and generates reports from case data. Used well, this turns the notification content into a view of the case rather than a rewrite from memory. Confirm that the report output can be adapted to the format and fields your competent authority or CSIRT requires, since the notification format is set by the authority, not by the tool.

MISP for indicator correlation

MISP correlates indicators by exact match and by advanced patterns such as fuzzy hashes and CIDR overlaps. This helps the team decide which observed indicators of compromise are linked to the incident and which are only similar. Record sightings and confirm that sharing groups and distribution settings do not expose sensitive incident details beyond what the notification requires.

MISP exports for the IOC section

MISP exports indicators to STIX 1 and 2, CSV, and Suricata, Snort and Zeek rule formats through its REST API. These exports let the notification list indicators in a structured form and let detection teams deploy the same indicators. Check which export format the authority accepts and whether your license obligations under AGPL-3.0-only apply to any modifications you make to the deployed instance.

Confirm fit before relying on the tools

Neither tool decides whether an incident is significant, what the authority accepts, or when the clock starts. Confirm each tool's capabilities against the current version in your environment, review the license terms (LGPL-3.0-or-later for DFIR-IRIS, AGPL-3.0-only for MISP) with counsel, and test the export path to the authority's channel before an incident occurs.

Who does what for the 72-hour notification

Your organization owns the reporting obligation. Under Article 23(4)(b), the entity must submit the incident notification without undue delay and within 72 hours of becoming aware of the significant incident, and that duty sits with the entity, not with any consultant or service provider. The people accountable for the decision are the ones who must confirm that the incident is significant, assess its severity and impact, and approve what goes to the CSIRT or competent authority.

Notify decision: Named decision makers confirm whether the incident meets the significance test and whether the update to the early warning is due.
Severity and impact assessment: Your incident responders produce the initial assessment, and an accountable owner signs it off.
Indicators of compromise: Your team decides which IOCs are shared, based on what is verified and where confidentiality limits apply.
Submission: Your staff, not an outside party, submits the notification through the channel your national authority designates.
Record of the timeline: Your team keeps timestamps showing when awareness started and when each step happened.

Check that your contact list, approval chain and submission route are tested before an incident occurs.

Questions buyers ask about the 72-hour notification

How long does it take to prepare the 72-hour incident notification?

No supplied fact gives a duration, so the honest answer depends on the incident and the state of your records. The 72-hour clock starts when the entity becomes aware of the significant incident, and the notification must be submitted without undue delay and in any event within 72 hours. Preparation time is driven by how quickly you can establish what happened, which systems and services are affected, whether indicators of compromise are available, and who must sign off. Teams that already hold a timeline and an asset inventory for the incident usually finish faster. Ask any partner to show how they would staff a 72-hour window across nights and weekends, and to state which parts of the notification they expect to draft in advance.

Can our own security team write the 72-hour notification without outside help?

Often yes, if the team already runs incident handling and has a reporting template, a named decision maker and access to the evidence. The notification is an update to the early warning with an initial assessment of severity and impact, plus indicators of compromise where available. Your team owns the content and the submission, because the reporting duty sits with the entity. Outside help is most useful for preparing the case record, consolidating logs and building the timeline quickly, or for rehearsing the process before a real event. Confirm internally whether you have a case management tool, a documented escalation path and staff who can work outside business hours.

What does the 72-hour notification need from management and security staff?

It needs a named decision maker who can judge severity and impact and approve the submission, and security staff who can produce facts quickly. Management must be reachable within the window, understand the reporting duty and accept that an initial assessment may later change. Security staff must be able to confirm affected assets, the time of awareness, the indicators observed and the immediate containment steps. Consider these parts of the work:

Decision rights for severity, impact and sign-off
Access to logs, endpoint data and the asset inventory
Legal, privacy and communications contacts for the GDPR overlap and any public statements
A record of each decision with its time, which supports the later final report

How does the 24-hour rule for trust service providers differ in practice?

For trust service providers, the notification of a significant incident affecting their trust services is due within 24 hours of becoming aware of it, instead of 72 hours. That halves the window for the notification step. In practice, the early warning and the notification may need to be prepared in the same shift, so the initial facts must be available almost immediately. Trust service providers should confirm with their competent authority how the timelines apply to their services, and test whether their monitoring, on-call rota and case records support a first submission in that window. Ask any partner whether the exercise plan includes a 24-hour scenario.

What will a supervisor check in the 72-hour notification?

A supervisor will check whether the notification was submitted within the deadline, whether it updates the early warning, and whether it contains a reasoned initial assessment of severity and impact. They may also look for indicators of compromise where available, and information that lets the CSIRT or authority judge any cross-border impact. Keep a time-stamped record of when you became aware of the incident, each submission and the evidence behind each statement. The NIS2 Directive creates no certificate, so supervision happens through inspections, information requests and audits by the national authority. Confirm the format and channel your national authority expects, because procedures are set nationally.

What should a partner deliver in a fixed-scope engagement for this step?

A fixed-scope engagement should name the deliverables, the systems in scope and the timelines in writing before work starts. For the 72-hour step, typical deliverables are a reporting procedure, a notification template mapped to the Article 23 content, a case workflow in your chosen tool, and a tested runbook that shows who acts in each hour. Ask for a clear split between what the partner prepares and what your organization owns, including submission and sign-off. DeployOpen implements, configures and documents self-hosted open-source platforms such as DFIR-IRIS and MISP inside your environment, and runs exercises, but it does not issue reports or certifications. Request a quote that states scope, assumptions, exclusions and any retainer for ongoing support.

How DeployOpen prepares the 72-hour notification process

DeployOpen works on the 72-hour notification as part of a wider incident reporting setup inside your own infrastructure. We prepare the systems, records and evidence that let your team update the early warning with an initial severity and impact assessment and indicators of compromise, while your organization keeps ownership of the decision to notify.

How we scope

Agree in writing which systems, teams and reporting channels the 72-hour notification process covers before work starts.
Confirm which entity types apply, including whether trust service provider 24-hour timing applies to any services in scope.
Define who owns the severity and impact assessment, who approves the notification, and who is the contact for the CSIRT or authority.

How we build

Configure case management so each incident holds affected assets, IOCs, tasks and an audit trail that can feed a notification.
Set up threat intelligence sharing and indicator correlation so IOCs can be recorded and exported in standard formats.
Connect logging sources such as SIEM, EDR and application audit logs so the timeline can be reconstructed from retained records.

How we hand over

Document the notification workflow, templates and decision points in a runbook your staff own and can update.
Deliver a test of the notification steps against an illustrative incident, with the results recorded for your assessors.
Provide configuration records, access settings and evidence locations so your internal team can operate the process without us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer to keep the tooling and runbook current.
Review the process after exercises or real incidents and agree written changes to scope, runbook or configuration.
Confirm with your legal and compliance advisers which regulator, CSIRT and timing rules apply in each Member State where you operate.