Mapping NIS2 to Microsoft Sentinel Detections

NIS2 is often read as a governance and paperwork exercise. It is not. Buried in the German NIS2UmsG, which has applied since 6 December 2025 with no transition period, is a hard operational demand: you must be able to detect a significant incident, decide it is significant, and report it to the BSI within 24 hours of awareness. That is a detection-engineering problem before it is a compliance problem. This post is the mapping we use with clients to turn NIS2's prose into concrete Microsoft Sentinel detections, with an audit trail that survives scrutiny.

TL;DR / Key takeaways

• NIS2 names no product, but the 24-hour early warning and 72-hour report deadlines are practically unmeetable at enterprise scale without a central SIEM such as Microsoft Sentinel.
• The strongest NIS2 Microsoft Sentinel mappings are incident handling, detection and reporting of significant incidents, logging and monitoring, supply-chain anomaly detection, and effectiveness review.
• Build a living NIS2 SIEM mapping matrix: each measure to its analytics rules to its data sources, aligned to MITRE ATT&CK — this is your audit evidence.
• Sentinel's automatic timestamps make awareness defensible and let you start the legal clock the moment a significant-incident rule fires.
• Sentinel is not the whole programme. It is the control that proves your other NIS2 measures actually work.

Why NIS2 turns into a detection problem

Most of NIS2's risk-management catalogue describes states you must achieve: access control, cryptography, business continuity, supplier security. The directive's reporting regime, however, describes an event you must catch in motion. Article-level obligations require an early warning within 24 hours of becoming aware of a significant incident, a fuller report within 72 hours, and a final report within one month. Awareness is the trigger, and awareness is a function of detection.

This is where many organisations quietly fail their own controls. They have a SIEM, but its rules were tuned for generic threat hunting, not for the specific question NIS2 asks: has a significant incident occurred to an essential or important service? The gap between "we have alerts" and "we can defend our 24-hour timeline to the BSI" is exactly the gap this mapping closes. (If you are still unsure whether you are in scope at all, start with our NIS2 Germany scope test under the NIS2UmsG.)

Mapping NIS2 measures to Sentinel capabilities

NIS2's risk-management measures are deliberately technology-neutral. The practitioner's job is to bind each one to something concrete and observable. The table below is the core of our NIS2 SIEM mapping approach. It is not exhaustive, but it covers the measures where a SIEM does the heavy lifting.

The point of the table is not that Sentinel "does NIS2". It is that for each obligation you can point to a specific, queryable artefact. When the BSI or an ISO 27001 auditor asks how you would have known, you answer with a rule name and a data source, not a slide.

The detection layer that actually triggers the clock

The single most important detections are those that answer the significance question. We typically implement a small set of high-confidence "significant incident candidate" analytics rules — for example, confirmed data exfiltration above a threshold, ransomware behaviour on a production service, or compromise of a privileged identity governing an essential service. These rules are deliberately conservative and high-fidelity, because they are wired directly to the reporting workflow described in our NIS2 24/72-hour incident reporting runbook.

In one engagement for a mid-market logistics operator newly in scope, we found their existing SOC had over 200 enabled rules but none that mapped cleanly to "an incident a board would have to report." We delivered eight tightly scoped significant-incident rules, each tagged with the NIS2 measure it served and a MITRE ATT&CK technique. The reduction in ambiguity, not the increase in rules, was what made their 24-hour timeline defensible.

A worked KQL example: privileged identity compromise

NIS2 cares disproportionately about identity, because identity compromise is the fastest route to a significant incident across an essential service. A simplified but representative detection for anomalous privileged role activation in Microsoft Entra ID:

AuditLogs
| where OperationName == "Add member to role"
| where TargetResources has_any ("Global Administrator", "Privileged Role Administrator", "Security Administrator")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| join kind=leftouter (
    SigninLogs
    | summarize KnownCountries = make_set(LocationDetails.countryOrRegion) by UserPrincipalName
  ) on $left.Actor == $right.UserPrincipalName
| extend ActivationCountry = tostring(parse_json(AdditionalDetails)[0].value)
| where ActivationCountry !in (KnownCountries)
| project TimeGenerated, Actor, OperationName, ActivationCountry, KnownCountries

This is illustrative, not production-ready — real rules need tuning against your baseline and your privileged-access model (see Zero Trust services for how we approach the underlying identity controls). But it demonstrates the principle: the rule is named, tagged to a NIS2 measure, and produces a timestamped artefact you can present as evidence.

Don't ingest everything: the cost-versus-coverage decision

A recurring mistake is treating NIS2 as a mandate to log everything. It is not. The obligation is appropriate and proportionate measures. Ingesting telemetry you never detect on is pure cost. We use a simple tiering decision when scoping a NIS2-aligned Sentinel deployment:

The governing rule: if a data source has no analytics rule or hunting query referencing it, and it carries no audit obligation, you are paying for storage, not security.

Closing the loop: registration, evidence, and review

Detection coverage is only credible if it is documented and reviewed. Three habits make the difference:

1. Keep the mapping matrix live. Every new analytics rule records the NIS2 measure it serves and the MITRE technique it covers. Every retired rule is reviewed for the gap it leaves.
2. Make coverage visible. A Sentinel workbook showing enabled rules, data-source health, and detection-coverage gaps is the artefact you hand an auditor — and the one that makes management oversight real rather than nominal.
3. Review effectiveness on a cadence. NIS2 expects you to assess whether measures work. Time-to-detect, false-positive rate, and coverage trend are the metrics that demonstrate continuous improvement.

If you have not yet registered with the BSI, the monitoring story should be built in parallel — our BSI registration walkthrough covers the portal process, and registration remains required even after the 6 March 2026 deadline has passed.

A final framing for the board: NIS2 makes management personally liable for the oversight and approval of risk-management measures, with fines reaching EUR 10 million or 2% of global turnover for particularly important entities. A well-mapped Sentinel deployment is one of the few artefacts that lets a CISO show, with evidence, that those measures exist and are working. That is its real value under NIS2 — not detection for its own sake, but defensible accountability.

FAQ

Does NIS2 require a SIEM like Microsoft Sentinel? NIS2 does not name any product. It requires appropriate and proportionate risk-management measures, including incident handling, logging, monitoring, and the ability to detect and report significant incidents within strict deadlines. In practice, meeting the 24-hour early warning and 72-hour reporting obligations for a mid-sized or larger enterprise is very hard without a central SIEM. Microsoft Sentinel is one defensible way to satisfy the detection, correlation, and evidence requirements, especially in Microsoft-centric estates.

Which NIS2 risk-management measures map to Sentinel? The clearest mappings are incident handling, the detection and reporting of significant incidents, logging and monitoring, supply-chain anomaly detection, and effectiveness review of security measures. Sentinel covers these through data connectors, analytics rules, automation playbooks, and workbooks. Access control and cryptography are largely enforced elsewhere, but Sentinel still provides the monitoring evidence that those controls are working.

How does Sentinel help meet the NIS2 24-hour and 72-hour deadlines? Sentinel timestamps detection, incident creation, and analyst actions automatically, which gives you a defensible record of when awareness occurred. Automation rules can open a tracked case, notify the on-call commander, and start the reporting clock the moment a significant-incident rule fires. That turns a legal deadline into an operational workflow rather than an after-the-fact reconstruction.

Is Microsoft Sentinel enough on its own for NIS2 compliance? No. NIS2 spans governance, risk management, supply-chain security, business continuity, and management accountability. Sentinel addresses the detection, monitoring, and incident-evidence layer. You still need policies, a risk register, supplier assessments, tested recovery, and documented management oversight. Treat Sentinel as the control that proves your other measures are working, not as the whole programme.

What logs should we ingest into Sentinel for NIS2 monitoring? Prioritise identity (Entra ID sign-in and audit logs), Microsoft Defender XDR incidents, Azure Activity, Microsoft 365 audit logs, and network telemetry such as firewall, DNS, and flow logs. Add on-premises and OT or sector systems via Syslog or CEF where they are in scope. The principle is to ingest what you will actually detect or investigate on, because unused data is cost, not security.

How do we prove NIS2 detection coverage to the BSI or an auditor? Maintain a living mapping between each NIS2 measure, the corresponding Sentinel analytics rules, and the data sources that feed them, ideally aligned to MITRE ATT&CK. Use Sentinel workbooks and the content hub to show enabled rules, coverage gaps, and rule effectiveness over time. Combined with incident timelines, this gives the BSI a clear, evidence-based picture rather than assertions.

NIS2 monitoring is a detection-engineering discipline, and the difference between a noisy SOC and a defensible one is the mapping. If you want a second pair of senior eyes on how your Sentinel deployment maps to NIS2 — and where the gaps are — talk to our Zero Trust and security operations team. We have delivered this for entities newly in scope of the NIS2UmsG, and we are happy to start with a focused coverage review.