How to Prove NIS2 Compliance in an Audit: The Technical Evidence That Really Counts

Policies and documents are not enough

NIS2 has a bad reputation as a bureaucratic exercise. The idea that to be compliant it is enough to produce a set of policies, a theoretical risk assessment and a few responsibility org charts is widespread among Italian SMEs, and it often stems from how IT compliance is traditionally handled.

But NIS2 audits in OT environments work differently. An experienced technical auditor is not satisfied with seeing a document that describes how OT assets are managed in theory: they ask to see the asset list updated last week. They are not satisfied with a vulnerability management policy: they ask to see the latest vulnerability assessment reports and the documented patching decisions. They are not satisfied with an incident response plan: they ask to see the logs of the alerts handled over the past few months.

This distinction between documents of intent and technical evidence is fundamental to understanding what it really takes to pass a NIS2 audit in an OT environment.

The four categories of technical evidence

1. An up-to-date asset inventory

A NIS2 OT audit almost always starts with a direct question: "Show me the list of your OT assets". The expected answer is not an Excel file drafted six months ago and updated by hand during maintenance windows. It is an inventory that demonstrates it is actively maintained, with recent update dates and a defined process to keep it accurate.

The minimum information an OT inventory must contain to be useful in an audit:

• Unique identifier and device name
• Type (PLC, HMI, RTU, SCADA server, historian, field device)
• Manufacturer and model
• Current firmware/software version
• IP address or network identifier
• Network zone it belongs to
• Operational criticality (what happens if this device goes offline?)
• Status of known vulnerabilities (relevant CVEs identified)

An inventory that lacks recent entries, that contains devices last updated years ago, or that does not include field devices (only SCADA servers, for example) is a negative signal for the auditor.

The most common follow-up question: "How is this inventory updated when a new device is added?" If the answer is "manually, when we remember", the robustness of the process is clearly low.

2. Evidence of periodic vulnerability assessment

NIS2 requires vulnerability management processes. In an audit, this translates into the ability to demonstrate that vulnerability assessment is carried out with a certain regularity, that the results are documented, and that the vulnerabilities identified are managed through a traceable process.

The evidence typically requested:

• The report of the latest vulnerability assessment (date, scope, methodology)
• A list of the vulnerabilities identified with their status (patched, accepted, with a compensating control)
• A decision register: for each open vulnerability, documentation of the decision taken and its rationale
• Evidence that OT vulnerability intelligence sources are being monitored (CISA ICS-CERT advisories, vendor bulletins)

An element often missing in SMEs: documentation of the decisions not to apply a patch. "We decided not to update the PLC firmware because the update would require an 8-hour line shutdown and we implemented X as a compensating control" is a defensible position in an audit. "We did not update because we did not think about it" is not.

The acceptable frequency depends on the criticality of the environment. For critical OT systems, an annual vulnerability assessment is a minimum. For high-criticality assets with known, actively exploited vulnerabilities, a higher frequency may be required.

3. Detection logs and alert handling

The ability to detect compromises is implicit in the NIS2 requirements but often underestimated. If a significant incident must be notified within 24 hours, it means the organization must be able to detect it within a much shorter timeframe. This presupposes the existence of a monitoring system and an alert handling process.

The evidence an auditor looks for in this category:

• Proof that an OT network monitoring system exists (not necessarily sophisticated, but present and working)
• Alert logs from the past few months, with evidence that they are reviewed and handled
• Documentation of alert triage: every alert must be marked "reviewed" with an indication of the outcome (false positive with rationale, real incident handled, situation to monitor)
• An escalation process: who receives the alerts, who decides whether it is an incident, who notifies management

An organization that has no OT traffic logging is in a very weak position in a NIS2 audit. The question "how do you know whether you have suffered an incident?" has no satisfactory answer if there is no monitoring system.

A point often overlooked: log retention. Logs must be kept for a period long enough to support a potential forensic investigation. Six months is a reasonable minimum; one year is better. Logs that are overwritten every week are not evidence.

4. Documented and tested incident notification procedures

NIS2 sets precise deadlines for the notification of significant incidents: 24 hours for the early warning, 72 hours for the full initial notification, 30 days for the final report. Meeting these deadlines without a ready procedure is practically impossible while managing a real incident.

The evidence required in this area:

• A written incident notification procedure, with a clear workflow and assigned responsibilities
• An operational definition of "significant incident" applicable to the specific context
• Up-to-date contacts for the national authority (ACN) and procedures for accessing the notification portal
• Evidence that the procedure has been exercised (tabletop exercise, simulation)
• A register of past incidents, including those not significant for NIS2 purposes, as proof that the detection and handling process is active

The last piece of evidence is often the hardest for SMEs that have never formalized the process to produce: an empty register ("we have never had incidents") is plausible for an organization with robust monitoring, but it is suspicious for one that has no monitoring and has never found anything.

Continuous OT monitoring as a source of evidence

One of the challenges of NIS2 audits is that the required evidence must be built up over time. You cannot produce six months of monitoring logs the week before an audit: the logs must already exist, correctly dated and tamper-proof.

This creates a structural advantage for organizations that have implemented continuous OT monitoring: the system automatically generates evidence with date and time in a non-modifiable way. The monitoring reports become audit documentation with no extra work.

In concrete terms, a well-configured OT monitoring system produces:

• Periodic reports of the inventory of detected assets, with timestamps
• Logs of all generated alerts with date, time, description and handling status
• Evidence of the anomalous communications detected and the actions taken
• Reports on the vulnerabilities identified on the monitored assets
• A history of changes in the asset inventory (new devices appearing, devices removed)

This kind of automatic documentation directly answers the most frequent requests from NIS2 auditors, and it does so with evidence that has intrinsic credibility: it is produced by a technical system on a continuous basis, not drafted by hand ahead of the audit.

How to structure the evidence package for an audit

A practical approach is to build an "audit package" that can be presented quickly when requested. It does not have to be a stack of paper: it can be an organized folder of files, updated periodically.

The minimum package for a NIS2 OT audit includes:

1. OT asset inventory (recent, documented update)
2. The latest vulnerability assessment report, with a decision register on the findings
3. An OT security policy approved by management (with approval and review dates)
4. An incident response and NIS2 notification procedure (with evidence of at least one exercise)
5. Alert logs from the past 90 to 180 days, with documented triage
6. A list of vendors with remote access to OT systems and the related controls in place
7. Backup configurations and an OT disaster recovery plan

Preparing this package is not a one-off activity: it requires the underlying processes to be active and the evidence to accumulate over time. The audit, in this sense, is not the final goal but the verification that the security processes work as declared.

---

The difference between those who pass a NIS2 audit and those who do not lies not in the ability to write policies: it lies in having active technical processes that produce verifiable evidence. This requires investment in tools and processes before the audit, not during it.

The MON5 angle

The evidence that holds up in a NIS2 audit, as we have seen, accumulates over time: it cannot be improvised the week before. MON5 produces it as a byproduct of normal operation: the continuous asset inventory of the ANALYZE phase answers the request "show me the updated list", while the monitoring of the PROTECT phase generates dated logs of alerts, new devices and remote access.

The integrated NIS2 compliance support links this data to the requirements of the directive, reducing the work of preparing the audit package. To capture today how far you are from the requirements, an OT assessment is the fastest way.

Analysis and commentary by MON5 based on public-domain research and data from the OT/ICS sector.