NIS2 Incident Reporting on Azure: Meeting the 24-Hour and 72-Hour Obligations

NIS2 incident reporting on Azure is a stopwatch problem before it is a technology problem. Article 23 of the directive gives you 24 hours to file an early warning, 72 hours to submit a full incident notification, and one month to deliver a final report — and the clock starts when you become aware of a significant incident, not when you finish investigating it. The capability that meets those deadlines is built in Microsoft Sentinel and Microsoft Defender XDR, and most teams discover the gaps the first time the clock is actually running.

Someone forwards you a Sentinel incident at 02:14. By the rules you now have until roughly 02:14 the next day to tell the authority something. The question is whether your environment can produce a defensible timeline by then, or whether you spend those hours reconstructing what happened instead of reporting it.

Key takeaways

• NIS2 Article 23 sets three deadlines: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month of the initial notification.
• The 24-hour clock starts at awareness of a significant incident — the moment a Microsoft Sentinel analytic rule or Microsoft Defender XDR alert reaches a human with the authority to judge it.
• In the Netherlands you report to the CSIRT and the relevant sector supervisor under the Cyberbeveiligingswet, the Dutch transposition of NIS2; the national CSIRT function sits with the NCSC.
• A “significant incident” is defined by severe operational disruption, financial loss, or material harm to others — not by whether an attacker technically succeeded.
• The retained evidence — a Microsoft Sentinel incident export, the analytic-rule logic, and an immutable activity timeline — is the artifact an auditor and a supervisor will ask for.

What exactly does NIS2 Article 23 require, and when does the clock start?

NIS2 Article 23 requires a three-stage notification, and the first stage is due within 24 hours of becoming aware of a significant incident. The early warning is deliberately thin: it states that an incident has occurred, whether you suspect it was unlawful or malicious, and whether it could have cross-border impact. You are not expected to know root cause yet. You are expected to have noticed.

The 72-hour notification is the substantive one. It updates the early warning with an initial assessment of the incident, including severity, impact, and — where available — indicators of compromise. The final report, due within one month of that notification, carries a detailed description, the threat type or root cause, the mitigations applied, and any cross-border effect.

The phrase that does the work is “becoming aware.” For a SecOps team running Microsoft Sentinel, awareness is the timestamp at which an incident moves from machine-generated to human-acknowledged — when an analyst opens the incident, or when an automation rule escalates it to someone who can decide it is significant. That timestamp is the single most important field in your entire reporting record, because every deadline counts from it. If your tooling cannot tell you precisely when awareness occurred, you cannot prove you met the 24-hour rule. The NIS2 Article 21 Azure control set covers the governance side; this piece covers what fires when an incident actually lands.

What counts as a “significant incident” under NIS2?

A significant incident under NIS2 is one that causes, or is capable of causing, severe operational disruption or financial loss to your entity, or considerable material or non-material harm to other people. The directive’s implementing regulation for certain sectors adds concrete thresholds — for example, an incident is significant if it causes downtime above a defined duration, affects a defined number of users, or triggers a recurring pattern of lower-severity events.

The trap is treating “significant” as a synonym for “breach.” It is broader. A ransomware detonation that you contained is significant if it disrupted service. A misconfiguration that took a customer-facing workload offline for hours is significant even with no adversary involved. A repeated, automatically-mitigated event can become significant through accumulation.

For an Azure environment, the practical move is to encode these thresholds into Microsoft Sentinel rather than leaving them to interpretation at 02:14. You define what “severe operational disruption” means for your services — a SLA breach window, a count of affected Microsoft Entra ID accounts, a Microsoft Azure resource group going dark — and let the rule logic flag candidates. A human still makes the significance call.

How do you build the 24/72-hour capability in Microsoft Sentinel and Defender XDR?

You build the NIS2 incident reporting capability in Microsoft Sentinel by combining analytic rules that detect, automation rules that orchestrate, and Logic App playbooks that act — with Microsoft Defender XDR feeding correlated alerts in. The goal is to compress the distance between an event happening and a human with reporting authority knowing about it. The components, in the order they fire:

• Microsoft Defender XDR correlates signals across endpoint (Microsoft Defender for Endpoint), identity (Microsoft Defender for Identity), email (Microsoft Defender for Office 365), and cloud apps into a single incident, then streams it to Microsoft Sentinel through the Microsoft Defender XDR data connector.
• Microsoft Sentinel analytic rules — scheduled or near-real-time (NRT) — detect the conditions you defined as significant. An NRT rule runs roughly every minute, which matters when your budget is 24 hours.
• Microsoft Sentinel automation rules trigger on incident creation: they set severity, assign an owner, tag the incident with a NIS2-candidate label, and start the clock by stamping the awareness time.
• Logic App playbooks carry out the notification mechanics — post to the SecOps channel, open a ticket, and draft the early-warning content from the incident’s entities, pre-populating the fields the authority’s portal expects so the human is editing, not authoring, against the deadline.

The single most useful artifact this pipeline produces is a defensible timeline. Microsoft Sentinel records incident activity — when it was created, acknowledged, escalated, and closed — and you can export that record. That export turns “we think we noticed around 2am” into “awareness was logged at 02:14:07; early warning filed at 09:30; within the 24-hour window.” Pair this with the drift detection in Azure configuration drift so a misconfiguration that becomes an incident is caught before it escalates.

A note on honesty: tooling detects and times. It does not decide significance or write the regulatory narrative — a human owns both. What the pipeline guarantees is that the human has the time and the evidence to do the job well.

Where do you report in the Netherlands, and under which law?

In the Netherlands you report a significant incident to the CSIRT designated for your sector and to your sector supervisor, under the Cyberbeveiligingswet — the Dutch law transposing NIS2. The national CSIRT function and much of the operational coordination sits with the Nationaal Cyber Security Centrum (NCSC). Which supervisor receives the notification depends on your sector; essential and important entities are mapped to their competent authority in the law.

The mechanics matter because the 24-hour clock does not pause while you work out who to email. Establish the reporting destination, the portal or contact channel, and the responsible internal owner before an incident — not during one. Put the destination in the playbook. Put the owner in the on-call rotation.

Reporting is also an ongoing obligation, not a single filing. The early warning, the 72-hour notification, and the one-month final report are updates to the same incident, so your evidence record has to support all three from one continuous source — which is exactly why an exportable Microsoft Sentinel incident, rather than three separately-assembled documents, is the right backbone.

What evidence do you retain, and in what form?

You retain a continuous, tamper-evident record of the incident: the detection logic that fired, the awareness timestamp, the full activity timeline, the entities involved, and the actions taken. In Microsoft Sentinel terms, that is the analytic-rule definition, the incident’s audit and activity log, and an incident export. The form matters as much as the content — a supervisor and an auditor both want to see that the record was not assembled after the fact.

Concrete retention choices for an Azure environment:

Evidence item	Source	Why it matters
Awareness timestamp	Microsoft Sentinel incident activity log	Proves the 24-hour clock was met
Detection logic	Microsoft Sentinel analytic rule (KQL)	Shows the incident was caught by design, not luck
Incident timeline	Microsoft Sentinel incident export / audit log	Reconstructs the sequence for the final report
Affected entities	Microsoft Defender XDR incident graph	Scopes impact for the significance judgment
Notification record	Logic App playbook run history	Proves what was filed and when

Send the relevant logs to a Log Analytics workspace with retention configured to meet your sector’s requirement, and consider immutable storage for the incident export so the record cannot be altered after filing. The Azure architecture governance checklist covers the broader logging posture this depends on.

This is where producing the evidence cleanly stops being a tooling exercise and becomes an assessment one. Platform Architecture Authority (PAA) reads your Microsoft Azure and Microsoft 365 configuration and maps the gaps against NIS2 obligations — including whether your detection coverage, log retention, and incident-export path can actually produce a 24-hour-defensible record — then generates the remediation code you apply. It does not replace the analyst who judges significance or writes the narrative; it makes sure the evidence those people need exists before the clock starts. PAA is read-only.

FAQ

Does the 24-hour clock start when the attack happened or when we noticed? The clock starts when you become aware of a significant incident — not when the incident technically began. For a Microsoft Sentinel pipeline, awareness is the timestamp at which a human with reporting authority acknowledges the incident. Capturing that timestamp precisely is what lets you prove the 24-hour early warning was filed on time.

Is an early warning the same as the full report? No. The 24-hour early warning is a short notification that a significant incident occurred and whether it appears malicious or cross-border. The 72-hour notification adds an initial severity and impact assessment. The one-month final report carries root cause, mitigations, and full impact. They are three stages of one obligation, not three separate reports.

Do we report every Microsoft Defender XDR alert to the authority? No. You report significant incidents, judged against operational disruption, financial loss, or harm to others. Most Microsoft Defender XDR alerts never reach that bar. The reporting pipeline exists to surface candidates to a human quickly; the human decides significance. Over-reporting and under-reporting are both failures of that judgment, not of the tooling.

Who is the competent authority in the Netherlands? You report to the CSIRT for your sector and to your sector’s supervisor under the Cyberbeveiligingswet. The Nationaal Cyber Security Centrum holds the national CSIRT function. The specific supervisor depends on whether you are classified as an essential or important entity and in which sector, so confirm your mapping before an incident occurs.

How long do we keep the incident evidence? Keep it at least as long as your sector’s supervisory and audit requirements demand, and treat the incident export as a record that may be requested well after closure. Configure Log Analytics retention deliberately, and store the final incident export in immutable form so its integrity is not in question if a supervisor asks for it months later.

The deadlines in Article 23 are not negotiable, and they do not wait for your tooling to catch up. Build the detection, the timestamp, and the export before the clock is running, because the night it starts is the wrong night to find out what is missing.