NIS2 Compliance: Why Fleet-Level Evidence Is the Missing Layer

NIS2 asks for technical risk-management measures backed by evidence. Most organizations can show the policy, but not the state of their fleet on a given day. Here's the gap, and where LEA Platform fits.

The NIS2 Directive (EU Directive 2022/2555) places a clear obligation on "essential" and "important" entities: implement appropriate technical, operational and organizational risk-management measures under Article 21, and meet the incident reporting timelines in Article 23: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month.

Many organizations treat this as a paperwork exercise. They draft policies, update their governance frameworks and tick the boxes. But the weak point usually isn't the policy. It's the proof. When an auditor, regulator or insurer asks whether access controls, cryptography settings and update policies were actually in place on every host during an incident window, most teams can't answer with confidence. They have policies. They don't have evidence.

That is the distinction NIS2 brings into the open: compliance is not the existence of a control document. It is controls that are applied, checked and recorded across every endpoint in the fleet.

The gap between policy and proof

Article 21(2) lists ten areas of risk-management measures:

• (a) policies on risk analysis and information system security
• (b) incident handling
• (c) business continuity, including backup management, disaster recovery and crisis management
• (d) supply chain security
• (e) security in network and information system acquisition, development and maintenance, including vulnerability handling and disclosure
• (f) policies and procedures to assess the effectiveness of cybersecurity risk-management measures
• (g) basic cyber hygiene practices and cybersecurity training
• (h) policies and procedures on cryptography and, where appropriate, encryption
• (i) human resources security, access control policies and asset management
• (j) multi-factor or continuous authentication and secured communications

The language is deliberately broad. It has to be: it applies to everything from energy grids to cloud providers. But broad language creates an illusion that having a policy for each area is enough. In practice, auditors and national authorities increasingly look past intent. They want evidence that measures were operating and effective over time.

The reconstruction problem

If a breach happens on March 15 and your last compliance scan ran on February 28, you can't reconstruct the actual security posture of the fleet during the incident window. You can only infer it. Inference is not evidence, and NIS2's reporting timelines leave little room for "probably compliant."

Periodic scans, quarterly audits and annual penetration tests share the same weakness: they are point-in-time snapshots of a moving target. The gap between snapshots is where drift happens, where incidents occur, and where compliance quietly erodes.

How LEA helps close the gap

LEA is built for one part of this problem: checking configuration across a mixed Linux, macOS and Windows fleet on a regular cycle, and keeping signed evidence of the results. Here is how that maps to NIS2.

1. Configuration checks on every cycle

LEA agents run read-only checks on each host on a per-rule cycle (for example, hourly) and send the raw output to the LEA server. The server decides pass or fail, so a host can't grade its own homework. The shipped rules cover areas such as authentication and password policy, access control, SSH and cryptography settings, audit logging, kernel and network hardening. When a setting drifts out of policy, it shows up as a failure on the next check cycle. Where a rule defines an opt-in remedy, LEA can put the setting back and re-check it, with both steps recorded.

2. Signed compliance evidence

LEA takes scheduled evidence snapshots (every 24 hours by default). Each evidence record is signed with HMAC-SHA256, so any later change to a record can be detected. Results, remedies and admin actions are kept as history. When an auditor asks what the fleet looked like during a specific week, you can show signed snapshots and the result history, not screenshots.

3. Evidence mapped to common frameworks

Evidence snapshots are organized by framework: CIS Controls, ISO 27001, SOC 2 and CMMC. Shipped rules also carry NIST SP 800-53 and PCI DSS tags. LEA does not ship a dedicated NIS2 mapping. Many organizations use ISO 27001 as the basis for their NIS2 measures, so the same configuration evidence can support both, with your own mapping from controls to Article 21(2) areas.

4. Update policy checks

Article 21(2)(e) covers vulnerability handling. LEA is not a vulnerability scanner and does not install patches. It can check that update policy is in place on each host, for example that automatic operating system updates are enabled, and you can write rules for other update-related settings you care about. Failures show up as drift on the next check cycle.

5. Package inventory

Article 21(2)(d) and (i) touch on supply chain security and asset management. A shipped inventory rule collects a snapshot of installed packages on Linux and Windows hosts on a regular cycle. That data supports asset inventories and supply chain reviews, and can be exported for correlation in your own vulnerability tooling. LEA itself does not match packages against CVE databases.

NIS2 scope, and where LEA fits

NIS2 spans risk management, management accountability, incident reporting and business continuity. It matters to be precise about where a tool fits, because mapping the wrong tool to the wrong obligation creates false confidence.

LEA works within the technical part of Article 21(2): configuration checks and evidence for areas such as cyber hygiene (g), cryptography settings (h), access control and asset inventory (i), and update policy as part of vulnerability handling (e). These are technical, measurable obligations that can be checked on a cycle.

Management body accountability under Article 20 (oversight, training, approval of measures) is an organizational obligation. It needs governance structures and documented decisions. LEA does not run your board meetings. Incident reporting under Article 23 (the 24-hour, 72-hour and one-month notifications) is a procedural obligation that needs communication channels, legal review and coordination with your national CSIRT or competent authority. LEA does not file those reports.

What LEA does is supply evidence that feeds into those processes. When management needs to show that technical controls were in place, LEA provides the record. When incident responders need to reconstruct fleet state during a breach window, LEA has signed, timestamped snapshots and result history. When legal and GRC teams need documentation, LEA produces PDF stakeholder reports (including GRC Legal and External Auditor views) and CSV/JSON exports. LEA is part of the technical foundation, not the whole building.

LEA Platform produces evidence; certification is granted only by an accredited auditor.

Key takeaways

• NIS2 asks for measures that are in place and effective, not just documented policies.
• Periodic scans can't reconstruct fleet state during an incident window.
• LEA checks Article 21(2)-relevant configuration on Linux, macOS and Windows on every check cycle, and judges results on the server.
• Evidence records are HMAC-SHA256 signed, so later changes can be detected.
• Evidence is organized by CIS Controls, ISO 27001, SOC 2 and CMMC; your NIS2 mapping builds on it.
• LEA supplies technical evidence. Management accountability and incident reporting remain organizational obligations.

Closing thoughts

NIS2 is not a checkbox. It is a structural shift in how the EU expects essential and important entities to manage and demonstrate cybersecurity. Its strength is also its challenge: it asks for evidence that measures work over time, not snapshots of good intentions.

Most organizations already have the policies. What they lack is the layer beneath the policy: regular, automated checks that show controls were in place on every host, every day, including the day something went wrong. That's the layer LEA provides.