NIS2 Enforcement Has Teeth Now: What the First Audits Are Asking For

The transposition phase is over. The inspection phase has started, and the evidence an examiner asks for is not a policy binder — it is operational proof that the policies ran.

For most of the period since NIS2 — Directive (EU) 2022/2555 — fell due for transposition on 17 October 2024, the work inside in-scope firms was documentary. Someone wrote a risk-management policy, someone mapped the ten measures in Article 21(2), the board signed a paper, and the file was closed. That was defensible while nobody was checking. Authorities are now checking, and the gap between having a policy and being able to show it operated is where the first audits are landing. This is a reading of what examiners are actually requesting, written for the people who have to produce it on the day.

Essential and important entities are not audited the same way

The first thing to establish is which supervisory regime applies to you, because it changes when the letter arrives. Article 32 governs essential entities and permits ex ante supervision: authorities can inspect proactively, without waiting for an incident. The measures it lists are concrete — on-site inspections and off-site supervision, regular and targeted security audits by an independent body or the authority, security scans, requests for information to assess the risk-management measures adopted, requests to access data, documents and information, and requests for evidence of implementation of policies, including the results of security audits carried out by a qualified auditor.

Article 33 governs important entities and is ex post: supervision is triggered by evidence, indication or information that the entity is not complying — typically after an incident or a complaint. The practical consequence is that an essential entity should assume it will be asked to prove compliance cold, on a routine timetable, whereas an important entity is more likely to be examined in the worse conditions of an incident already in progress. Either way the artefacts requested are the same. The difference is how much warning you get to assemble them. If you are unsure which category you fall into, that classification question is worth resolving before anything else — it is covered in our reading of NIS2 scope and obligations.

The artefacts an early audit actually names

Strip away the framing and the requests cluster into five groups, each tied to a specific obligation rather than a general expectation of good hygiene.

1. Governance evidence, under Article 20. The management body must have approved the cybersecurity risk-management measures, must oversee their implementation, and can be held liable for infringements. An examiner asks to see the board minute that records the approval — with a date, the version approved, and the discussion, not a one-line ratification. Article 20(2) also requires members of the management body to follow training; the completion records for that training are requested by name. “The board is aware of cyber risk” is not evidence. The dated minute and the training log are.

2. Risk-management evidence, under Article 21. The article requires appropriate and proportionate technical, operational and organisational measures across ten areas: risk-analysis and information-system security policies; incident handling; business continuity, backup and crisis management; supply-chain security; security in acquisition, development and maintenance including vulnerability handling; policies to assess the effectiveness of the measures; basic cyber hygiene and training; cryptography and encryption; human-resources security, access control and asset management; and multi-factor or continuous authentication and secured communications. Examiners do not want a document asserting these exist. They want the artefacts each one produces — the current risk register, the backup restoration test report with a date, the vulnerability-handling records, the asset inventory, the access-control review. Article 21(2)(f) — the duty to assess whether the measures actually work — is the one most firms cannot evidence, because assessing effectiveness produces a report nobody remembered to commission.

3. Incident records, under Article 23. The reporting timeline is unforgiving: an early warning without undue delay and in any event within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, an intermediate update on request, and a final report no later than one month after the notification. An audit asks for the incident log and the submitted reports, and it checks them against the clock. A firm that handled an incident competently but cannot show it hit the 24-hour and 72-hour marks has an evidence problem, not a security one. Where the same incident also engages the Cyber Resilience Act or DORA, the reporting obligations multiply rather than merge — a point we set out in one vulnerability, three reporting clocks.

4. Supply-chain assessment, under Article 21(2)(d). Supply-chain security is a named measure, and it is where the requested evidence is thinnest. Examiners ask for the assessment of your suppliers and service providers — how you evaluated their security, what you concluded, and what the contracts require. A vendor list is not an assessment. The harder-to-classify dependencies — managed service providers, identity providers, code and package registries — are the ones routinely missing from the file.

5. Proof the policies ran, not that they exist. This is the thread through all of the above and the explicit language of Article 32(2): evidence of implementation. The results of a security audit by a qualified auditor, the output of the effectiveness assessment, the restoration test, the access review — dated, attributable, and recent. Documentation states intent. Evidence states operation. The regime is now asking for the second.

Why the binder fails and the checklist wins

The firms that struggle are not the ones without policies. They are the ones whose policies were written to pass a reading and never wired into anything that generates a record. A backup policy with no restoration test report. A supplier-security clause with no assessment behind it. A board approval with no minute. Each is a controls narrative with no evidence of operation, and an inspector who asks for the evidence of implementation — as Article 32 explicitly permits — will find the seam immediately.

The countermeasure is to invert the exercise. Instead of maintaining policies and hoping they satisfy an examiner, build the audit checklist first — the artefacts above, mapped to the article that demands each — and treat any item you cannot produce on demand as an open finding against yourself. This is the same discipline that a first internal audit function imposes, and the tooling question is similar: you need a place where these artefacts are generated, dated and retained as a matter of routine, not reconstructed under pressure. We have written separately on GRC tooling for a first internal audit function, and the same logic applies here.

Proportionality still applies — Article 21(1) scales the depth of the measures to your size, exposure and the likelihood and severity of incidents. A small in-scope entity is not held to the documentation depth of a national telecoms operator. But proportionality reduces the depth of each artefact; it does not remove the artefact. Even the smallest essential entity needs a board approval with a date, an incident log that meets the clock, and a supplier assessment that exists.

The enforcement backstop is real: Article 34 sets maximum administrative fines for essential entities at at least €10 million or 2% of total worldwide annual turnover, whichever is higher, and at least €7 million or 1.4% for important entities. That is the number that concentrates a board’s attention, and it is why the drift from documentary to operational supervision matters. We traced the early signals of that shift in NIS2 enforcement waking up; the audits now underway are the shift arriving.

Assemble the evidence against the article that demands it before the letter arrives, because the one thing an inspector will not accept is a promise that the policy would have worked.