Key takeaway: a supervisor cannot see your controls. They can only see your evidence. The gap between "we do this" and "here is the artefact, dated, owned, and reviewed" is where almost every finding lives. Preparation is mostly the work of closing that gap, and it is work you can do in four weeks if you start from the governance layer.

The word audit does a lot of work in NIS2 conversations, and it covers several different things. A competent authority carrying out an on-site inspection is not the same as an independent body carrying out a targeted security audit ordered by that authority, which is not the same as a customer sending you a supplier questionnaire because they are in scope and you are in their supply chain. All three ask for similar evidence, which is the useful part: build the pack once and it answers all three.

This article walks through the supervisory powers behind the audit, the structure of an evidence pack that survives contact with a supervisor, a four-week preparation plan, how the day itself tends to run, and the findings that keep repeating across organisations of every size.

What the authority can actually demand

Article 32 sets out the supervisory measures available against essential entities. The list is broad and worth reading in full at least once, because the scope of it surprises people who expect a light-touch regime.

  • On-site inspections and off-site supervision, including random checks, carried out by trained professionals.
  • Regular and targeted security audits carried out by an independent body or by the competent authority itself.
  • Ad hoc audits, justified by a significant incident or by an apparent infringement.
  • Security scans based on objective, non-discriminatory, fair and transparent risk assessment criteria.
  • Requests for information needed to assess the cybersecurity risk-management measures, including documented security policies.
  • Requests to access data, documents and information necessary to carry out supervision, and requests for evidence of implementation of cybersecurity policies, such as the results of security audits and the underlying evidence.

For important entities, Article 33 applies instead. The powers are broadly similar but they are exercised ex post: the authority acts when it has evidence, an indication, or information suggesting that an important entity is not meeting its obligations. That difference matters for planning. An essential entity should assume it will be examined at some point without warning. An important entity should assume that an incident, a complaint, or a peer's supervisory finding is what will trigger the visit.

The cost point people miss: where an authority orders a targeted security audit by an independent body, Article 32(2) states that the costs of that audit are paid by the audited entity, except in duly substantiated cases where the competent authority decides otherwise. Budget for the possibility. An unplanned external audit in the middle of a financial year is a much harder conversation with the board than a planned readiness assessment.

Build the evidence pack in four layers

The mistake most organisations make is assembling evidence control by control, in the order of Article 21(2). That produces a pile of documents in the wrong sequence, because a supervisor does not start at 21(2)(a) and work down. They start with governance, because governance tells them how much to trust everything else. Structure the pack the way it will be read.

Layer 1: governance and accountability

The cybersecurity risk-management policy, with the date and minuted record of approval by the management body. The Article 20 training record per director, with trainer, curriculum, date and attendance. The scope determination and classification decision. The organisational chart showing who owns cybersecurity risk and to whom they report. If this layer is weak, everything below it is read sceptically.

Layer 2: risk and asset foundations

The risk register with named owners, assessment dates, treatment decisions and residual risk accepted at the right level. The service-aligned asset inventory, mapping each essential or important service to the systems and suppliers that support it. Without these two, the remaining measures have nothing to attach to and cannot be shown to be proportionate to actual risk.

Layer 3: the ten Article 21 measures

One folder per measure: risk analysis and information system security policies, incident handling, business continuity including backup management, disaster recovery and crisis management, supply chain security, security in acquisition, development and maintenance including vulnerability handling and disclosure, effectiveness assessment, cyber hygiene and training, cryptography and encryption policy, human resources security and access control and asset management, and multi-factor authentication and secured communications. Each folder holds the policy, the operational artefact that proves the policy runs, and the last review record.

Layer 4: incidents and exercises

The incident register, the classification test used to decide what counts as significant, copies of any Article 23 notifications sent with their timestamps, and the reports from tabletop or live exercises in the last twelve months. This is the layer that shows the programme works under pressure rather than only on paper.

The four weeks before an audit

Assume you get notice. Assume it is short. This is the plan we run with clients, compressed into four working weeks and sequenced so that the highest-value work happens first, in case the notice turns out to be shorter than expected.

Four-week preparation plan

  • Week 1, governance. Locate the board approval minute and the training records. If either is missing, fix it now and date it honestly, because a late artefact with a truthful date beats a backdated one every time.
  • Week 1, inventory sanity check. Pick the two most important services and confirm you can list the supporting systems, business owners and technical owners in under an hour.
  • Week 2, the ten folders. One owner per Article 21 measure, one week, one folder each. Empty folders are information: they tell you where the real gaps are while there is still time to act.
  • Week 2, coverage reports. Pull the MFA enrolment report, the patch compliance figures and the EDR deployment percentage on the same date, so the numbers reconcile with each other.
  • Week 3, restore test and exercise. If there has been no documented restore test or incident exercise in twelve months, run one now and write it up including what went wrong. A candid report is stronger evidence than a flawless one.
  • Week 3, known gaps register. Write down every gap you know about, with an owner, a date and a remediation plan. Declared gaps are managed risk. Discovered gaps are findings.
  • Week 4, dry run. Someone who did not build the pack asks for ten random artefacts and times how long each takes to produce. Anything over ten minutes gets an index entry.
  • Week 4, board briefing. Thirty minutes with the directors on what they will be asked and what the honest answers are. Article 20 questions go to them directly.

How the day tends to run

The pattern is consistent enough to plan for. An opening session on governance and scope, usually with directors present. A walkthrough of the risk-management approach, following one or two real services end to end rather than reviewing the policy in the abstract. Sampling: give me the access review for this system, show me the patch record for that server, produce the notification you sent for the incident in March. Then a closing session summarising observations.

Three behaviours make the day go better. Answer the question asked, not the question you prepared for. When you do not know, say you do not know and commit to a time by which you will provide it, then meet that time. And keep one person logging every request, every document handed over and every commitment made, because the follow-up list is what turns into the formal findings.

Do not volunteer material outside the question. A supervisor asking about backup testing does not need your full disaster recovery strategy and your cloud migration plan. Extra material adds surface area, and every additional artefact is something else that has to be consistent with everything else you have said.

The findings that keep repeating

  • Policy approved by the wrong body. Article 20 requires the management body to approve the risk-management measures. A policy signed off by the IT director alone is a governance finding regardless of how good the policy is.
  • Training that happened but cannot be shown. A session with no attendance list, no trainer credentials and no minute is treated as a session that did not happen.
  • Risk register without residual risk. Registers that list risks and controls but never state what residual exposure was accepted, and by whom, fail the accountability test.
  • MFA with an undocumented exception list. Exceptions are acceptable. Exceptions without a named owner, a compensating control and a review date are not.
  • Backups never restored. A backup job that completes successfully is not evidence of recoverability. A dated restore test with a measured recovery time is.
  • No written classification test for significant incidents. If nobody has agreed in advance what triggers the 24-hour early warning, the decision gets made under pressure by whoever is on call.
  • Supplier register that procurement and security do not share. Two lists with two definitions of critical produce two different answers to the same supervisory question.
  • Effectiveness never assessed. Article 21(2)(f) requires policies and procedures to assess the effectiveness of the measures. Many programmes implement controls and never evaluate whether they work.

What happens after a finding

Article 32(4) gives authorities a graduated set of enforcement powers. Warnings. Binding instructions. Orders to cease conduct that infringes the directive. Orders to bring measures into compliance in a specified manner and within a specified deadline. Orders to implement the recommendations of a security audit. Orders to inform the natural or legal persons affected by a significant threat. The designation of a monitoring officer with defined tasks. Orders to make aspects of an infringement public. And administrative fines.

For essential entities there is a further step in Article 32(5). Where other enforcement measures have proved ineffective, a Member State may temporarily suspend a certification or authorisation concerning the services provided by the entity, and temporarily prohibit a natural person exercising managerial responsibilities at chief executive or legal representative level from exercising those functions. That is the provision boards should understand, because it reaches individuals rather than balance sheets.

The practical reading is that most first contacts end in instructions and deadlines rather than penalties. What escalates a case is not the original gap. It is failing to close it by the date you were given.

Frequently asked questions

Does NIS2 require an external audit?

The directive does not impose a standing certification requirement. It gives competent authorities the power to require targeted security audits carried out by an independent body or by the authority itself, and to require ad hoc audits where justified. So an audit is not automatic, but the power to order one, and to charge the entity for it, exists.

What is the difference between supervision of essential and important entities?

Essential entities are supervised ex ante under Article 32, which allows inspections, random checks, regular and targeted audits, security scans and information requests without any prior indication of a problem. Important entities are supervised ex post under Article 33, meaning the authority acts when it has evidence or an indication that obligations are not being met.

What evidence does a NIS2 auditor ask for first?

In practice the opening requests are governance artefacts: the approved risk-management policy with the date and record of management body approval, the board training record under Article 20, the risk register with named owners, and the incident register. Technical evidence such as MFA coverage and patch metrics follows after the governance layer has been examined.

How far back does a NIS2 audit look?

There is no fixed lookback period in the directive. A practical planning assumption is twelve months, because that is the natural cycle for policy review, board training, restore testing and incident response exercises. Evidence that a control existed only in the fortnight before the audit is treated as weak.

Can a NIS2 audit lead to a fine directly?

It can, but a fine is one option among several. Article 32(4) lists warnings, binding instructions, orders to cease conduct, orders to bring measures into compliance, orders to implement audit recommendations, orders to inform affected recipients, the designation of a monitoring officer, orders to make aspects of the infringement public, and administrative fines. Authorities generally escalate rather than open with the maximum.

Does ISO 27001 certification satisfy a NIS2 audit?

No, but it helps considerably. A certified ISMS covers a large share of the Article 21 measures and gives you an evidence discipline that auditors recognise. The gaps that remain are typically the NIS2-specific ones: the Article 20 management body duties, the Article 23 reporting timelines, and the service-aligned scope, since an ISO scope statement can legitimately exclude systems that NIS2 considers in scope.

Who should be in the room during a NIS2 audit?

A single named lead who owns the conversation, a subject matter expert per Article 21 measure available on call, and one person managing the evidence log. Directors should be available for the governance session, because Article 20 questions are answered by the management body, not by the security team on its behalf.

Related articles