What early NIS2 enforcement tells us about audit trails

Most compliance mandates start as a checkbox exercise. Someone confirms logging is on, ticks the box, and the team moves on. But NIS2 is changing that. Regulators are now going after proof of your controls. They’re asking whether you can reconstruct what happened and whether anyone should trust your record. Because if you can’t show who did what and when, those controls may as well not exist.

Regulators want evidence

Fine amounts are hard to pin down. The figures floating around online vary by source, and the EU has yet to create a central register of fines. The recent pattern of enforcement, however, tells us more.

Germany's BSI has issued dozens of formal notices. France's ANSSI has issued orders to fix problems in energy and transport, preferring remediation to penalties. In the Netherlands, a review of essential digital infrastructure companies found that more than a third had weak incident-reporting procedures and more than half had no management-approved security policy on file.

Every one of these findings comes down to missing proof.

Where the real requirements live

Most coverage stops at Article 21, the part of NIS2 that lists ten broad security measures. But that article is intentionally general. The detail you need sits in Commission Implementing Regulation (EU) 2024/2690, in force since November 2024. It turns those ten measures into more than 150 specific controls. Logging and monitoring, the controls behind your audit trail, are covered in Annex Section 3.2.

The regulation applies directly to a defined group of companies, including cloud and data center providers, DNS providers, managed service providers, and online marketplaces. Companies outside that list aren't formally bound, yet it's still the yardstick a regulator is most likely to use. (Our NIS2 compliance overview walks through the criteria for whether NIS2 applies to you.)

The rules often say things like "where appropriate" or "to the extent feasible," which sounds like wiggle room. But there’s a catch: if you decide a requirement doesn't apply to you, you have to write down why. Choosing to skip logging on a system is fine when you’ve documented the reasoning. Otherwise, it's a finding.

The proof often disappears before anyone looks

Windows security logs on domain controllers overwrite themselves by design. Once a log hits a size limit, the oldest events make way for new ones. That limit, likely set by someone years ago to save disk space, doesn’t take evidence into account. On a busy server, the log can turn over in minutes.

But because logging is on and new records keep arriving, nobody notices the loss. When a regulator asks about something that happened four months ago, telling them "logging was on" won’t help.

Two quick things you can do:

• Check how long your domain controllers and critical servers keep logs today. The real setting matters more than the policy document.
• Find out how much of your required evidence window your audit platform can search directly. Recent data is usually fast to search, while older data sits in an archive that may need a restore. Test that retrieval now. Article 23 of NIS2 gives you 24 hours for an early warning. That's a bad moment to learn that digging up six-month-old activity takes days.

Logs an admin can edit aren't evidence

NIS2 expects you to protect your logs from unauthorized access and changes.

Think about who you'd be investigating: usually, it's an account with admin rights. If your audit data lives on systems that account controls, one of its first moves can be clearing the logs. And while Windows records that a log was cleared, it writes that entry into the very log that was just wiped. You learn that history was erased, but not what it held.

This is why "how long do we keep it?" is the wrong first question. A seven-year archive that an admin can edit is weaker than a six-month archive they can't touch. A record you can trust needs three things:

1. A system outside the monitored environment collects and stores the data.
2. The people who run those systems can't change the stored history.
3. The audit store records every change made to it.

It’s the second one companies fail the most. The account that collects audit data is often a domain admin because it was easiest to set up. So an attacker who takes over an admin login also reaches the evidence. Check who has write access to your audit database and archive today.

The third requirement is the easiest to overlook. Your platform should tell you when audit logs were cleared, when audit settings changed, and who has looked at the store. If it can't, your evidence has no evidence behind it.

Six tests to run before a regulator does

Block two hours, grab a stopwatch, and try to produce proof for each of these in your real environment:

1. A privileged account is compromised. Can you see everything it did, across every system, in order?
2. Someone gets permissions they shouldn't have. Can you tell who granted them and when, even through nested groups?
3. A critical setting changes. Can you show what it was before and what it is now?
4. A suspicious account appears. Can you tell who created it and what it did next?
5. An incident touches several systems. Can you build one clear timeline fast enough to support Article 23's 24-hour early warning?
6. Someone cleared a security log last Tuesday. Would you know, and could you show how you know?

Score yourself and note the date range you test. Teams often pass for last week but fail for last quarter. That difference is what this exercise shows you. And "yes, but it took three days and five teams" is a fail. The 24-hour clock doesn't care how many people you needed.

Where Netwrix Auditor fits

All six tests come down to one capability: a trustworthy history of who changed what, when, and what it was before, stored somewhere the monitored environment can't quietly rewrite it.

Netwrix Auditor gathers change, access, and admin activity from Active Directory, Entra ID, Microsoft 365, file servers, SQL Server, and more into its own audit store. Your history no longer depends on how long a domain controller holds onto its logs.

There's also a NIS2 report pack that lines up closely with the six tests. For example, Administrative Group Membership Changes cover test 1, and Account Permissions Reports cover test 2. Audit Log Clearing and Local Audit Policy Changes cover test 6, and Access to Archive Data shows who has been reading the evidence itself. A NIS2 requirements mapping guide helps you show a regulator the line from each requirement to a report.

No auditing tool makes you NIS2 compliant by itself. Article 21 covers far more than monitoring, but every one of its measures eventually has to be proven, and proof comes from audit evidence. Without it, a working control and a missing one look the same to a regulator.

The takeaway

Early enforcement is a signal of where European regulators are headed. Compliance is shifting from what your policy says to what you can show.

So run the six tests, and aim them at a date four months back. If any fail, make fixing them this week's priority, before a regulator makes that same fix more expensive.