Does NIS2 Really Require a SIEM? CIR 2024/2690 Logging Rules, Log Sources, and the SIEM vs. SOAR vs. MDR Decision

Most vendor blogs answer “does NIS2 require a SIEM?” with a flat yes, then sell you one. The honest answer is narrower and more useful: a specific, named list of digital-infrastructure entities has a literal logging-and-monitoring mandate written into binding EU law, and everyone else has a broader “detect and handle incidents” duty that a SIEM is one proportionate way — not the only way — to satisfy. Knowing which category you’re in changes what an auditor can actually demand from you.

This article works from the primary legal text — the NIS2 Directive and its Commission Implementing Regulation (CIR) 2024/2690 — to establish exactly what’s mandated, then goes further than either the regulation or most compliance content by mapping practical log sources, the real technical difference between SIEM, SOAR, and MDR, and the correlation logic a detection system needs to actually catch something.

Does NIS2 Actually Require a SIEM?

In plain terms: only 10 specific types of digital-infrastructure entity have a literal, named logging-and-monitoring checklist in binding EU law. If you’re not one of them, NIS2 still requires you to detect and handle incidents under Article 21(2)(b) — but the law leaves the “how” to your own risk-based judgment, not a mandated tool list.

The NIS2 Directive itself — Regulation (EU) 2022/2555 — sets ten categories of cybersecurity risk-management measure at Article 21(2)[1]. Point (b) is “incident handling.” Nowhere in that list does the Directive name a technology. It requires the outcome (the capability to detect and respond to incidents), not the implementation.

The Commission Implementing Regulation 2024/2690 fills in the “how” — but its Annex applies, by its own scope provisions, only to DNS service providers, TLD name registries, cloud computing providers, data centre service providers, content delivery network (CDN) providers, managed service providers (MSP), managed security service providers (MSSP), online marketplaces, online search engines, social networking platforms, and trust service providers. If your organisation sits in one of those categories, Section 3.2 of the CIR Annex is a binding checklist, not a suggestion. If you’re a manufacturer, hospital, energy operator, or almost any other essential or important entity, the CIR applies at most “by analogy” — as a well-reasoned interpretive reference for what “appropriate” incident-handling capability looks like, not as a directly enforceable requirement.

Your entity type	What actually binds you	Is a SIEM literally mandated?
DNS/TLD, cloud, data centre, CDN, MSP/MSSP, marketplace, search engine, social platform, trust service	CIR 2024/2690 Annex Section 3.2 (monitoring & logging), directly	Not by name, but the described capability (automated, continuous, correlated log monitoring) is hard to deliver at scale without one
All other essential/important entities (manufacturing, health, energy generation, transport, public admin, etc.)	Article 21(2)(b) “incident handling,” risk-based and proportionate	No — a smaller organisation can satisfy the duty with disciplined manual log review; scale is what usually forces the tooling question

This distinction matters because overclaiming it either way creates a real compliance risk: a CIR-bound entity that treats Section 3.2 as optional guidance will fail an audit against a binding provision, while a manufacturer who’s told “NIS2 requires a SIEM” may over-spend on tooling a smaller, well-documented manual process would satisfy just as well under Article 21(2)(f)’s effectiveness-assessment duty. For a full walk-through of how all ten Article 21(2) measures apply across entity types, see our Article 21 breakdown.

What CIR 2024/2690 Section 3.2 Actually Mandates

In plain terms: for CIR-bound entities, Section 3.2 requires seven things — monitoring tools and procedures, automation, a defined log scope, regular review with alert thresholds, protected retention, time synchronisation, and periodic re-review. None of it names a product; all of it is auditable against your own written procedure.

The CIR Annex’s Section 3, “Incident handling,”[2] devotes its second subsection specifically to monitoring and logging. Read verbatim, the seven provisions are:

• 3.2.1 — lay down procedures and use tools to monitor and log activity to detect events that could be incidents, and respond to mitigate impact.
• 3.2.2 — monitoring should be automated and continuous (or periodic where business capability requires), tuned to minimise both false positives and false negatives.
• 3.2.3 — maintain, document, and review logs against a risk-based asset list, covering twelve defined categories of content (the next section breaks these down by practical source).
• 3.2.4 — review logs regularly for unusual or unwanted trends, and set alarm thresholds where appropriate.
• 3.2.5 — retain and back up logs for a predefined period, protected from unauthorised access or change.
• 3.2.6 — synchronise system clocks and make monitoring/logging infrastructure redundant, with its own availability monitored independently of the systems it watches.
• 3.2.7 — review the logging procedures and asset list at regular intervals and after significant incidents.

The phrase that does the most work here is 3.2.2’s “minimises false positives and false negatives.” An auditor can’t inspect a mental commitment to accuracy — they inspect evidence that you measured your detection rate and tuned against it. That’s the gap between owning log-collection software and running an actual monitoring programme, and it’s the gap most SIEM deployments fail to close in year one. For the exact retention windows regulators expect in practice and a full SIEM-vs-MSSP cost comparison, we cover that ground in depth in our CIR logging and retention guide — this article focuses on what to log, what tooling category does which job, and how to build detection logic that actually fires.

Log Source Requirements: OS, Network, Application, Cloud, and OT

In plain terms: Section 3.2.3 lists twelve legal categories of loggable content, written in regulatory language. In practice, a security team needs to translate that list into “which systems actually produce these logs” — which splits cleanly into five practical source types.

The CIR’s twelve categories[2] are: inbound/outbound network traffic; user creation, modification, deletion and permission changes; access to systems and applications; authentication events; privileged access and administrative activity; access or changes to critical configuration and backup files; event logs from security tools (antivirus, IDS, firewalls); system resource use and performance; physical facility access; network equipment access and use; log activation/stopping/pausing; and environmental events. No competing guide we found organises this list by where the logs actually originate — most repeat it verbatim and stop. Mapped to practical source infrastructure, it looks like this:

Source category	What it captures	Maps to CIR 3.2.3 category
Operating system / endpoint	Login/logoff, user and permission changes, process execution, local admin activity	User account changes, authentication, privileged access
Network	Firewall allow/deny, router/switch flow data, VPN sessions, DNS queries	Inbound/outbound traffic, network equipment access
Application	App-level auth, API calls, database access, config file changes	Access to systems/applications, config/backup file changes
Cloud / SaaS	IAM role changes, storage bucket access, control-plane audit trails (e.g. CloudTrail-equivalent)	User changes, privileged access, resource utilisation
OT / ICS	Engineering-station logins, PLC configuration pushes, HMI access, network flow at IT/OT boundary	Privileged access, config changes, network equipment — collected differently (see below)

Security tool output — antivirus, IDS/IPS, EDR alerts — is its own explicit category under 3.2.3 and typically becomes the highest-value feed into a correlation engine, because it’s already pre-filtered for suspicious activity rather than raw activity.

SIEM vs. SOAR vs. MDR: Which One Satisfies Which Obligation

In plain terms: these three tool categories do different jobs, and treating “we bought a SIEM” as a complete answer to Article 21(2)(b) is the single most common gap we see in NIS2 readiness reviews. A SIEM collects and correlates; SOAR automates the response once something’s flagged; MDR outsources the human analysis in between. Most CIR-bound entities need at least two of the three working together — see our Article 21 IT workstream guide for how detection tooling fits alongside the rest of an Article 21 security programme (identity, backup, segmentation, patching).

Based on the mechanism-level breakdown from security vendor Blumira[4], the practical distinction is:

Tool	Primary job	Input	Output	Which CIR 3.2 provision it addresses
SIEM	Centralised log aggregation, correlation, retention	Logs from every source category above	Alerts, historical audit trail	3.2.1, 3.2.3, 3.2.5 (collection, scope, retention)
SOAR	Workflow automation across security tools	Alert output from SIEM/XDR	Automated remediation actions (isolate host, disable account)	3.2.4 (turning alerts into action faster than manual response)
MDR	Outsourced 24/7 human analysis and response	Environment access — logs, endpoint telemetry, network data	Investigated incidents, response recommendations	3.2.2, 3.2.4 (continuous review, minimising false positives — with human judgement most in-house teams can’t staff around the clock)

None of these tools is a substitute for 3.2.6’s requirement that the monitoring system’s own availability be watched independently — a SIEM that silently stops ingesting logs from one source for three weeks is, on paper, worse than having no SIEM at all, because it creates a false sense of coverage. That single failure mode is worth a recurring line item in whatever internal audit procedure covers your monitoring programme.

The honest trade-off: a SIEM alone gives you 3.2.1’s collection duty and half of 3.2.4’s review duty, but without SOAR or MDR, “regularly reviewed” logs are only as good as the analyst hours available to look at them — which is exactly the gap a smaller CIR-bound entity (say, a regional MSSP or a single-country CDN operator) is most likely to have.

Correlation Use Cases: From Raw Logs to Actionable Alerts

In plain terms: a single failed login is noise; ten failed logins from one IP address in five minutes followed by a success is a signal. Correlation rules are what turn 3.2.3’s raw log categories into 3.2.4’s “unusual or unwanted trends” — and most SIEM deployments underperform not because the tool is wrong, but because nobody wrote rules specific enough to fire on the right thing without drowning the team in false positives.

Four correlation patterns cover most of what a CIR-bound entity’s monitoring programme needs to demonstrate, drawing on standard SIEM detection logic[6]:

• Brute force: more than 10 failed login attempts from a single IP within a 5-minute window generates an alert; a subsequent success from that same source within the window escalates it from noise to incident.
• Lateral movement: successful logins to multiple distinct hosts, originating from one machine, within a 15-minute window — the pattern a compromised workstation shows when an attacker is pivoting toward higher-value targets.
• Data exfiltration: outbound data volume exceeding roughly 1 GB from a single host within an hour, particularly to a destination the host has no established communication history with.
• Command-and-control beaconing: a host making small, regular, periodic outbound connections to the same external address — a pattern that’s invisible in any single log line and only becomes visible once you correlate timing across a window.

Every one of these rules needs a documented threshold and time window to satisfy 3.2.4 in an audit — “we monitor for lateral movement” is not evidence; a written rule definition with the values above, plus a log of tuning changes and false-positive rate over time, is.

OT and ICS Logging: Why Standard SIEM Agents Don’t Work

In plain terms: the endpoint agent that feeds your SIEM from a laptop or a cloud VM cannot run on a programmable logic controller (PLC), and trying to actively scan one can knock it offline. OT log collection has to work around the device, not on it.

Industrial control devices run proprietary firmware on fixed maintenance cycles; they generally can’t be patched, rebooted, or have new software installed without taking a production process offline[5]. Active network scanning — sending probe packets to see what responds — carries a real risk of triggering unexpected behaviour in equipment that was never designed to receive unsolicited traffic. That rules out the two most common IT monitoring techniques (agent installation and active discovery) for a meaningful slice of an OT environment.

The practical workaround most OT security programmes use is passive: pulling NetFlow or IPFIX telemetry from the routers, switches, and firewalls that sit at IT/OT zone boundaries, rather than from the PLCs and engineering workstations themselves[5]. That gives visibility into which devices are talking to which, over what protocol, at what volume and for how long — enough to flag an engineering workstation suddenly reaching out to a segment it’s never touched, or a spike in traffic crossing the IT/OT boundary at 3 a.m. What it doesn’t give you is the content of the industrial protocol conversation itself (a Modbus or DNP3 command payload) — that requires protocol-aware deep packet inspection tooling as a separate layer, not a SIEM configuration change. For manufacturers building this into a broader NIS2 network security programme, IEC 62443’s zone-and-conduit model is the standard reference architecture underpinning where that boundary telemetry should be collected.

Audit Documentation Checklist for NIS2 SIEM Compliance

In plain terms: auditors under Article 32 (essential entities) or Article 33 (important entities) aren’t evaluating whether your SIEM dashboard looks impressive — they’re checking for a specific paper trail against each of the seven Section 3.2 sub-provisions.

• Written monitoring and logging procedure, naming the tools in use (3.2.1)
• Evidence of automation configuration and a stated review cadence (3.2.2)
• Current asset list showing what’s logged, tied to a documented risk assessment (3.2.3)
• Alert threshold definitions for each correlation rule, with a change log (3.2.4)
• Retention policy stating the period and the access-control measures protecting stored logs (3.2.5)
• Confirmation of time synchronisation (e.g. NTP configuration) and monitoring-system redundancy (3.2.6)
• Dated record of the last periodic procedure review, and any post-incident revision (3.2.7)
• False-positive/false-negative rate tracked over time, showing tuning effort (evidence for 3.2.2’s “minimises” requirement)

Every item on that list maps directly to a sub-provision above — which is deliberate. An auditor working through Section 3.2 sub-point by sub-point should be able to ask for each item and receive it without your team needing to reconstruct evidence on the spot.

Frequently Asked Questions

Does NIS2 name a specific SIEM product or vendor requirement?
No. Neither the Directive nor the CIR names a product category by brand or even by acronym. The CIR describes required capabilities (automated, continuous, correlated monitoring with defined retention) that a SIEM is the most common way to deliver at scale, but a smaller organisation could in principle satisfy the same provisions with rigorous manual log review, provided it can evidence the same outcomes.

What’s the minimum log retention period under NIS2?
CIR 2024/2690 Section 3.2.5 requires retention “for a predefined period” without specifying a number of months — the specific duration is a risk-based decision your organisation documents and defends, not a fixed EU-wide figure. We cover practical retention benchmarks and the reasoning behind common 6/12/18-month splits in our dedicated logging and retention article. For a section-by-section walk-through of ENISA’s practical guidance across all 13 CIR areas, see our ENISA implementation guidance summary.

Do we need a SIEM if we already use MDR?
Usually yes, in some form — MDR providers typically monitor and correlate through their own SIEM-class platform or yours; “MDR” describes the service model (outsourced human analysis), not a replacement for the underlying log-correlation layer. Confirm during vendor selection whether the MDR provider ingests your logs into their platform or requires you to run the correlation layer yourself.

Does this apply to a company that just uses cloud services, rather than providing them?
No — the CIR Annex’s Section 3.2 binds cloud computing service providers, not their customers. A manufacturer running workloads on a public cloud provider is bound by Article 21(2)(b)’s general incident-handling duty, not by the CIR’s specific tooling checklist; the cloud provider itself carries the CIR-bound obligation for its own infrastructure.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. NIS2 Directive (EU) 2022/2555, Article 21 — nis-2-directive.com
2. Commission Implementing Regulation (EU) 2024/2690, Annex Section 3.2 — Advisera full-text mirror
3. ENISA, “NIS2 Technical Implementation Guidance” (26 June 2025) — enisa.europa.eu
4. “SIEM, SOC, SOAR, XDR Defined” — Blumira
5. “Agentless Security for OT/ICS Networks” — NetFlow Logic
6. “SIEM Correlation Rules: Building Detection Logic” — NetworkersHome