NIS2 Logging Requirements: A Practical Checklist

NIS2 has spent two years as a directive on a slide. In 2026 it becomes something concrete: active supervision, inspections, and — in the Netherlands — the Cyberbeveiligingswet that transposes it into national law. The shift from "we should look at this" to "an auditor is asking" lands hardest on one team: whoever owns logging and monitoring.

The good news is that most of what NIS2 expects from your logs is not exotic. It is the discipline of collecting the right events, keeping them long enough, watching them in real time, and being able to prove all of it. This is a practical checklist of what that means day to day, and how to evidence each item. For the platform-level summary, see our NIS2 compliance page.

What NIS2 actually asks of your logs

NIS2 does not hand you a list of log fields. It sets outcomes: you must be able to detect incidents, respond to them, and report significant ones quickly — an early warning within 24 hours and a fuller notification within 72. Everything in the logging domain exists to make those outcomes possible and provable.

Translated into operational terms, four capabilities have to hold together: you can see events from across your estate in one place, you keep them long enough to investigate and to satisfy an auditor, you spot the bad ones as they happen rather than weeks later, and you can produce evidence on demand. Miss any one of those and the others stop counting.

The checklist

Centralized collection. Logs from servers, network devices, identity providers, cloud services, and critical applications land in one queryable place. Scattered logs on individual hosts are not monitorable and are trivially tampered with.

Adequate, tamper-resistant retention. Events survive long enough to investigate an incident discovered months later and to evidence controls during an audit. The store should be append-only so a logged event cannot be quietly edited away.

Real-time detection mapped to known techniques. Raw collection is not monitoring. You need detections — ideally mapped to a framework like MITRE ATT&CK so coverage is legible — that raise something a human can act on as events arrive.

An incident workflow that can hit the clock. When something fires, you need to triage, confirm, and escalate fast enough to meet the 24- and 72-hour duties, with a record of what was decided and when.

Evidence you can hand to a regulator. Coverage reports, an audit trail of who did what, and the ability to reconstruct an incident timeline. "We had logs somewhere" is not evidence; a report that maps controls to data is.

Access control and an audit trail on the logs themselves. Who can read and change the logging configuration is itself in scope. The monitoring system has to monitor its own use.

Mapping the checklist to a platform

This is the shape LogPulse is built around, which is why the checklist maps cleanly. Collection is centralized into one EU-hosted store; retention is configurable per plan with an append-only audit log; detection ships as 50+ MITRE ATT&CK-tagged rules plus anything you write in LPQL.

On top of that sits the part that actually saves an analyst time during an incident: instead of an alert per rule, every signal contributes to one bounded risk score per entity, and a small number of high-confidence notables are raised, AI-investigated, and worked through an analyst dashboard with notes, evidence, and escalation. Compliance reports then map the detections and data to NIS2 controls. The Security Monitoring (SIEM) page walks through that engine in detail.

What a platform cannot do for you

It is worth being blunt about the boundary, because vendors usually are not. No tool makes you NIS2-compliant. A platform covers the logging, detection, monitoring, and reporting layer and produces evidence. It does not determine whether NIS2 applies to you, write your risk-management policy, run your governance, or train your people. Those are organizational, and they stay yours.

The honest framing is that a good platform removes the technical excuse. Once collection, detection, and reporting are handled, the remaining work is process and governance — which is where it should be, not stuck on "we cannot even see our logs."

Where to start

You do not need a compliance program to begin; you need visibility. Start by centralizing logs from your most critical systems and turning on the built-in detections, then iterate toward the rest of the checklist. The free plan is enough to get logs flowing and see the model work; Security Monitoring and the NIS2 control reports live on the Business plan.

If NIS2 is on your roadmap for 2026, the cheapest move you can make today is to stop logging into silos. Everything else on the checklist gets easier once the data is in one place. Start with the NIS2 compliance overview, or just ship your first logs and build from there.