NIS2 logging requirements explained

The NIS2 Directive (EU) 2022/2555 is the EU's updated cybersecurity law for essential and important entities. It replaces the original 2016 NIS Directive, widens the sectors in scope, and raises the bar on cybersecurity risk management, incident reporting, and management accountability. The transposition deadline for Member States was 17 October 2024; national laws implement it and several countries were late, so the exact wording you must follow is your local transposition.

Logging sits at the centre of two of NIS2's core duties: the risk-management measures in Article 21 (you must be able to detect, handle and recover from incidents) and the reporting obligations in Article 23 (you must report significant incidents quickly and accurately). You cannot detect, investigate, or report an incident you never recorded — which is why a credible logging and monitoring capability is effectively mandatory.

NIS2 splits regulated organisations into two tiers, both of which carry the same security obligations but face different supervision:

• Essential entities — larger operators in high-criticality sectors such as energy, transport, banking, financial market infrastructure, health, drinking and waste water, digital infrastructure, public administration, and space.
• Important entities — operators in other critical sectors such as postal services, waste management, chemicals, food, manufacturing, digital providers, and research.

Scope generally follows a size-and-sector test (typically medium-sized and larger organisations in a listed sector), with some entity types in scope regardless of size. If you supply services into these sectors, your customers' NIS2 obligations frequently flow down to you through contracts and supply-chain security requirements.

The directive states the outcome — you must be able to detect and analyse incidents — while the detailed technical expectations for several digital-sector entities are spelled out in Commission Implementing Regulation (EU) 2024/2690. It calls for logging policies that establish what is recorded, reviewed and retained, and continuous monitoring of that data. In practice, a defensible NIS2 logging baseline captures:

• Authentication and access events — successful and failed logins, MFA challenges, privilege escalation, session creation.
• Administrative and privileged actions — account creation and changes, permission grants, use of admin or service accounts.
• Configuration and change events — changes to systems, security controls, firewall rules, and critical applications.
• Network and security telemetry — traffic at boundaries, IDS/IPS and endpoint alerts, malware and DLP events.
• Application and system events — errors, service failures, and audit trails from business-critical applications.
• Data access events — access to sensitive or regulated data stores, especially for personal data overlapping with the GDPR.

Logs should carry enough context — accurate timestamps from a synchronised clock source, the acting identity, source and destination, and the outcome — to reconstruct a sequence of events during an investigation.

NIS2 does not set a single statutory retention number. The requirement is risk-based: keep logs long enough to detect a slow-moving incident, investigate it, and meet your reporting and forensic needs. Because attackers often dwell for months before discovery, very short retention undermines the directive's intent.

In practice, organisations and national guidance converge on a window of roughly 6 to 18 months, often split into a hot tier for fast querying and a cheaper archive tier for forensic reconstruction. Some national transpositions and sector regulators set their own minimums, and overlapping regimes (GDPR, DORA, ISO 27001, PCI DSS) may pull the figure in different directions.

Collecting logs is not enough — NIS2 expects you to use them. Implementing Regulation (EU) 2024/2690 describes continuous monitoring of events, threshold-based alerting, and a timely, qualified response. That means your monitoring needs to:

1. Centralise logs from across the estate so they can be searched and correlated, rather than sitting in silos on individual systems.
2. Distinguish baseline activity from events that warrant investigation — through detection rules, thresholds, and anomaly detection.
3. Alert a responsible team in time to act, with enough context to triage and escalate.
4. Support correlation across sources, so a multi-step attack is seen as one chain rather than scattered, unrelated lines.

This is the functional definition of a SIEM (Security Information and Event Management) capability. NIS2 does not name a product category, but it is hard to satisfy continuous monitoring, correlation and qualified response at scale without one.

Article 23 sets a multi-stage clock for significant incidents. Your logs are the evidence base for every stage, which is another reason they must be searchable quickly:

Hitting a 24-hour early-warning window depends on having already detected the incident and being able to pull the relevant events fast. Slow search or missing logs turn a reporting deadline into a compliance failure.

Logs are both evidence and a target. An attacker who can edit or delete them can hide their tracks, so NIS2's integrity and access-control expectations apply to the log store itself:

• Integrity — store logs so they cannot be silently altered (append-only / tamper-evident storage), preserving their evidentiary value.
• Access control — restrict who can read and administer logs, and log that access too.
• Availability — ensure logs survive the failure or compromise of the systems that produced them (centralised, off-host).
• Confidentiality and the GDPR — logs often contain personal data; handle and, where appropriate, redact it in line with data- protection obligations.

Use this as a starting baseline and adapt it to your sector and national law:

• Centralised collection of authentication, admin, change, network and application logs.
• Synchronised, accurate timestamps and consistent identity/source fields.
• A written, risk-justified retention policy (commonly 6–18 months), checked against national transposition.
• Tamper-evident storage with access control and audited log-access.
• Continuous monitoring with detection rules, thresholds and anomaly detection.
• Correlation across sources to surface multi-step attacks.
• Alerting and an incident-response process that can meet the 24h / 72h / 1-month deadlines.
• Evidence and reporting workflow that maps incidents to the Article 23 stages.
• PII handling/redaction for logs containing personal data.

LogPulse centralises your logs on one engine, retains them for the window your plan provides, and monitors them in real time — search, anomaly detection, and a risk-based Security Monitoring (SIEM) layer on the same data, so continuous monitoring and correlation do not require a separate, separately-priced security stack. Detections map to NIS2, DORA and ISO 27001 controls, and log data stays in the EU (GDPR-compliant by default), which matters when your obligations are themselves EU-driven.

For the full picture of how this maps to the directive, see the NIS2 compliance overview, and the related DORA obligations if you are a financial entity. LogPulse supports your compliance programme and produces evidence; it is not itself a certification.