Article 32 NIS2 supervision of essential entities

What NIS2 Article 32 means for essential entities

If your organization is classified as an essential entity, a national competent authority can inspect you without first having any sign that something has gone wrong. Under Article 32(2), supervision of essential entities is ex ante: the authority can run on-site and off-site inspections, including random checks, order regular and targeted security audits, commission ad hoc audits, and perform security scans. The starting assumption is that your risk-management measures under Article 21 must already be in place and provable on any given day. That is the central difference from important entities, which are supervised ex post and generally only when there is evidence of non-compliance under Article 33(1).

The regime exists because the authority wants to find weaknesses before an incident exposes them, and it expects you to be able to show how your controls work at that moment. In practice, the authority can request documented cybersecurity policies, access to data and documents, and evidence of implementation, including the results of security audits by a qualified auditor together with the underlying evidence (Article 32(2)(e) to (g)). Before you hand anything over, check that the authority has stated the purpose of its request and the information it wants, as Article 32(3) requires. Confirm who in your organization is authorized to receive and respond to these requests, and where the supporting records are held.

Readiness is hard because NIS2 creates no certificate of compliance that you can present to an inspector as a standing answer. Each authority will judge your evidence against the national transposition law and, where it applies, Implementing Regulation (EU) 2024/2690. Plan for three things. First, decide who pays for targeted audits by an independent body, since Article 32(2) places that cost on the audited entity unless the authority decides otherwise in duly substantiated cases. Second, make sure audit results and their underlying evidence can be produced quickly and reflect current operations. Third, confirm with your national authority which audit formats and evidence it accepts, because that detail is set nationally rather than in the Directive itself.

Which essential entities and systems fall under Article 32 supervision

Article 32 supervision applies only once an entity is classed as essential, and the scope of what an authority can ask for then depends on the systems, data and suppliers behind the services in scope. The cards below cover the decisions that shape the evidence an authority may request, and the points where the national transposition law sets the details.

Essential classification under Article 3

Article 3 sorts in-scope entities into essential and important. Essential status brings ex ante supervision, meaning an authority can inspect and audit without first finding a problem. Confirm which Annex I sector and entity type applies, whether the organization exceeds the size threshold for its sector, and whether a sector-specific law displaces NIS2 for part of its activities. Record the classification decision and its basis, since the authority will start there.

Systems and services in scope

Supervisors can ask about the risk-management measures that protect network and information systems used to provide the entity's services. Map which services, networks, identity systems, backups and operational technology feed those services, and mark which are outside the perimeter. An undocumented boundary is hard to defend in an inspection, so the scope statement should be written, approved and kept current.

Data and documents an authority can request

Authorities may request documented cybersecurity policies, access to data and documents, and evidence that measures are implemented. Build an index of where each policy, asset register, risk assessment and access log lives, and who can produce it. Confirm with the national authority how it wants data handled, and which requests it considers within purpose, since requests must state their purpose and specify the information sought.

Managed service providers and their evidence

When a managed service provider runs part of the security or network estate, the entity still answers for those systems in an inspection. Check contracts for audit rights, log access, incident notification and the right to receive the provider's audit results. Ask the provider which evidence it can produce, and whether it will support a targeted audit. Gaps in these clauses become gaps in the entity's own evidence.

Cloud and hosting dependencies

Cloud and hosting providers hold configuration, logs and sometimes data that an authority may ask to see. Identify which controls the entity runs in its own accounts and which the provider operates, and obtain the provider's independent audit reports and shared responsibility documentation. Where the entity self-hosts platforms in its own cloud accounts or data centers, the evidence sits within its control, which simplifies production but raises the burden of keeping it complete.

Transposition law sets authority and details

NIS2 is a directive, so the Member State's transposition law designates the competent authority, the form of inspections and audits, and the procedures for requests. Entities operating in several Member States may face more than one authority. Confirm with the designated authority which audit body it accepts, how targeted audit results must be delivered, and what the audited entity pays for, because these points vary by country.

How to prepare for an inspection or audit request

This sequence gives an essential entity a defensible position before a competent authority inspects, scans or audits it. It ends with an evidence index, a tested internal review and a documented process for answering information requests that state their purpose.

Confirm classification and the competent authority
Legal or compliance leads confirm, with counsel, that the organization is an essential entity under Article 3 and identify the Member State whose national law applies, including the competent authority that will supervise it. Confirm whether any sector-specific law displaces NIS2 for part of the business and whether the group operates in several Member States. The output is a signed classification memo naming the authority, the national transposition law and the contact route for requests. Check the memo against the national implementing law, since its details come from the Member State.
Map the scope of systems and services
Platform, security and compliance owners list the network and information systems, services and suppliers that support the entity's in-scope activities. Each system gets an owner, a business purpose and a link to its risk assessment. The output is a scope register that an inspector can read without help from the team. Keep it current, because an authority that finds systems missing from the register will question the rest of the evidence.
Build the evidence index for policies and Article 21 measures
The compliance lead creates an index that maps each Article 21 measure to the documented policy, procedure, technical configuration, log or record that shows it operates. Policies are approved by the management body, versioned and dated, and each index entry points to where the evidence sits. Open-source platforms such as CISO Assistant can hold the framework mapping and assessment records, while a wiki with version history can hold the policy text. The output is an index that a reviewer can use to find any requested document within a short search.
Collect and verify technical evidence
Security engineers pull current evidence for each control in the index, such as access reviews, patch records, backup restore tests, log samples and configuration baselines. Each item is checked for date, scope and author, and gaps are logged with an owner. The output is an evidence pack per control with a status of complete, partial or missing. Confirm that evidence reflects actual operation, not only design, because authorities can request the underlying records.
Run an internal review against the requirements
An internal reviewer who did not build the controls tests the index and evidence packs against the Article 21 measures and the requirements of Implementing Regulation (EU) 2024/2690 where they apply. The reviewer may use ENISA's non-binding technical guidance to check examples of evidence. Findings are recorded with severity, owner and a remediation plan approved by the management body. The output is a signed internal review report and a tracked remediation list. The report should be kept as evidence that the entity checks itself.
Decide when independent audit support is needed
Leadership decides whether an independent body should carry out a regular or targeted security audit before any authority asks. Where the entity asks an external firm to prepare or test evidence, the engagement is scoped in writing so that the organization keeps ownership of its controls. Ask any provider to confirm that it does not issue audit reports or certifications unless it is an independent auditor or certification body. The output is a written decision with scope, owner and the audit results routed to the authority when required.
Set up the process for information requests
The incident or compliance lead creates a request log and a standard procedure for handling requests from the authority. Each request is checked for the stated purpose and the specific information requested, as Article 32(3) requires, and clarification is sought if either is missing. Responses are reviewed by legal counsel, assigned to an owner and recorded with the evidence supplied. The output is a tested request procedure, a named contact and a log that shows every response and its basis. Run a tabletop exercise to confirm the team can answer within the timelines set by the national authority.
Rehearse an inspection and keep the file current
The compliance lead runs a mock inspection in which a team member who was not involved selects random controls and requests evidence, while staff practice locating records and explaining them. Gaps found in the rehearsal are fixed and the index is updated with dates and version numbers. The output is a rehearsal record and a refreshed evidence index with a named owner for each control. Repeat the rehearsal after major system or supplier changes so the file stays accurate.

How an authority tests essential entities under Article 32

This table maps each Article 32(2) supervisory power to how an authority tests it, the evidence it asks for and the findings that most often come up. Read it as a preparation guide: each row shows what the entity should be able to produce before an inspection or audit starts.

Supervisory power	How the authority tests it	Evidence requested and common findings
On-site inspections and off-site supervision	Inspectors visit premises or review systems remotely to check that controls operate as described, not only that they are documented.	Evidence: live system configurations, access lists, logs. Common finding: policies exist on paper but are not implemented in daily operations.
Random checks	Checks happen without prior indication of an infringement, so the entity must be inspection-ready at all times.	Evidence: current asset inventory, up-to-date risk register. Common finding: documentation last reviewed long before the check date.
Regular security audits by an independent body or the authority	The audit tests the Article 21 measures against the entity's own risk assessment and scope.	Evidence: prior audit reports, remediation tracking. Common finding: audit reports without the underlying sampling evidence behind them.
Targeted security audits	Based on risk assessments by the authority or the entity, focusing on the areas judged most exposed.	Evidence: the entity's risk assessment and treatment plan. Common finding: risk assessment not linked to actual control selection.
Ad hoc audits	Triggered by a significant incident or a specific concern, with a narrower and faster scope.	Evidence: incident records, post-incident reviews, changes made since the incident. Common finding: lessons learned not reflected in updated controls.
Security scans	Authority-run or independent vulnerability and configuration scans against defined objective criteria.	Evidence: patch records, vulnerability management timelines. Common finding: unpatched or exposed services found that the entity had not logged as risks.
Information requests and documented policies	Authority asks for cybersecurity policies and states the purpose and the specific information requested.	Evidence: approved policies, version history, management approval records. Common finding: policies missing management body approval or not updated after changes.
Access to data, documents and evidence of implementation	Authority reviews underlying records and sample results to confirm that stated measures are in place.	Evidence: audit results with the underlying evidence, training records, access reviews. Common finding: summaries provided without the supporting records.

Evidence that passes a supervisory request

Article 32 gives national authorities the power to ask essential entities for documented policies, risk records, audit results and scan evidence, often without a prior incident. The cards below cover the artifacts that answer those requests and the routines that keep them current between requests.

Documented cybersecurity policies

Authorities can ask for the documented cybersecurity policies that set out how the entity manages risk to its network and information systems. Each policy should name an owner, a review date and the management body approval that governs it. Check that every policy matches what staff actually do in the systems, because an inspector will compare the text with configurations, tickets and logs. Keep a version history so you can show which text applied on any past date. A wiki with change tracking, such as XWiki, can hold this record, and you should confirm that its history export meets your retention needs.

Risk assessment records

A risk assessment record shows the assets, threats, vulnerabilities and treatment decisions behind the risk-management measures. Authorities use it to judge whether controls were chosen for real exposures. Record who approved each risk, the date of the last review and the link from each risk to its treatment, such as a control, a project or an accepted residual risk. Stale registers are a common finding, so tie each review to a trigger such as a new system, a major incident or a change in the entity's sector exposure.

Independent audit results with underlying evidence

Article 32 expects evidence such as the results of security audits carried out by a qualified auditor, and the authority can ask for the underlying evidence too. Keep the full audit report, the scope and sampling notes, the auditor's working papers where you hold them, and your written response to each finding. Confirm with the auditor which materials they will release to you and which they retain, since that determines what you can hand to an authority. Agree the audit scope in writing so the report can be tied to a specific set of systems and a date.

Scan reports and remediation tracking

Security scans are one of the supervisory tools named in Article 32, so authorities may ask for recent scan output and proof of what happened next. Keep each scan report with its date, tool, asset list and configuration, then track every finding in a ticket with an owner, a target date and a closure note. Show that critical and high findings were re-tested after the fix. Ask your scanning vendor or open-source tool maintainers how their reports are exported, and confirm that exports remain readable after the tool is upgraded.

Current operating procedures and runbooks

Authorities test whether policies work in practice, so they look for operating procedures that show how controls run day to day. Examples include access review steps, change approval, backup restoration tests and vulnerability triage. Each runbook should carry a version number, an owner and a last-tested date. Procedures written for a past architecture are a frequent source of findings, so compare each runbook against the current systems at every quarterly review and record the outcome.

Request log and purpose-bound responses

Article 32 requires an authority to state the purpose of a request and specify the information it wants, so your team should check each request against that statement before answering. Keep a log that records the request date, the stated purpose, the items provided, the people who approved the response and the date sent. Provide only what the request covers, and note in writing where a request is unclear or exceeds its stated purpose. This record shows that responses stayed within scope and were timely.

Who pays for targeted audits and what drives the bill

Under Article 32(2), when a targeted security audit of an essential entity is carried out by an independent body, the audited entity pays for it, unless the competent authority decides otherwise in duly substantiated cases. The rule matters because the audit is triggered by the authority's risk assessment or the entity's own, and the bill lands on the entity even though the authority chooses the scope and receives the results. Treat the payment rule as the default you plan for, and ask your national competent authority in writing whether it has adopted any exception that would shift the cost. Also confirm who selects the independent body, since the entity should know whether it can propose candidates or must accept one assigned to it.

The invoice from an independent auditor is only one line of the total. Recurring and one-time costs fall into several buckets: internal staff time to gather documents, answer questions and sit in interviews; the cost of keeping evidence current, such as policy reviews, access review records and training logs; scan tooling or vendor-run scans where the authority orders a security scan; and remediation of any findings, which is often the largest and least predictable item. Costs rise with the number of systems in scope, the age and state of the documentation, the number of sites, and how many findings must be re-tested. Evidence that is already produced continuously, such as versioned policies and logged configuration changes, lowers both the audit hours and the remediation spend.

When you request a quote for a targeted audit, ask the auditor to state the scope in writing, the systems and sites sampled, the number of auditor days, the assumptions about your evidence, how re-testing of findings is priced, and whether travel is included. Ask your implementation partner to separate preparation work, such as building the evidence pack, from the audit itself, since only the independent body issues the audit result. Budget for at least one retest cycle, and confirm with your authority which audit results must be shared and in what format, because a poorly scoped quote can leave the audited entity paying twice for the same ground.

What readiness for Article 32 costs in money and effort

This table lists the cost components of getting ready for ex ante supervision under Article 32, who is paid for each one, whether it is one-time or recurring, and what moves it up or down. Use it to frame a quote request, because the largest variables are the scope of systems in view and how much evidence the organization must produce on demand. No fee or duration is stated here because none has been researched for this topic.

Cost component	Who is paid or who carries the cost	One-time or recurring	What drives it up or down
Tooling and licenses	Software vendors or subscription providers, or none for self-hosted open-source tools	Mostly recurring for commercial licenses; one-time for installation	Number of users and systems in scope; self-hosted open-source options can remove per-seat license spend but still need hosting and staff time
Engineering and administration time	Internal staff, or an implementation partner under a fixed-scope written agreement	One-time for build-out, recurring for operation	Number of systems to document, age of current tooling, and how many evidence sources must be integrated
Evidence upkeep	Internal compliance and security staff who keep policies, asset inventories and audit results current	Recurring	Frequency of change in the environment, and whether evidence is collected automatically or assembled by hand when a supervisor asks
Security scans and testing	External testing providers or internal teams, depending on the scan type and the authority's request	Recurring, with one-time baselines	Scope of applications and infrastructure, and whether scans are scheduled or triggered only by an ad hoc request
Independent security audits	The audited entity pays for audits by an independent body, unless the authority decides otherwise in duly substantiated cases (Article 32(2))	Recurring for regular audits; ad hoc when the authority requests one	Whether the authority or the entity sets the targeted audit scope, and the number of systems and sites covered
Remediation of findings	Internal teams or contracted engineers, plus any vendors whose products need changes	One-time per finding, with recurring retesting	Number and severity of gaps found in inspections, audits or scans; early gap analysis lowers surprise work
Management time and training	Internal management body members, who must oversee the measures under Article 20	Recurring	Frequency of briefings and reports to the management body and the depth of documented decisions

Who owns Article 32 readiness: the entity, a partner and the auditor

The entity owns its risk-management measures, its policies and the evidence that shows they operate. The management body approves and oversees these measures, and the staff who run the controls must be able to explain them to an inspector. No part of Article 32 moves that responsibility to a vendor or consultant, so readiness starts with named people inside the organization.

Control ownership: name an owner for each control area, with the decisions and sign-offs recorded in a register.
Policy set: keep documented cybersecurity policies that match how systems actually run, because authorities can request them.
Evidence custody: keep logs, tickets, configuration exports and audit results retrievable on request, with a clear retention rule.
Request handling: appoint one contact to receive information requests, check the stated purpose and respond within the deadline the authority sets.
Remediation tracking: assign, date and close every finding from scans, audits and internal reviews.

Check whether each control owner can name the evidence for their control and locate it without calling an outside consultant.

Where essential entities fall short on supervisory requests

When a national competent authority asks for evidence under Article 32, the request usually exposes gaps that were invisible during day-to-day operations. The cards below cover the five gaps we see most often, each with a closing action the organization can take before the next request arrives.

Unclear evidence owners

Article 32 requests ask for documented policies, access to records and evidence of implementation. If no named person owns each evidence item, the answer arrives late or inconsistent. Assign one owner and one backup per control, and record where the current evidence sits. Closing action: publish an owner register and test it by pulling one item per control.

Unlinked policies and controls

Authorities test whether written policies translate into operating controls. Policies that do not point to specific technical or organizational measures force staff to reconstruct the link under pressure. Map each policy clause to the control that implements it and to the record that proves it runs. Closing action: build a policy-to-control-to-evidence matrix and review it after each material change.

No record of request handling

Authorities must state the purpose of a request and the information they want, and the entity must respond against that scope. Without a log of incoming requests, deadlines, responses and the people who approved them, the organization cannot show what it provided. Keep a request register with dates, scope, reviewer and the exact files sent. Closing action: run a tabletop exercise with one mock information request and confirm the register captures every step.

Audit findings without tracked remediation

Targeted and regular security audits produce results that go to the authority. If findings from earlier audits, scans or internal reviews remain open with no owner or due date, the entity may be asked to show why a known weakness persisted. Track every finding to closure with evidence of the fix and a retest. Closing action: confirm that each open finding has an owner, a target date and a linked verification record.

Out-of-date asset inventories

Security scans and on-site inspections start from what the entity runs. An inventory that omits systems, cloud accounts or internet-facing services means scan results and evidence cover only part of the estate. Reconcile the inventory against cloud accounts, network records and configuration management at a set cadence. Closing action: compare the inventory with a fresh discovery scan and close every gap before the next review.

Questions buyers ask about Article 32 supervision

Can we prepare for Article 32 supervision on our own?

Yes, an essential entity can prepare its own evidence, and nothing in NIS2 requires an outside firm. The organization owns its risk-management measures, its policies and its records, and its management body remains accountable for them. Outside help is usually a question of capacity and experience: whether your team has run an independent security audit before, whether it can produce evidence on demand, and whether it has time to map existing controls to the Article 21 measures and the requirements of Implementing Regulation (EU) 2024/2690. Many organizations split the work, keeping governance and decisions in-house and bringing in a partner for systems hardening, evidence collection and testing.

How much effort does supervision readiness take, and what drives it?

No supplied figure gives a reliable effort estimate, so confirm the number through a written assessment of your own environment. The main drivers are the size and number of in-scope systems, how well current controls are documented, how much evidence already exists in logs and tickets, and whether your organization operates in several Member States under different national laws. Ask any provider to split effort into a gap assessment, remediation, evidence collection and support for an audit, and to state which of these recur each year.

Who pays for an independent security audit under NIS2?

Under Article 32(2), the audited entity pays for audits carried out by an independent body, unless the competent authority decides otherwise in duly substantiated cases. Targeted audits follow a risk assessment made by the authority or the entity, and their results go to the authority. The authority itself may order audits, so the cost sits with the entity in most cases. Budget for the audit fee, the internal time to prepare evidence and any remediation that the audit finds. Ask the auditor for a quote that separates scoping, fieldwork and reporting.

Does NIS2 issue a certificate that proves we comply?

No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines under Articles 32 to 34. Some organizations seek a certification or attestation against a standard such as ISO/IEC 27001 to show structured control, but that is a voluntary choice and does not replace supervision. Only an independent auditor or certification body issues a report or certificate, and DeployOpen does not issue either.

What should we confirm with our national competent authority?

Start with the authority's expectations for your sector and entity type, because national transposition laws differ. Confirm which authority supervises you, whether it expects an ex ante regime as an essential entity, how it selects targeted audits, which audit methods and qualified auditors it accepts, and in what format it expects audit results and underlying evidence. Also ask how it will state the purpose of its information requests, since Article 32(3) requires that. Record each answer in writing, because the authority's position will shape your evidence plan.

What must our own team keep in-house?

The management body must approve and oversee the Article 21 measures, and it cannot delegate that accountability. Your organization should also keep ownership of its risk assessment, its documented cybersecurity policies, its decisions on acceptable risk and the day-to-day operation of controls such as access management, change control and backups. Outside partners can prepare systems, documentation and evidence, run security testing and support an audit, but the people who run your environment must be able to explain and maintain it after the engagement ends.

What evidence should we have ready for an authority request?

Authorities may ask for documented cybersecurity policies, access to data and documents, and evidence that measures are implemented, including results of security audits by a qualified auditor with the underlying evidence. Keep these ready in a single, dated location: the policy set, the asset inventory, risk assessments, test and scan results with remediation records, access reviews and change records. Version control helps show what changed and when. Confirm the exact format each authority expects before you build the repository.

How DeployOpen prepares essential entities for supervision

DeployOpen prepares the systems, controls and evidence that an essential entity would put in front of its competent authority under Article 32, but it does not inspect, audit, certify or report on compliance itself. Work is delivered as a fixed-scope engagement inside the client's own infrastructure, whether that is their cloud accounts, data centers or air-gapped networks. The scope, deliverables and timelines are agreed in writing before any work starts, and a quote follows from that written scope. Only an independent auditor, an assessor appointed under Article 32(2), or the authority itself issues audit results or findings.

In practice, a preparation engagement for Article 32 usually starts with the evidence an authority is most likely to request: the documented cybersecurity policies, the results of security scans and audits, and records showing that the Article 21 measures are operating. DeployOpen can help configure self-hosted platforms so that access logs, change history and policy approvals are retained and easy to export, and can run internal security testing so that the entity learns about weaknesses before an authority does. The client keeps ownership of its controls and decides which findings to fix, accept or escalate. Confirm with your own counsel which findings must be disclosed to the authority and in what form.

Ongoing support, upgrades and continuous testing are available as retainers, which suits entities that expect recurring or ad hoc audits and want their evidence kept current between assessments. Before you engage any provider, ask for the written scope, the list of deliverables, the evidence each deliverable produces, and the named client roles responsible for signing off on each control. Confirm which parts of an audit cycle the provider will not perform, and make sure the independent auditor you select is acceptable to your competent authority.

Article 32 Supervision of essential entities