Splunk for NIS2 Compliance: Mapping Enterprise Security to CIR 2024/2690 Section 3.2 and Article 23

Search “NIS2 Splunk Annex 6.11” and you’ll find that exact citation repeated across vendor blog posts and consultant briefs. It doesn’t exist. Commission Implementing Regulation (EU) 2024/2690’s Annex runs to 13 numbered sections, and the logging and monitoring obligation sits at Section 3.2, under “Incident handling” — nowhere near Section 6, which covers system and network security [1]. Getting this wrong in front of an auditor is a bad first impression, and it matters here specifically because Splunk is one of the most common SIEM platforms EU organisations already run. This guide maps what Section 3.2 actually requires onto a working Splunk Enterprise Security deployment, then closes a gap the equivalent guides for other SIEM platforms on this site don’t cover: how a Splunk Notable Event connects to the Article 23 clock that starts running the moment your team becomes aware of a significant incident.

Who this is for: security engineers running or evaluating Splunk for NIS2 readiness (technical mapping in the sections below), and compliance officers who need to know what documentation a Splunk deployment does not generate on its own (skip to “What an Auditor Will Ask to See”).

Does CIR 2024/2690 Apply to Your Organisation?

In plain terms: CIR 2024/2690 is not a universal NIS2 logging law. Article 21(5) of the NIS2 Directive instructed the Commission to write binding technical requirements for one specific list of entity types — if your organisation isn’t on that list, Section 3.2 is a best-practice reference, not a citable legal obligation, and your general duty comes from Article 21(2)(b) “incident handling” directly [2].

Entity type	CIR 2024/2690 binds you directly?
DNS service providers, TLD name registries	Yes
Cloud computing, data centre, and CDN providers	Yes
Managed service and managed security service providers	Yes
Online marketplaces, search engines, social networking platforms	Yes
Trust service providers	Yes
Every other essential/important entity (manufacturing, health, energy, finance, etc.)	No — Section 3.2 is reference-quality guidance, not a binding citation

Germany’s BSI — one of the national authorities enforcing NIS2 transpositions — describes the CIR’s function as formulating and specifying the minimum requirements behind Article 21’s risk-management measures, and confirms the same eleven-entity scope [3]. If you fall outside that list, everything below still applies as a defensible logging standard; you just cite Article 21(2)(b) and your national law instead of the CIR by name.

What CIR 2024/2690 Section 3.2 Actually Requires for Logging

Section 3.2 breaks into seven numbered sub-clauses. None of them names a specific product, and none of them sets a fixed retention period — both are common misreadings worth clearing up before the Splunk-specific mapping.

Sub-clause	What it requires
3.2.1	Documented procedures and tools to monitor and log activity for incident detection
3.2.2	Monitoring automated “to the extent feasible”, continuous or at periodic intervals
3.2.3	A risk-assessment-based list of log categories, maintained, documented, and reviewed
3.2.4	Regular review of logs for unusual or unwanted trends, with alarm thresholds
3.2.5	Logs backed up “for a predefined period” and protected from unauthorised access or changes
3.2.6	Synchronised time sources across systems, so logs correlate correctly
3.2.7	Periodic review of the logging procedures and the asset list, including after significant incidents

Sub-clause 3.2.3’s log-category list is the longest single requirement: network traffic, user account changes, system/application access, authentication events, privileged administrative activity, changes to critical configuration and backup files, security-tool event logs, resource utilisation, physical facility access, network device access, log activation/deactivation, and environmental events [1]. In reviewing Splunk deployments against this list, the gap is rarely coverage — most environments with Splunk already ingesting firewall, identity, and endpoint data hit 9 or 10 of the twelve categories by default. The two that get missed are physical access logs (badge systems usually live in a separate platform nobody onboards to Splunk) and environmental events (server-room temperature/power sensors, which are almost never forwarded anywhere).

On retention: 3.2.5 requires a “predefined period”, not a specific number of months — the regulation deliberately leaves the duration to the entity’s own risk assessment [1]. As a practical baseline, a 12-month minimum (commonly split as roughly 6 months in searchable “hot” storage plus 6 months in archived “cold” storage) is a defensible starting point, with some national guidance for essential entities running longer; document whichever period you choose with a risk-based rationale, because “we picked a number” is what an auditor will actually test.

Mapping Splunk Enterprise Security to the Seven Section 3.2 Sub-Clauses

Splunk’s own documentation doesn’t reference NIS2 — there is no built-in “CIR 2024/2690 dashboard”. The mapping below is original analysis connecting Splunk’s standard configuration surface to each sub-clause.

Sub-clause	Splunk mechanism	Effort
3.2.1	Written SOP naming your data inputs, index structure, and Enterprise Security app configuration as the “tool”	Low
3.2.2	Correlation searches on a real-time or continuous (cron) schedule — continuous schedules are never skipped, which matters for an auditable “automated” claim [4]	Medium
3.2.3	Data input and index selection mapped explicitly against the twelve log categories; document any deliberate exclusion (e.g. physical access) as a risk-assessment decision, not an oversight	Medium
3.2.4	Correlation searches feeding the Risk data model, with results shown on the Incident Review dashboard’s Risk Timeline as “risk notables”	Medium
3.2.5	Index-level retention via frozenTimePeriodInSecs in indexes.conf, with coldToFrozenDir archiving data instead of deleting it once it ages out [5]	Low
3.2.6	NTP/time-sync enforced on the log sources feeding Splunk — Splunk itself doesn’t fix unsynchronised clocks upstream, so this sits outside the Splunk config entirely	Low
3.2.7	Scheduled review of correlation-search health and the index/data-input list, plus a triggered review after any Notable Event closes as a confirmed incident	Low

The pattern across most rows is the same one seen in equivalent mappings for other SIEM platforms on this site: the technical capability already exists in a default Splunk Enterprise Security deployment. What’s usually missing is the decision trail — which index settings were chosen because of Section 3.2.5, not just because someone copied a default indexes.conf from a training course.

How Splunk Notable Events Map to the Article 23 Reporting Clock

This is the connection most Splunk-and-NIS2 content skips. Article 23 sets three deadlines once your organisation becomes aware of a significant incident: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month of that notification, with an intermediate report available if a CSIRT or competent authority asks for one [6]. “Significant” itself is a legal test — severe operational disruption or financial loss, or considerable damage to others — that no tool decides for you [6].

A correlation search’s Notable Event is the closest thing Splunk has to a “becoming aware” timestamp, and that timestamp matters more than most teams realise: if a regulator later questions why notification took 30 hours instead of 24, the honest answer usually traces back to how long the event sat unassigned in the Incident Review queue, not how long the investigation took. Building the workflow correctly means treating triage as the moment the clock starts, not the moment someone finishes confirming impact.

Role	Owns
SOC analyst / Tier 1	Acknowledges the Notable Event, records the acknowledgement timestamp — this is your evidentiary “awareness” marker
Security lead / Tier 2-3	Applies the Article 23(3) significance test; escalates to compliance if it’s met
Compliance officer	Owns the 24h/72h/1-month submission itself, pulling Splunk’s timeline and indicator-of-compromise fields into the notification content
CISO	Signs off on the final report’s root-cause and remediation narrative

Two adaptive-response habits reduce the gap between detection and the 24-hour deadline: throttling correlation-search results so a single incident doesn’t flood the queue with duplicate Notable Events (each one competing for triage attention), and grouping related events by common fields so the Incident Review dashboard shows one case, not twenty alerts, the moment someone opens it [4].

What an Auditor Will Ask to See Beyond Your Splunk Dashboards

A live dashboard proves capability, not compliance history. Evidence an inspector typically wants:

• The written Section 3.2 procedure naming Splunk as the monitoring tool, with a version history
• The risk assessment behind your chosen log-category list and any documented exclusions
• indexes.conf retention settings alongside the risk-based rationale for the specific period chosen
• A sample of Notable Event timestamps compared against actual notification submission times, showing the 24h/72h clock was respected
• Records of the periodic 3.2.7 review, including any changes made after a real incident

Common Implementation Mistakes

The recurring failure isn’t a missing Splunk feature — it’s treating a working SIEM as self-documenting. Specific patterns worth checking: frozenTimePeriodInSecs set shorter than the documented retention policy (a silent contradiction an auditor will catch by comparing the two); correlation searches left in their default “disabled” state after installing Enterprise Security, so nothing actually generates Notable Events; and conflating “we have index=notable” with “we satisfy 3.2.4” — the sub-clause requires regular human review of trends, which a populated index alone doesn’t demonstrate.

Frequently Asked Questions

Does the free/core Splunk platform satisfy CIR 2024/2690, or do I need Enterprise Security?
Core Splunk can technically ingest and retain the required log categories, satisfying parts of 3.2.1-3.2.3 and 3.2.5-3.2.6. Enterprise Security’s correlation searches and Notable Events are what most efficiently satisfy 3.2.4’s “regular review for unusual trends” requirement at scale — without it, that review has to happen through manual dashboards or scheduled reports instead.

Is there a mandatory minimum log retention period under CIR 2024/2690?
No. Section 3.2.5 requires logs kept “for a predefined period” that the entity itself sets and can justify — there is no fixed number in the regulation [1].

Does CIR 2024/2690 apply to my company if we’re not a cloud, DNS, or hosting provider?
Only Article 21(5)’s eleven listed entity types are directly bound. Everyone else follows Article 21(2)(b) and their national transposition law, using Section 3.2 as reference-quality guidance rather than a citable requirement [2] [3].

What actually starts the Article 23 24-hour clock?
The moment your organisation becomes aware that an incident meets the Article 23(3) significance test — not the moment the investigation concludes [6]. A Notable Event’s acknowledgement timestamp is the practical evidence of that moment.

Can Splunk auto-classify whether an incident is “significant” under Article 23?
No. Significance is a legal/operational judgment (severe disruption, financial loss, or damage to others) that a person applies — correlation searches can surface candidate incidents, but they don’t make the Article 23(3) determination [6].

Key Takeaways

Splunk’s technical capability already covers most of CIR 2024/2690 Section 3.2 in a default Enterprise Security deployment. The compliance gap is almost always documentation and timing discipline: a written procedure naming Splunk as the tool, a risk-based retention rationale that matches your actual frozenTimePeriodInSecs setting, and a triage workflow that treats Notable Event acknowledgement as the moment the Article 23 clock starts. None of that requires new software — it requires someone to write it down and test it against a timeline.

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. Commission Implementing Regulation (EU) 2024/2690, Annex Section 3.2 — EUR-Lex
2. NIS 2 Directive (EU) 2022/2555, Article 21 — nis-2-directive.com
3. Bundesamt für Sicherheit in der Informationstechnik (BSI), NIS-2 für IT und TK: DurchführungsVO (EU) 2024/2690 — bsi.bund.de
4. Splunk documentation, Configure correlation searches in Splunk Enterprise Security — help.splunk.com
5. Splunk Lantern, Establishing data retention policies — lantern.splunk.com
6. NIS 2 Directive (EU) 2022/2555, Article 23 — nis-2-directive.com

See also: NIS2 Logging & Monitoring requirements, Microsoft Sentinel for NIS2, Microsoft Defender for NIS2, and the full Article 21 requirements mapping.