Microsoft Sentinel for NIS2: Configuring SIEM Logging to Meet CIR 2024/2690 Section 3.2

Search for “NIS2 logging Annex 6.11” and you’ll find the number circulating in vendor blog posts and LinkedIn threads — it doesn’t exist. Commission Implementing Regulation (EU) 2024/2690’s Annex runs 13 numbered sections, and logging and monitoring sit in Section 3.2, under “Incident handling,” not in Section 6 (which covers system acquisition and development, subsections 6.1 through 6.10) [2]. Citing the wrong provision in an audit conversation is a bad first impression. This guide maps what Section 3.2 actually requires onto a working Microsoft Sentinel workspace: retention settings, data connectors, and the documentation an inspector will ask to see.

Does CIR 2024/2690 Apply to Your Organisation?

In plain terms: CIR 2024/2690 is not a universal NIS2 requirement. It binds a specific list of digital-infrastructure and ICT-service entities named in Article 21(5) of the NIS2 Directive — if you’re outside that list, your national transposition law and its risk-management guidance apply instead, and Section 3.2 is best-practice reference rather than a binding citation [1].

Entity type	CIR 2024/2690 applies?
DNS service providers, TLD registries	Yes
Cloud computing service providers	Yes
Data centre service providers	Yes
Content delivery network providers	Yes
Managed service & managed security service providers	Yes
Online marketplaces, search engines, social networking platforms	Yes
Trust service providers	Yes
All other essential/important entities (manufacturing, energy, healthcare, finance, etc.)	No — governed by national transposition law instead

Even outside CIR’s binding scope, Section 3.2’s seven controls are a reasonable technical benchmark: national competent authorities routinely point regulated entities toward the same “appropriate and proportionate” measures the CIR spells out in detail [6].

What CIR 2024/2690 Section 3.2 Actually Requires for Logging

In plain terms: Section 3.2 doesn’t hand you a retention number. It requires a documented, risk-based logging programme covering seven specific controls — and the regulation leaves the exact retention period for your organisation to define and justify.

Control	Requirement
3.2.1	Documented procedures and tools to monitor and log activity across network and information systems
3.2.2	Monitoring automated, run continuously or at defined periodic intervals
3.2.3	A risk-based, documented list of what gets logged — traffic, account changes, system/app access, authentication, privileged activity, config changes, security-tool alerts, resource usage, physical and environmental events
3.2.4	Regular review of logs for unusual or unwanted trends
3.2.5	Logs maintained and backed up for a predefined period, protected from unauthorised access
3.2.6	Synchronised time sources across logging assets
3.2.7	Periodic review and update of procedures and the logged-asset list

[2]

Mapping Section 3.2’s Seven Controls to a Microsoft Sentinel Workspace

Sentinel is built on Azure Monitor Log Analytics, so most of Section 3.2 maps to configuration choices rather than new tooling [4]. The gap most teams carry isn’t capability — it’s that the default settings were never deliberately chosen against the regulation’s language.

Section 3.2 control	Sentinel/Log Analytics capability	Effort to close the gap
3.2.1 — documented monitoring procedures	Written SOP referencing your logging and monitoring policy and workspace architecture	Low
3.2.2 — continuous/periodic automated monitoring	Scheduled and near-real-time analytics rules	Medium
3.2.3 — risk-based log-type list	Data connector selection mapped to the required categories (below)	Medium
3.2.4 — regular review for anomalies	Analytics rules plus UEBA anomaly detections; documented review cadence	Medium
3.2.5 — predefined retention, protected from tampering	Table-level retention settings; Sentinel inherits Azure Monitor’s append-only, tamper-resistant storage	Low
3.2.6 — synchronised time sources	NTP/PTP on log sources before ingestion — Sentinel doesn’t correct source timestamps	Low (source-side, not Sentinel-side)
3.2.7 — periodic procedure review	Scheduled review of the connector list and analytics rules against current asset inventory	Low

Configuring Log Analytics Retention for the “Predefined Period” Requirement (3.2.5)

In plain terms: pick a retention period, write down why, and configure it explicitly — the regulation’s silence on an exact number is not permission to leave the workspace on its defaults.

A new Log Analytics workspace defaults to 30 days of interactive (queryable) retention for most tables; the Usage and AzureActivity tables get 90 days free [3]. That default was set for troubleshooting cost control, not for compliance evidence, and it is almost never what a documented 3.2.5 policy should say. Two settings do the work:

• Interactive (analytics) retention — extendable per table up to 730 days (2 years) at additional ingestion cost. This is the window where you can query logs directly for investigation.
• Total retention — stacks a low-cost, long-term archive tier on top of interactive retention, extendable to 12 years (4,383 days). Data here isn’t directly queryable; a search job pulls a specific slice back into an interactive table when needed.

As a general guideline, teams building a documented retention policy for CIR-scoped entities size interactive retention to active investigation needs (often 90–180 days) and stack archive retention on top to cover the total period the policy commits to — commonly 12–18 months in practice, though this is an organisational choice justified by risk assessment, not a number CIR 2024/2690 states outright [2][3]. Basic and Auxiliary-plan tables, used for high-volume, lower-value logs, default to a fixed 30-day total retention — confirm nothing feeding your 3.2.3 log-category list is quietly capped there.

The trade-off is cost versus queryability, not cost versus compliance. Basic and Auxiliary-plan tables cost substantially less per GB ingested than Analytics-plan tables, which makes them attractive for high-volume, low-value-per-event sources like verbose network flow logs. The catch: Basic-plan tables only support a narrower KQL query surface, and both plans cap total retention at 30 days by default unless extended. A defensible pattern is Analytics plan for the categories 3.2.4 requires active review on (authentication, privileged activity, security-tool alerts) and Basic or Auxiliary plan — with total retention explicitly extended to match the documented policy — for high-volume categories reviewed only during an investigation.

Choosing Data Connectors for the Log Categories Required Under 3.2.3

Section 3.2.3’s list reads like a checklist against Sentinel’s connector catalogue [2][5]:

• Authentication and privileged-activity logs — Microsoft Entra ID connector (sign-ins, audit logs, privileged role assignment changes)
• Configuration and admin-action logs — Azure Activity connector (resource-level changes, admin operations)
• Network traffic and network-equipment logs — NSG flow logs, firewall and network-appliance feeds via Syslog/CEF over the Azure Monitor Agent (AMA)
• Security-tool logs — native connectors for Defender XDR and third-party tools, or Syslog/CEF/AMA where no packaged connector exists
• Physical access and environmental events — rarely have a native connector; ingest via custom logs over AMA if the physical access control system can export syslog or flat files

The physical/environmental category is the one teams most often drop, since building security systems weren’t built with a SIEM in mind. Documenting that gap — and a compensating manual review process — satisfies 3.2.1’s “procedures and tools” requirement better than pretending Sentinel ingests it automatically.

Once a connector lands data, Sentinel normalises it through the Advanced Security Information Model (ASIM), so authentication events from Entra ID and a third-party VPN concentrator can be queried through the same schema instead of two incompatible table structures. That matters for 3.2.4’s “regular review” control: a single scheduled analytics rule can cover a log category end-to-end, rather than one rule per connector [7].

Documentation an NCA Inspector Will Ask to See

A working Sentinel deployment doesn’t prove compliance by itself — the paper trail around it does. A CIR-scoped entity should be able to produce:

• A written logging and monitoring policy naming the retention period and its rationale (3.2.1, 3.2.5)
• The current data-connector inventory, mapped to the log categories in 3.2.3
• Evidence of scheduled log review (ticket history, analytics-rule run logs, or a review register) (3.2.4)
• Time-synchronisation configuration for logging assets (3.2.6)
• A dated record of the last procedure and asset-list review (3.2.7)
• Access control records for who can read or modify the Log Analytics workspace, supporting the “protected from unauthorised access” language in 3.2.5

None of this needs to be elaborate. A one-page policy with a change log, reviewed annually, generally outperforms a lengthy document nobody updates.

Role Responsibilities: Who Owns What

Role	Owns
CISO / IT Security Manager	Connector selection, retention configuration, analytics-rule tuning, workspace access control
Compliance Officer	Written policy, retention rationale, documentation checklist, evidence collection ahead of an audit
IT Operations	Time synchronisation on source systems, physical/environmental log export where no native connector exists
Board / Management	Sign-off on retention cost vs. risk trade-off; accountability for the documented programme under Article 21

Common Implementation Mistakes

• Citing “Annex 6.11.” It doesn’t exist. Section 3.2 is the correct reference — getting this wrong in front of an auditor undermines confidence in the rest of the programme.
• Leaving retention on workspace defaults. Thirty days of interactive retention with no archive tier rarely satisfies a documented “predefined period” that also has to survive an incident investigation months later.
• Treating “we have Sentinel” as the compliance answer. 3.2.1, 3.2.4, and 3.2.7 are procedural requirements — a tool without a written procedure and a review cadence doesn’t satisfy them.
• Assuming CIR 2024/2690 applies universally. If your entity isn’t on the Article 21(5) list, Section 3.2 is a strong reference architecture, not your binding citation — check your national transposition law first [1].

The bottom line: Section 3.2 rewards organisations that treat logging as a documented, reviewed programme rather than a box Sentinel ticks by existing. The technical work — connectors, retention tiers, ASIM normalisation — is usually a few days of configuration. The habit that actually satisfies an auditor is the recurring one: someone reviews the logs, someone reviews the procedure annually, and both are written down.

Frequently Asked Questions

Does NIS2 or CIR 2024/2690 mandate a specific log retention period, like 12 months?
No. Section 3.2.5 requires a “predefined period” that the entity defines and justifies through its own risk assessment; the regulation does not state a fixed number of months [2].

Is Microsoft Sentinel itself “NIS2 compliant”?
No single tool is compliant on its own. Sentinel can satisfy the technical controls in Section 3.2 when configured and documented correctly, but compliance is a property of the organisation’s whole programme — policy, procedure, and evidence — not the software.

Do I need Microsoft Sentinel specifically, or will another SIEM satisfy Section 3.2?
Section 3.2 is technology-neutral; it describes required capabilities, not a named product. Any SIEM that supports automated monitoring, the required log categories, retention controls, and access protection can satisfy it.

What happens after Sentinel’s Azure portal retirement in March 2027?
Sentinel continues in the Microsoft Defender portal; workspaces should plan the transition ahead of the March 2027 cut-off rather than treating it as a compliance risk in itself [4].

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

• Article 21 — NIS2 Directive (EU) 2022/2555, via nis2resources.eu
• Commission Implementing Regulation (EU) 2024/2690, Annex — Technical and methodological requirements, via advisera.com
• Manage data retention in a Log Analytics workspace — Microsoft Learn
• What is Microsoft Sentinel SIEM? — Microsoft Learn
• Find your Microsoft Sentinel data connector — Microsoft Learn
• NIS2 FAQ — National Cyber Security Centre (NCSC) Ireland
• Normalization and the Advanced Security Information Model (ASIM) — Microsoft Learn