What NIS2 CIR 2024/2690 Actually Requires for Logging: Retention Windows, SIEM Specs, and Anomaly Detection Rules

Who the CIR Binds — and Why It Matters More Than Article 21

Your organisation’s management team can be held personally liable for failing to implement adequate network monitoring under NIS2 — not as an executive policy failure, but as a technical compliance shortcoming. NIS2 Directive Article 21(2)(b) requires incident handling capabilities for all essential and important entities. Commission Implementing Regulation (EU) 2024/2690, published October 17, 2024, converts those broad obligations into more than 150 binding technical controls — and Section 3.2 of its Annex governs exactly what your logging and monitoring infrastructure must do.

The CIR applies directly to the following entity types:

Entity Type	CIR Scope
DNS service providers	Yes
TLD name registries	Yes
Cloud computing service providers	Yes
Data centre service providers	Yes
Content delivery network (CDN) providers	Yes
Managed service providers (MSPs)	Yes
Managed security service providers (MSSPs)	Yes
Online marketplace providers	Yes
Online search engine providers	Yes
Social networking service platforms	Yes
Trust service providers	Yes
All other essential/important entities	NIS2 Article 21 applies; CIR Section 3.2 is the authoritative technical benchmark regulators reference when assessing compliance

If your organisation falls outside the directly bound categories, CIR Section 3.2 still represents the clearest available technical standard. National regulators across multiple member states use it as a reference point when assessing whether Article 21(2)(b) incident handling obligations have been met. Understanding these requirements places your NIS2 compliance programme on solid ground regardless of which category applies to you. For a broader overview of NIS2 obligations, see our NIS2 requirements guide.

The CIR Annex Structure — Where Logging and Monitoring Actually Lives

Many vendor articles reference “CIR Annex 8” when discussing NIS2 monitoring requirements. This is a factual error worth correcting before going further, because acting on incorrect section references can create gaps in your compliance programme.

The CIR Annex contains 13 titled sections. Monitoring and logging does not appear in Section 8:

CIR Annex Section	Title
1	Policy on the security of network and information systems
2	Risk management policy
3	Incident management — contains Section 3.2: Monitoring and Logging
4	Business continuity and crisis management
5	Supply chain security
6	Security in network and information systems acquisition, development and maintenance
7	Policies and procedures to assess the effectiveness of cybersecurity risk-management measures
8	Cyber hygiene and cybersecurity training (NOT monitoring)
9	Cryptography and encryption
10	Human resources security
11	Access control and asset management
12	Physical and environmental security
13	Multi-factor authentication

Section 8 mandates awareness programmes and security training — not SIEM infrastructure or log retention. The confusion likely originates from ISO 27001:2022, which places logging controls in Annex A 8.15 (Logging) and 8.16 (Monitoring activities). ISO 27001 and CIR 2024/2690 use entirely different numbering schemes. NIS2 monitoring and logging requirements live in CIR Section 3.2, under Incident Management.

CIR Section 3.2 — The Seven Monitoring and Logging Controls

Section 3.2 contains seven binding sub-requirements. Each has specific audit evidence implications and a different implementation effort profile.

3.2.1 — Procedures and Tools for Monitoring

What it requires: Establish documented procedures and deploy tools to monitor activity across network and information systems to detect events that could constitute incidents.

Audit evidence: A written monitoring policy referencing the specific systems in scope, plus evidence that monitoring tools (SIEM, IDS/IPS, EDR) are actively deployed and generating data. The policy must name who is responsible for monitoring and how they are alerted.

Effort: Medium. Tooling selection and deployment takes time, but the process documentation is straightforward once you know what you are monitoring.

3.2.2 — Automation and Continuity of Monitoring

What it requires: To the extent feasible, monitoring shall be automated and carried out either continuously or at periodic intervals. Automated processes must minimise both false positives and false negatives.

Audit evidence: Evidence that monitoring does not rely solely on manual log review; alert generation logs; documented thresholds used to suppress noise. The phrase “subject to business capabilities” gives smaller organisations some flexibility, but the expectation is continuous monitoring for critical assets.

Effort: High for initial setup — threshold calibration and alert tuning require specialised expertise. Low ongoing once well-tuned.

3.2.3 — Log Scope: What Must Be Logged

This is the most operationally specific sub-requirement. Organisations must maintain a risk-assessment-based list of assets subject to logging. That list must cover, at minimum:

Log Category	Examples
Network traffic (inbound and outbound)	Firewall logs, NetFlow data, DNS query logs
User account changes	Account creation, deletion, role and permission modifications
System and application access	Login events, session initiation, service access records
Authentication events	Successful and failed logins, MFA events, SSO federation
Privileged administrative activities	Sudo/root commands, admin console access, service account use
Critical configuration and backup file access	Access to backup files, configuration repositories, secrets stores
Security tool event logs	Antivirus detections, IDS/IPS alerts, firewall rule changes
System resource utilisation and performance	CPU/memory spikes potentially indicating cryptomining or data exfiltration
Physical facility access	Badge access logs, server room entry records
Network equipment and device usage	Switch and router configuration changes, VLAN modifications
Log activation and deactivation events	Proof that no one can silently disable logging
Environmental events	Temperature alerts, power anomalies in data facilities

Audit evidence: A logged asset register tied to your risk assessment, showing why each category is included or excluded. Justified exclusions are permissible — the audit looks for the documented decision, not just the coverage.

Effort: Medium. Most organisations already collect some of these categories. The gap is usually centralised correlation and a documented coverage decision.

3.2.4 — Log Review, Thresholds, and Automated Alerts

What it requires: Logs must be regularly reviewed. Organisations should establish threshold values that trigger automatic alarms where feasible, followed by a timely, qualified response.

Audit evidence: Documented alarm thresholds for the highest-risk log categories; evidence that alerts are routed to a named responder or team; investigation and closure records showing alerts were acted on within a defined SLA.

The phrase “timely qualified response” is not defined numerically in the CIR. In practice, security operations teams use Mean Time to Detect (MTTD) as their benchmark. Industry data places the standard for critical events at under one hour. Building your internal SLAs around this benchmark provides a defensible position with auditors and aligns your programme with the directive’s intent.

Effort: High initially — threshold design is specialist work. Medium ongoing.

3.2.5 — Log Protection and Retention

What it requires: Logs must be maintained and backed up for defined periods. They must be protected against unauthorised access and modification — a tamper-evident or immutable storage model.

Audit evidence: Write-once or append-only log storage confirmation; access control records showing only authorised personnel can access raw logs; backup records confirming retention for the defined period.

The retention question — what the regulation actually says: CIR Section 3.2.5 does not specify a minimum retention duration. Neither does the NIS2 Directive itself. National implementations vary: some member states have issued guidance citing 18 months, particularly for essential entities. ISMS.online documents this 18-month floor as a reference point for organisations seeking to align with the strictest national interpretations. A 12-month minimum — 6 months in hot (online, queryable) storage plus 6 months in cold archive — is the practical floor that survives most national audits and supports forensic reconstruction across the widest range of incident scenarios. Higher-risk sectors such as financial services or healthcare may face sector-specific rules requiring up to 7 years. Document your chosen period with a risk-based rationale and have legal counsel review it against your jurisdiction’s national NIS2 transposition.

Effort: Medium. Immutable storage configuration is a one-time technical task; the ongoing effort is periodic capacity reviews.

3.2.6 — Time Synchronisation

What it requires: Where feasible, organisations should ensure synchronised time sources across all logging assets and maintain an up-to-date list of those assets.

Audit evidence: NTP or PTP configuration on all log-generating systems; evidence that timestamps correlate correctly across sources. Misaligned timestamps make incident reconstruction unreliable, which is why auditors examine this specifically when reviewing investigation capability.

Effort: Low. Time synchronisation is standard infrastructure practice. The gap is usually documentation: proving all logging assets share a time reference.

3.2.7 — Periodic Review of Monitoring Procedures

What it requires: Logging procedures and the asset coverage list must be reviewed at defined intervals and following significant security incidents.

Audit evidence: A defined review schedule (annual minimum is typical); records of reviews performed; evidence that the asset list was updated when new systems were deployed or decommissioned.

Effort: Low. This is documentation governance work, not technical work. The common failure is treating the asset list as a one-time setup task rather than a living document.

Log Retention in Practice — 6 Months, 12 Months, or 18 Months?

The log retention question is one of the most common sources of confusion in NIS2 compliance planning, and the honest answer is that the regulation itself does not give you a single number to work from.

Here is the picture at each authority tier:

Tier 1 — The regulation: CIR Section 3.2.5 requires logs be maintained and backed up with access protection. No duration is specified. NIS2 Article 21 does not set a retention floor either.

Tier 2 — National and sector regulators: Several member states have issued guidance or national transpositions specifying retention periods. Requirements published by national cybersecurity authorities in Germany, the Netherlands, and France reference durations in the 12–18 month range for critical infrastructure entities. These apply within their jurisdictions and are not uniform across the EU.

Tier 3 — Industry consensus: Most NIS2 practitioners and security consultants cite 12 months as a practical, defensible minimum. The rationale: advanced persistent threats regularly maintain access for weeks or months before detection. An incident discovered today may require log evidence from well before the discovery date. Hot storage for 6 months enables rapid querying during active investigations; archived logs for the following 6 months enable forensic reconstruction if the incident timeline extends further back.

Set your retention policy in writing, document the risk basis for the period you choose, and verify it against your jurisdiction’s national NIS2 transposition. If you operate across multiple member states, apply the strictest requirement among the relevant jurisdictions.

Anomaly Detection — From Log Data to Actionable Alerts

CIR Section 3.2.4 requires threshold-based alerting and a timely, qualified response. In practice, this means your monitoring infrastructure must distinguish between baseline activity and events that warrant investigation. Three steps make this work.

Step 1: Establish behavioural baselines. Before you can detect anomalies, you need to define normal. For network traffic, that means typical peak and off-peak bandwidth per segment, standard DNS query volumes, expected authentication geographies, and normal authentication failure rates per hour. A 3 AM login from an unrecognised country is worth flagging; 300 failed logins in 60 seconds against a single account warrants automatic lockout. Neither is useful without a defined baseline.

Step 2: Map anomalies to NIS2 reporting thresholds. Not every anomaly requires an incident report. NIS2 Article 23 defines a significant incident as one causing substantial disruption to service delivery or affecting other entities. The anomaly categories that consistently escalate to that threshold include: large-scale data exfiltration indicators, authentication bypass patterns, ransomware staging behaviour (lateral movement combined with large-scale encryption activity), and persistent command-and-control traffic. Your detection rules should route these to immediate human review — not just logging — because they sit directly upstream of the 24-hour early-warning notification obligation under Article 23. For the full incident reporting workflow, see our NIS2 incident reporting guide.

Step 3: Reduce false positives without creating blind spots. CIR Section 3.2.2 explicitly requires minimising both false positives and false negatives. Alert fatigue — caused by too many false positives — leads analysts to begin ignoring alerts, which creates the blind spots the regulation is designed to prevent. The operational solution is alert tiering: automated suppression of known-benign patterns combined with a weekly tuning cycle that adjusts thresholds based on the prior week’s false-positive patterns.

In-House SIEM vs. MSSP — A Cost Decision Matrix

The CIR does not require you to operate your own SIEM. It requires that the monitoring and logging obligations in Section 3.2 are met — how you deliver that capability is your decision. The build-versus-buy choice depends on four factors.

Factor	In-House SIEM / SOC	MSSP / MDR
Annual cost (indicative)	EUR 300K–680K/year including staff, SIEM licensing, training	$36K–$180K/year depending on coverage tier
Staffing requirement for 24/7	5–6 Tier 1/2 analysts + 1–2 Tier 3 experts + SOC manager	Included in service fee
Time to operational readiness	6–18 months (hiring, integration, tuning)	4–12 weeks
NIS2 compliance documentation	You produce it internally	MSSP must supply it — verify content before signing
Legal liability for NIS2	Full internal ownership	You retain liability; MSSP provides operational and evidence support
Detection customisation	Full control over rules, data sources, and tuning	Depends on provider’s tuning flexibility and onboarding process
Recommended for	Organisations >3,000 employees with strong security talent retention	SMEs and mid-market up to ~3,000 employees

Based on SecurHUB’s cost analysis, building an in-house SOC costs PLN 1.3–2.9 million annually (approximately EUR 300K–680K), covering salaries for five to six Tier 1/2 analysts, one to two Tier 3 experts, a SOC manager, SIEM and XDR licences, threat intelligence feeds, and ongoing training. An MSSP delivering equivalent coverage typically costs 20–40% of that figure. Managed SIEM entry pricing starts at $3,000–$5,000 per month for SMB-scale coverage, rising to $5,000–$15,000/month at mid-market scale.

The break-even point shifts when you factor in detection quality, not just cost. In-house teams require 6–18 months to reach operational maturity. An MSSP with established playbooks can reach full coverage in weeks.

If you choose an MSSP, require the following in your contract:

• SOC 2 Type II attestation — 12-month effectiveness period, not just Type I readiness
• ISO 27001 certification
• Contractual MTTD and MTTR SLAs — industry benchmarks are MTTD under one hour and P1 MTTR under four hours
• A defined NIS2 audit documentation package: what they will produce, in what format, on what schedule
• Documented staff qualification thresholds and personnel turnover commitments

Outsourcing monitoring does not transfer your NIS2 legal obligations. NIS2 Articles 32–33 supervisory and enforcement provisions apply to your organisation’s management — not to your service provider. Treat your MSSP as an operational arm, not a liability shield.

Audit Documentation Checklist for NIS2 Logging Compliance

When a NIS2 supervisory authority requests evidence of your logging and monitoring compliance, the following documents must exist. Each maps directly to the CIR control it satisfies. For how this evidence integrates with your broader compliance programme, see our NIS2 audit preparation guide.

Evidence Item	CIR Control	Priority
Written monitoring and logging policy	3.2.1, 3.2.7	Must-have
Logged asset register with risk-based justification	3.2.3	Must-have
Log category scope list with exclusion rationale	3.2.3	Must-have
SIEM/monitoring tool configuration documentation	3.2.1, 3.2.2	Must-have
Defined alert thresholds and escalation procedures	3.2.4	Must-have
Alert investigation and closure records	3.2.4	Must-have
Log storage architecture diagram with retention periods	3.2.5	Must-have
Log access control policy and permissions audit trail	3.2.5	Must-have
Evidence of immutable or append-only log storage	3.2.5	Must-have
NTP/PTP configuration records for all logging assets	3.2.6	Recommended
Annual monitoring policy review records	3.2.7	Must-have
MSSP contract with defined SLAs (if applicable)	3.2.1, 3.2.4	Must-have if MSSP used

Key Takeaways

CIR Section 3.2 creates seven distinct monitoring and logging controls, not a single checkbox. Treating NIS2 logging compliance as a tool selection exercise misses the obligation to document a risk-based asset list (3.2.3), calibrate thresholds that reduce false positives and false negatives simultaneously (3.2.2, 3.2.4), protect logs from modification with immutable storage (3.2.5), and review your monitoring programme after significant incidents (3.2.7).

The log retention ambiguity is genuine — document your rationale, not just your number. A 12-month policy with a 6-month hot/cold split is a defensible, practical baseline. Check your jurisdiction’s national NIS2 transposition for any local minimum, and apply the strictest requirement if you operate across borders.

For organisations under 3,000 employees, a well-contracted MSSP is almost always more cost-effective than an in-house SOC. The legal obligation stays with your management regardless of which model you choose. Start with the asset list: every other Section 3.2 requirement flows from knowing precisely what you are logging and why.

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.

Frequently Asked Questions

Is there a specific log retention period in NIS2?

No. Neither the NIS2 Directive nor CIR 2024/2690 specifies a minimum retention duration. CIR Section 3.2.5 requires logs to be maintained, backed up, and protected, but leaves the duration to a documented, risk-based decision. National implementations vary: some member states reference 18 months for essential entities in their guidance. A 12-month minimum (6 months hot, 6 months archived) is widely accepted as a defensible baseline for most organisations.

Does NIS2 specifically require a SIEM tool?

No. CIR Section 3.2.1 requires procedures and tools for monitoring and logging — the specific tooling is not prescribed. A SIEM is the most common approach for centralised log collection and event correlation, but IDS, EDR, and dedicated log management platforms can collectively satisfy the requirement if they cover the log categories listed in Section 3.2.3.

What is “CIR Annex 8” and does it cover monitoring?

CIR 2024/2690 Section 8 covers cyber hygiene and cybersecurity training. The association with monitoring likely comes from ISO 27001:2022, which places logging in Annex A 8.15 and monitoring in Annex A 8.16. These are different frameworks with different numbering conventions. NIS2 monitoring and logging requirements are in CIR Section 3.2.

If we use an MSSP, are we still responsible for NIS2 compliance?

Yes. NIS2 Articles 32–33 place compliance obligations on the entity itself, with personal accountability provisions applying to your management. An MSSP provides the operational monitoring capability; your organisation retains full legal responsibility. Your contract must include NIS2-compatible audit documentation, and you must verify — not assume — that the service meets Section 3.2 technical requirements.

Does the 12-log-category list in Section 3.2.3 apply rigidly to all organisations?

The regulation requires that your logged asset list be based on a risk assessment, meaning justified exclusions are permissible. A small cloud provider operating entirely in a colocation facility managed by a third party may not require physical facility access logs of its own. The audit looks for a documented, risk-based decision — not complete coverage of every category irrespective of context.

How does NIS2 monitoring connect to the 24-hour incident reporting obligation?

An effective monitoring stack is what makes the 24-hour early-warning deadline achievable. CIR Section 3.2.4 requires threshold-based alerting and timely qualified response, which means your detection capability must identify potential significant incidents before the Article 23 reporting clock starts. Detection systems that only aggregate logs without generating actionable alerts cannot reliably support the notification timeline. See our incident reporting guide for the full notification workflow.

Sources

• Commission Implementing Regulation (EU) 2024/2690 — Official Journal of the EU: eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng
• NIS2 Implementing Act (EU) 2024/2690: ISO 27001 Mapping — OpenKRITIS: openkritis.de
• CIR 2024-2690 Annex 1: Technical and Methodological Requirements — Advisera: advisera.com/cir-2024-2690
• MSSP 2025: Choosing a Managed Security Provider — SecurHUB: securhub.pl
• 8 Best Managed SIEM Vendors Ranked 2026 — UnderDefense: underdefense.com
• NIS2 Technical Implementation Guidance — ENISA: enisa.europa.eu/publications/nis2-technical-implementation-guidance
• NIS2 Directive (EU) 2022/2555 — EUR-Lex: eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022L2555
• Meet NIS2 Logging & Retention Deadlines — ISMS.online: isms.online/nis-2/controls/logging-minimums/