NIS2 logging requirements: what to log, how long to keep logs and how to review them

NIS2 logging requirements in short

The NIS2 logging requirements are set out in Annex point 3.2 of Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024, which details incident handling, a measure that Article 21(2)(b) of the NIS2 Directive, Directive (EU) 2022/2555, names without mentioning logs. Point 3.2 requires procedures and tools to monitor and log activity, a list of assets to be logged based on the risk assessment, regular review of the logs, alarm thresholds where appropriate and a timely response to alarms. Logs are kept and backed up “for a predefined period” and protected from unauthorised access or changes. Time sources are synchronised to the extent feasible, and monitoring and logging systems are redundant.

Neither Article 21 nor point 3.2 sets a number of days, so the retention period is a decision the company makes and documents. ENISA’s Technical Implementation Guidance, published on 26 June 2025, ties it to “business needs, the risk assessment results and legal requirements/obligations”. Below, each point is mapped onto an estate of 10 to 60 VMware hosts and 500 to 2,000 VMs; the ten measures as a whole are in our guide to NIS2 Article 21.

Implementing Regulation 2024/2690 point 3.2: scope and wording

The regulation binds only the “relevant entities” of its Article 1, digital providers such as DNS, cloud computing, data centre, managed and managed security service providers. ENISA’s guidance says its indications “may be considered useful by other public or private bodies for improving their cybersecurity”, so others can use point 3.2 as a reference. Whether NIS2 applies to a company is a legal assessment for its legal department.

Point 3.2.1 asks for procedures and tools “to monitor and log activities on their network and information systems to detect events that could be considered as incidents”. Under point 3.2.2, monitoring is automated to the extent feasible, runs “either continuously or in periodic intervals, subject to business capabilities” and should minimise false positives and false negatives.

Where a relevant entity does not apply a requirement qualified “where appropriate”, “where applicable” or “to the extent feasible”, Article 2(2) asks it to document its reasoning “in a comprehensible manner”.

What to log under point 3.2.3, mapped to log sources

Point 3.2.3 asks entities to “maintain, document, and review logs” and to establish a list of assets to be logged, based on the risk assessment of point 2.1. Where appropriate, the logs include the twelve items below, shown with typical sources in a mid-size VMware estate.

Implementing Regulation (EU) 2024/2690, Annex point 3.2.3 (eur-lex.europa.eu); ESX log file contents from Broadcom KB 306962. The sources and example events are our summary.

ENISA’s examples of evidence for point 3.2.3 include samples of current and historical DNS and DHCP logs; DHCP records tie an IP address in a firewall log to one machine.

Log sources in an estate of 10 to 60 VMware hosts

With 500 to 2,000 VMs, logging every guest in full detail produces more data than an IT team can review, so the risk assessment picks the systems whose compromise matters most: the domain controllers and the directory service, vCenter and the hosts, the backup server and its repositories, firewalls and VPN, jump hosts and the password vault, internet-facing servers and the main business applications. The other VMs send their security tool events and sign-ins.

Broadcom’s KB 318939 describes the ESX setting Syslog.global.logHost as “a comma-delimited list of remote servers where logs are sent using the syslog protocol” and warns that “If the logHost field is blank, no logs are forwarded.” On the host, auth.log records “ESXi Shell authentication success and failure” and shell.log records shell use, “including enable/disable and every command entered” (KB 306962). Broadcom’s vSphere 8.0 and 9.0 documentation limits vCenter log forwarding to three syslog destinations. Audit records and the related hardening settings are in our guide to ESXi ransomware hardening.

On the backup server, the events to keep are administrator sign-ins, account changes and the deletion of jobs, restore points or repositories, item (f). For GPU servers and a private AI platform, BMC sign-ins and event logs belong to item (j), and sign-ins, administrator changes, new API keys and model deployments on the platform to items (c) and (e). Alert rules for privileged events are in our guide to privileged access management.

We would place two collectors in the management network, on different hosts or sites, administered with accounts outside the production directory, feeding a central store or SIEM with its own backup.

Event centralisation in a SIEM is part of our cyber resilience service, with engineering by our partner Vixen.UNO. Send us the list of systems that log to a central place today and the ones that do not.

NIS2 log retention: how long to keep logs

Point 3.2.5 states that “The relevant entities shall maintain and back up logs for a predefined period and shall protect them from unauthorised access or changes.” ENISA’s guidance says the retention period “should be in line with” point 4.2.2(f), which asks backup plans to include “retention periods based on business and regulatory requirements”. It also says that “The backup logs’ maintenance period shouldn’t be shorter than the logs’ review period”.

Outside EU law, the SIEM practitioner guidance that ASD’s Australian Cyber Security Centre and CISA published with partners on 27 May 2025 says that, for organisations new to detection, a starting point “may be a minimum of one year” for logs that record administrative and security-related events and 90 days for informational logs.

Implementing Regulation (EU) 2024/2690, Annex points 2.1, 3.2.5, 3.5.4 and 4.2.2(f); ENISA Technical Implementation Guidance v1.0 (26 June 2025); Regulation (EU) 2016/679, Article 5(1)(e); ASD and CISA SIEM practitioner guidance (27 May 2025). The Decision and Inputs columns are our summary of these sources.

Write the result down per log class: the period in the searchable store, the period in backup and who may delete. Among ENISA’s examples of evidence are “A retention period is set” and “Logs do not contain data about which retention periods have expired.” How the GDPR, sector rules or customer contracts affect the periods is a legal assessment for the company’s legal department.

Protecting logs, time synchronisation and redundancy

To protect logs, ENISA’s guidance on point 3.2.5 lists access control, encryption, hashing and “logging of all access and changes to log files”. A domain administrator account should not open the collectors or change the store’s retention settings, so use separate administrator accounts with MFA and keep one copy on storage that refuses deletion before the retention date.

Point 3.2.6 asks, to the extent feasible, that “all systems have synchronised time sources to be able to correlate logs between systems for event assessment”. ENISA suggests NTP or PTP, a central time server inside the entity and “multiple time sources to avoid a single point of failure”, and adds: “Use authenticated NTP to prevent malicious entities from tampering with your time synchronization.” Point hosts, vCenter, firewalls, switches, BMCs and the domain controller that serves time to the domain at the same two internal time servers with more than one upstream source.

The same point requires that “monitoring and logging systems are redundant” and that their availability “shall be monitored independent of the systems they are monitoring”. ENISA’s guidance on this point reads “Deploy separate tools to monitor the capacity and availability” of the primary monitoring and logging systems. For a mid-size estate, two collectors, a second copy of the central store and a check that runs outside the cluster it watches are one way to address that wording.

Log review, alarm thresholds and the response to alarms

Point 3.2.4 requires logs to be “regularly reviewed for any unusual or unwanted trends”, alarm thresholds where appropriate and, “in case of an alarm, a qualified and appropriate response is initiated in a timely manner”. ENISA’s indicative thresholds include “three or more account lockouts within 15 minutes” and “two or more instances of privilege escalation (e.g. normal user to admin) within 24 hours”, with the footnote “The thresholds are subject to the operational environment.”

Point 3.4.2 adds “a process for log correlation and analysis”, and point 3.5.4 requires incident response activities to be logged with evidence; the reporting deadlines that depend on these records are in our guide to NIS2 incident reporting. We suggest this review cycle for a mid-size estate.

1. Handle each alarm when it fires, since point 3.2.4 asks for a timely response, and each working day record every alarm of the past day as an event or an incident under the predefined criteria.
2. Each week, read a summary report for trends, such as sign-ins outside working hours or rising failed authentications, and adjust thresholds that fire without cause.
3. Each month, compare the list of logged assets with the asset and vCenter inventories, and check that every source has sent logs within the last day.
4. Each quarter, assess recurring incidents, as point 3.4.2(b) requires of relevant entities.
5. Each year and after significant incidents, review the procedures and the list of logged assets (point 3.2.7; ENISA says “at least annually”), and restore a sample of logs from backup.

Vulnerability scan records belong to point 6.10 and patch records to point 6.6, both covered in our guide to NIS2 vulnerability handling.

Our cyber resilience service includes an incident response plan with roles, actions and deadlines. Describe in the form below who reviews logs today and who receives alarms outside office hours.

NIS2 SIEM requirement and point 3.2.1

Point 3.2.1 asks for procedures and tools without naming a product category. ENISA’s examples of evidence for automated monitoring under point 3.2.2 include SIEM systems “used to analyse data and identify deviations from established patterns”, next to EDR and XDR tools. A central log store with alerting and search is one way to address that wording, and a SIEM automates much of the log correlation and analysis process that point 3.4.2(d) asks for. The tool categories, and who watches alerts at night, are in our comparison of EDR, XDR, SIEM and MDR.

General information on EU law as of October 2026, not legal advice for an individual case.

What we do

Under our cyber resilience service, our engineering partner Vixen.UNO sets up event centralisation in a SIEM and EDR/XDR on workstations and servers, on Trend Micro, Cisco and other vendors’ solutions. The security and compliance assessment reviews infrastructure, access, backups and compliance with NIS2 requirements, and gives you a risk map and a prioritised action plan. The NIS2 compliance map is a technical assessment, and the legal opinion on compliance is prepared by your legal department. Changes are rolled out in agreed maintenance windows with a rollback plan, followed by support under an agreed SLA, and our partner’s engineers work in your environment under your access controls, as our security and compliance page describes. Retention periods and who receives alarms remain your company’s decisions.

FAQ