NIS2 Log Management: 5 Changes + 1 Big Challenge

NIS2 requires organizations to implement risk-management measures and report significant incidents within strict deadlines. For years, logs were treated as a purely technical resource: kept to diagnose an outage, understand unusual behavior, track down the cause of an incident, or maintain a history for when something stops working as expected.

This article breaks down what NIS2 now requires of your logs and helps you identify your next steps.

NIS2: Why Are ITOps Teams Directly Affected?

A quick reminder: what NIS2 is

The NIS2 Directive (Directive (EU) 2022/2555) replaces the original 2016 NIS Directive and significantly expands the number of organizations within its scope.

It covers 18 sectors and distinguishes two main categories of organizations by sector and size: essential entities and important entities. NIS2 is estimated to cover around 160,000 organizations across the EU.

One of NIS2’s biggest changes for IT teams is that the directive goes beyond prevention. It also requires the ability to handle and report incidents. In other words, your organization must understand what happened and gather the facts quickly. What helps capture events, date them, and reconstruct an incident’s timeline after initial detection? Logs do.

That’s what log management is all about: collecting and centralizing logs from many different sources, then analyzing them with filters, queries, or dashboards.

Key takeaway: NIS2 gives new weight to a challenge ITOps teams already know well: turning a mass of technical data into actionable information when an incident hits.

Change 1: Know Your Logs, Don’t Just Store Them

Your organization needs to know which logs are available, what information they contain, and how to use them during an incident.

What are your critical log sources, and are you sure you’re collecting them?

You need to identify the systems that contribute to log accumulation, determine where they are stored, and ensure that events an audit would require are logged. Such a mapping will help reveal blind spots: are logs from a critical application escaping your central platform? Is a log from a network device showing too little history? Or are scattered log sources accessible to only a handful of people?

Key takeaway: The goal is no longer to log every component under the sun, but to master the entire logging chain, from the moment a log is generated to the moment it is used.

Change 2: Retention Policy Rather Than Retention Period

This is probably the topic where precision matters most: NIS2 does not set a single log-retention period for every organization.

Under NIS2, log retention must be proportionate to the risk.

Implementing Regulation (EU) 2024/2690, which binds only certain digital service providers (including cloud, data center, CDN, and managed service providers), requires logs to be kept “for a predefined period,” without setting any threshold or duration.

A log retention policy now needs to be formalized and justified. Establishing such a policy requires considering the log type and its criticality.

Key takeaway: The goal is a documented policy that specifies, for each log category, the chosen retention period, the justification, and how logs are securely deleted when that period expires.

Change 3: Logs Must Be Usable and Trustworthy

A log used mainly for quick troubleshooting might be set aside too soon. If that log may help reconstruct an incident, integrity is essential.

A log that can be edited or deleted is not reliable evidence.

It’s not just the information a log provides that counts, but also the full chain of custody. Sensitive logs, in particular, must be protected against unauthorized tampering or deletion. Technical mechanisms such as write-once storage, cryptographic signing, or sealing can help achieve this. Centralization also plays a key role. Storing logs only on the system that generates them creates an obvious weakness: if that system is compromised, its logs can be too.

That’s the approach with Centreon Log Management: logs are centralized, kept separate from the systems that generate them, and stored in write-once (WORM) storage, where they can’t be modified or deleted.

Key takeaway: Log integrity is now a genuine architecture issue for ITOps.

Change 4: Synchronized Timestamps Are Critical

Picture an incident that hits an application, then a database, a server, and a network device, one after another. You have all four logs. All is well until you notice that each system runs on a different clock. You end up with four conflicting time sources that are far harder to correlate. Yet reconstructing an accurate timeline is essential to an effective investigation.

A single, reliable time source is a key element of log quality.

You need to answer one fundamental question with precision: Who did what and when? That question applies foremost to access, authentication, and privileged actions.

Key takeaway: Make sure all your systems are synchronized on a common time source so your log data is reliable.

Change 5: Keeping Logs Out of Prying Eyes

NIS2’s risk-management measures under Article 21 explicitly include access control policies, along with cryptography and encryption. Role-based access control (RBAC), for example, limits log access to the people who need it. Centreon Log Management includes role-based access control and data encryption.

But it needs to go further: access to logs must itself be traceable. Who viewed the data? Who exported it? Who has admin rights?

Beyond your own teams, who can access your logs at your providers?

NIS2 also requires you to assess your providers’ security, including the ones that host your logs. And what matters isn’t just where your data is stored, but which law your provider answers to. The US CLOUD Act, for example, allows authorities to compel a provider under US jurisdiction to hand over data, even when that data is hosted in Europe.

Key takeaway: In practice, an organization must be able to determine who can view, export, or administer its logs, both internally and at its providers.

NIS2’s Biggest Challenge: Timely Information Retrieval

This is probably where NIS2 most directly affects day-to-day operations and your team. For significant incidents, the directive sets several reporting milestones that begin when your organization becomes aware of the incident:

• early warning within 24 hours
• incident notification within 72 hours
• final report within one month of the incident notification

In other words, the clock starts ticking as soon as you become aware of the incident, and it doesn’t stop while your team hunts for the right log files. Centreon Log Management helps with timely retrieval: its log explorer is designed to search and filter data so teams can investigate issues and track down their root causes.

Key takeaway: The real measure of maturity is no longer just the volume of logs you keep, but also how long it takes to get actionable information out of them.

NIS2 Is Not About Making a Legal Project Out of Log Management

Meeting NIS2 requirements doesn’t mean your operations team must become compliance experts, nor does it mean you must build a parallel log management system for audits. Storing certain logs "for compliance" in a system that’s separate from day-to-day operations risks creating yet another silo and could prove counterproductive. The goal is instead to strengthen your existing operational practices.

Key takeaway: The capabilities you need for compliance are the same ones that help ITOps teams improve operational efficiency and potentially reduce their mean time to resolution (MTTR).

Where to Start Preparing Your Log Management for NIS2

Before you look for a new tool, test your current setup. Take a hypothetical incident and ask a deliberately simple question: if this incident happened today, how long would it really take our team to reconstruct what happened?

This question is likely to be far more revealing than simply asking, "Are we keeping our logs?" NIS2 moves organizations from a mindset of possession to a mindset of capability.

Key takeaway: Having the data is no longer enough. You have to be able to use it.

Leverage NIS2 Expectations to Improve Incident Management

Compliance on paper or actual capability?

The opportunity is to look beyond whether your logs are NIS2-compliant and ask whether your log management actually lets you understand and document an incident within the deadlines NIS2 sets.

The difference between those two questions matters. The first can lead to compliance on paper. The second forces you to test your operational reality.

Want to go beyond the principles for a hard look at your current setup?

The Centreon guide NIS2 & DORA: What EU Regulators Now Expect You to Prove From Your Logs breaks down the logging requirements, reporting deadlines, and the sovereignty questions to ask your providers. It also includes a step-by-step action plan and a checklist to assess your readiness.

Download our guide now and identify the priority actions to take your log management to the next level.

Need to rethink your log management? Contact our team for a personalized demo.