If you run infrastructure for a company that falls under NIS2 (or sells to one), you will eventually be asked: "Are we logging what NIS2 requires?" The Directive itself does not contain the word SIEM. But read Articles 21 and 23 together with the Commission's Implementing Regulation (EU) 2024/2690 and the logging requirements become quite specific.
This post maps those texts to concrete log sources and events, and shows how to cover them with tools you host yourself.
This is a practical summary, not legal advice. Always check the official text and your national transposition.
Where logging appears in the Directive
Article 21(1) requires essential and important entities to take "appropriate and proportionate technical, operational and organisational measures" to manage risks to their network and information systems. Article 21(2) lists the minimum set. Three items depend directly on logs:
- (b) incident handling. You cannot detect, analyse or contain an incident without a record of what happened.
- (f) policies and procedures to assess the effectiveness of cybersecurity risk-management measures. Logs are how you prove a control works, not just that it exists.
- (j) the use of multi-factor authentication or continuous authentication solutions. Authentication events are the evidence that MFA is actually enforced.
Article 23 adds the clock: an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month of the notification. Producing a reliable timeline in 24 hours is very hard if logs are scattered over dozens of machines with drifting clocks.
Where it gets concrete: Implementing Regulation 2024/2690
The Implementing Regulation details the Article 21 measures for a specific set of digital providers: DNS service providers and TLD registries, cloud computing, data centres, content delivery networks, managed service providers, managed security service providers, online marketplaces, search engines, social networks and trust service providers. For everyone else it is not binding, but it is the most precise public description of what "incident handling" means in practice, and auditors use it as a reference.
Point 3.2 of its annex ("monitoring and logging") asks entities to keep logs that include, where appropriate:
- relevant outbound and inbound network traffic;
- creation, modification or deletion of users and extension of permissions;
- access to systems and applications;
- authentication-related events;
- all privileged access and activities performed by administrative accounts;
- access or changes to critical configuration and backup files;
- event logs and logs from security tools such as antivirus, IDS or firewalls;
- use of system resources and their performance;
- physical access to facilities;
- access to and use of network equipment and devices;
- activation, stopping and pausing of the various logs;
- environmental events.
It also asks for regular review of logs, automated alarms where appropriate, a defined retention period, protection against unauthorised access or modification, synchronised clocks, and monitoring that is reliable and does not depend on the systems it watches.
Mapping requirements to real sources
| Requirement | Typical source | What to collect |
|---|---|---|
| Network traffic | Firewall, VPN concentrator, reverse proxy / WAF | Allowed and denied connections, VPN sessions, admin logins to the firewall |
| User lifecycle and permissions | Active Directory / LDAP, Linux /etc/passwd changes |
Windows events 4720 (user created), 4726 (user deleted), 4728 / 4732 / 4756 (member added to a security group) |
| Authentication | Domain controllers, Linux auth.log / secure, SSH, web apps |
4624 (logon), 4625 (failed logon), 4740 (account locked out), sshd accepted/failed |
| Privileged activity |
sudo, Windows admin groups, hypervisor (ESXi) logs |
sudo commands, admin logins to vCenter/ESXi hosts |
| Critical config and backups | Backup server, config management, storage arrays | Job results, deleted snapshots, config changes |
| Security tools | Antivirus/EDR, IDS, firewall | Detections and policy changes |
| Logging stopped | Windows, rsyslog, agents | Event 1102 (audit log cleared); "source silent for N minutes" alerts |
The last row is the one most setups miss. Requirement 11 is easiest to meet with an alert that fires when a source stops sending.
A minimal self-hosted pipeline
You do not need a large platform to start. The pieces:
1. Time. Same NTP source everywhere, and check drift:
chronyc tracking | grep -E 'System time|Leap status'
2. Forwarding from Linux. With rsyslog, forward everything over TCP to your collector:
# /etc/rsyslog.d/90-forward.conf
*.* @@logs.example.internal:514
Use TLS (omfwd with StreamDriver="gtls") if logs cross untrusted networks.
3. Windows. Enable the advanced audit policy subcategories for logon, account management and security group management, and ship the Security log with an agent or Windows Event Forwarding.
4. Network devices and hypervisors. Firewalls, switches and ESXi hosts all speak syslog; point them at the collector.
5. Detection rules you can explain to an auditor. Start with a handful:
- Brute force: more than N failed logons for one account from one source in M minutes.
- Password spraying: one source failing against many different accounts in a short window.
- Lockouts: any 4740 on a privileged account.
- Out-of-hours admin logins.
- Changes to admin groups (4728/4732/4756 on Domain Admins and equivalents).
- Source silent: no events from a host for longer than its normal interval.
6. Review and tickets. Every alert should land somewhere with an owner, a status and a history. "We review logs" is a claim; a list of reviewed alerts with dates and names is evidence.
7. Retention and integrity. Neither the Directive nor the Regulation fixes a number of days. They ask for a defined period, justified by your risk assessment and other legal obligations. Document it, enforce it, and restrict who can read and delete logs.
Why self-hosting matters here
Logs contain usernames, IP addresses, hostnames and sometimes personal data. Shipping all of that to a third-party cloud brings its own contractual, data-protection and supply-chain questions (supply chain security is itself Article 21(2)(d)). Many public-sector and regulated organisations prefer, or are required, to keep the data on their own infrastructure. A self-hosted collector avoids that discussion entirely, at the cost of operating it yourself.
Checklist
- [ ] List of log sources in scope, and an alert when any of them goes silent
- [ ] Authentication, user lifecycle and admin-group events collected from every domain controller
- [ ] Firewall and VPN logs centralised
- [ ] Common NTP source and drift check
- [ ] Detection rules for brute force, spraying, lockouts, out-of-hours admin activity
- [ ] Alerts tracked as tickets with owner and history
- [ ] Documented retention period and restricted access to logs
- [ ] A tested way to produce an incident timeline within 24 hours
Disclosure: I work on SIEM Compliance, a self-hosted SIEM from NUTRADELIS S.L. (Spain). Its Community edition is free with no limit on servers, agents or log volume, collects logs from firewalls, Windows and Linux servers, ESXi, switches and Cloudflare, and ships with rules like the ones above. Paid plans add an audit module with NIS2 and ENS evidence packs. The original guide covers the same topic with a Spain-specific section.
Sources
- Directive (EU) 2022/2555 (NIS2), Articles 21 and 23, EUR-Lex: https://eur-lex.europa.eu/eli/dir/2022/2555/oj
- Commission Implementing Regulation (EU) 2024/2690, Annex, point 3.2, EUR-Lex: https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Article 21 text (secondary reproduction used for cross-checking): https://luxgap.com/lois/nis2/art-21/?lang=en
- Annex point 3.2.3 list of logged events (secondary reproduction used for cross-checking): https://www.cyberday.ai/requirement/nis2-guide-3-2-3-log-management-and-review
- Microsoft, Windows security audit events reference: https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/security-auditing-overview
- SIEM Compliance, original guide: https://www.siemcompliance.com/recursos/nis2-registro-monitorizacion-eventos/?lang=en
Top comments (2)
One gap worth adding: the same evidence chain now has to cover machine actors, not just people. In my setup every agent action writes a receipt before it is attempted and a result after it finishes, with actor, tool, target and a hash of the input. The receipt is written first on purpose, so an agent that crashes or gets killed still leaves a record of what it was about to do. I borrowed your source silent rule for that: if an agent stops emitting receipts while its session is still marked running, that fires an alert. Silent failure is exactly how an agent gets trusted for hours while it loops or does nothing. Do your detection rules distinguish a human running sudo from an agent invoking the same command?
Some comments may only be visible to logged-in visitors. Sign in to view all comments.