NIS2: The Evidence Package You Need to Pass an Inspection

If your national competent authority asked your organisation today to demonstrate how it manages cybersecurity, what evidence could you produce? A signed policy, the contract with your IT provider and a few training certificates rarely suffice.

Preparing for a NIS2 supervisory inspection requires a verifiable link between the risks you identified, the decisions your management body took, the measures you implemented and the results you obtained. For every relevant control you need to be able to reconstruct who owns it, how it is applied and what proves that it works.

The evidence package makes that reconstruction possible. The list below is a practical proposal derived from the obligations in Directive (EU) 2022/2555; it is not an official inspection checklist and it does not guarantee the outcome of a review, which also covers whether your measures are actually adequate. One caveat applies throughout: NIS2 is a directive, so detailed requirements, implementation deadlines and inspection procedures are set by national law. Read this alongside your national implementing act and any sector-specific rules.

What supervisory authorities can verify

Inspections, off-site supervision and access to data

Article 32 sets out the supervisory toolkit for essential entities: on-site inspections and off-site supervision, including random checks carried out by trained professionals, regular and targeted security audits, ad hoc audits justified by a significant incident or an infringement, security scans based on risk assessment criteria, requests for information needed to assess the cybersecurity measures adopted, requests for access to data, documents and information, and requests for evidence of the implementation of cybersecurity policies, including the results of security audits.

For important entities the regime is ex post: under Article 33 the same powers apply when the authority becomes aware of evidence, an indication or information suggesting an infringement. That condition changes when you are likely to be examined, not what you are required to have in place.

Where your national law channels communications with the authority through a digital platform or registry, part of your compliance evidence lives outside your own archives, in submission receipts and in the data you filed. Reconciling the two sources is the first check worth running.

Audits, scans and who pays for them

Targeted security audits are based on risk assessments or available risk-related information and are carried out by an independent body or by the competent authority. The cost of a targeted audit is borne by the entity concerned, which makes it a line item in the compliance budget rather than an abstract risk. Regular audits, security scans and requests for reporting on implementation can all arrive without an incident having occurred.

Enforcement measures and fines

Before fines come enforcement measures: warnings, binding instructions, orders to cease conduct, orders to implement audit recommendations within a set period, the designation of a monitoring officer, and orders to make aspects of the infringement public. For essential entities, persistent failure to comply can lead to the temporary suspension of a certification or authorisation and to a temporary ban on individuals exercising managerial functions.

Article 34 sets administrative fines with a floor on the ceiling: Member States must provide for maximum fines of at least €10 million or 2% of total worldwide annual turnover for essential entities, and at least €7 million or 1.4% for important entities, whichever amount is higher. National law may go further and may add separate regimes for public administration bodies.

How the evidence package is organised

We have grouped the evidence into five areas: governance, risk management, security, supply chain and incidents. Each area collects the documents that follow from the Directive and the operational records that show they are applied in practice.

Article 21 requires appropriate and proportionate measures under an all-hazards approach, taking into account the entity’s exposure to risk, its size, the likelihood of incidents and their severity, including societal and economic impact. Proportionality is not a licence to omit: when you narrow the scope of a measure, the reasoning behind that scope becomes part of the evidence. Write down which systems and services are in scope, why, and what you decided to leave out.

Two further layers sit on top of the Directive. National implementing measures usually specify technical requirements, implementation deadlines and the distinction between what essential and important entities must do. For DNS service providers, TLD name registries, cloud computing and data centre services, content delivery networks, managed service and managed security service providers, online marketplaces, search engines, social networking platforms and trust service providers, Commission Implementing Regulation (EU) 2024/2690 lays down detailed technical and methodological requirements that apply directly. Identify which layer governs you before you start collecting.

1. Governance: responsibilities, policies and management oversight

1.1 Scope file and filings to the authority

Keep the notification of your inclusion in the national list of essential and important entities, any identifier assigned to you, your classification, and every submission you have made to the competent authority together with the receipts. Member States had to establish those lists by 17 April 2025 and must review them regularly, at least every two years, so your classification is not a one-off fact: keep the versions.

Under Article 27, DNS service providers, TLD name registries, entities providing domain name registration services, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, and providers of online marketplaces, search engines and social networking platforms must submit registration information, including name, sector, establishment addresses, IP ranges and contact details, and keep it current. If you fall into one of these categories, the filing history is part of the file.

Where your national framework requires you to list or categorise your activities and services, or to justify a change to a pre-assigned criticality category, keep the submitted version and the supporting analysis. Once a filing window closes, the version you submitted is the one you will be examined against.

1.2 Security organisation and allocation of responsibilities

Prepare the cybersecurity organisation approved by your management body, the current list of the people appointed and the responsibilities assigned to them, including any roles carried out by third-party personnel. Document the contact point towards the competent authority, the person who liaises with the CSIRT, and their deputies, with the evidence that each appointment was accepted and notified. Review roles and responsibilities at defined intervals and after significant incidents, organisational changes or shifts in risk exposure.

Name the members of the management body in the file. Article 20 makes them responsible for approving the measures and supervising implementation, and provides that they can be held liable for the entity’s infringements, so the file should make clear who held that position and when. Internal communications and operating instructions show that responsibilities actually reached the people concerned.

1.3 Management body approvals and oversight

Collect the approvals of the cybersecurity organisation, the policies, the risk assessment and risk treatment plan, the vulnerability management plan, the remediation plan, the business continuity, recovery and crisis management plans, the training plan and the incident handling plan. Tie each approval to the exact version of the document it covers.

Add the periodic reports to the management body on remediation progress and on the effectiveness of the measures. They are what demonstrates that oversight continued over time, beyond the moment of signature, which is the part Article 20 actually asks for.

1.4 Policies and how they were communicated

Article 21(2) sets the substantive perimeter your policies have to cover:

• policies on risk analysis and on the security of information systems;
• incident handling;
• business continuity, including backup management and disaster recovery, and crisis management;
• supply chain security, including security aspects of relationships with direct suppliers and service providers;
• security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure;
• policies and procedures to assess the effectiveness of the cybersecurity risk-management measures;
• basic cyber hygiene practices and cybersecurity training;
• policies and procedures on the use of cryptography and, where appropriate, encryption;
• human resources security, access control policies and asset management;
• multi-factor or continuous authentication, secured voice, video and text communications, and secured emergency communication systems within the entity, where appropriate.

Keep the management body’s approval and the evidence that each policy was communicated to the functions that need it, on a need-to-know basis. You can hold this in a single document or across several consistent ones. National measures often add the minimum content required for each area, so check that list before deciding your structure.

1.5 Reviews, audits and improvement

Article 21(2)(f) requires policies and procedures to assess whether the risk-management measures are actually effective, and Article 21(4) requires appropriate and proportionate corrective measures without undue delay where a measure falls short. In practice that means three things in the file: the results of periodic reviews, the audit reports you hold, and an approved remediation plan with progress reporting.

Review the policies at least annually and whenever the law changes, a significant incident occurs, the organisation changes or risk exposure shifts, and record the outcome, including whether the policies still match the applicable rules. Link every gap to an action, an owner and a closure check.

2. Risk management: scope, assessment and treatment

2.1 Inventories of systems, assets and services

Asset management is an explicit requirement. Keep current inventories of physical devices, including IT, IoT, OT and mobile equipment; of services, systems and software applications, including commercial, open source and custom applications, including those reachable through APIs; and of the IT services supplied by providers, cloud services included. Inventoried assets should be traceable to an internal approval: an inventory records what was authorised, not only what happens to be running.

Then define which network and information systems are in scope, that is, those whose compromise would significantly affect the confidentiality, integrity or availability of the activities and services that bring you within NIS2. Document the path you followed: identification of the activities and services concerned, assessment of the impact of a compromise, selection of the systems with significant impact. No particular methodology is prescribed, but the reasoning has to be reconstructable.

2.2 Risk assessment and management plan

Keep the risk management plan and the documented assessment, covering identification, analysis and evaluation of risks, including dependencies on suppliers and partners. Link scenarios to the systems and services they affect. The assessment should be approved, kept up to date and clear about the priorities it establishes.

This document carries more weight than it appears to. Because the Directive requires measures proportionate to your exposure, the assessment defines both how and where each measure applies. If it is thin or generic, the scope you gave those measures becomes hard to defend during a review.

2.3 Risk treatment and documented exceptions

The treatment plan should set out measures, priorities, owners and timelines, together with the reasons for accepting any residual risk, and it should be approved by the management body. Where a requirement cannot be met for documented legal or technical reasons, record the constraint, adopt compensating measures where feasible, and describe both in the treatment plan along with the residual risk. A general acceptance of risk does not switch off an obligation.

2.4 Vulnerability handling and security updates

Keep the approved vulnerability management plan, the evidence that you monitor advisories from your CSIRT and from sector CERTs and ISACs, and the records of the action taken. Link every vulnerability to a fix, a mitigation or a documented risk decision. Coordinated vulnerability disclosure has its own framework under Article 12, including the European vulnerability database maintained by ENISA, so note which channel applies when a vulnerability concerns a product or service you provide.

Many national frameworks require periodic vulnerability identification activities on in-scope systems, typically including vulnerability assessments and penetration testing, also before a system enters production. Where that applies to you, document each exercise with a report describing scope, findings, the vulnerabilities identified and their impact.

3. Security: people, access, data, systems and continuity

3.1 Identity, authorisations and privileged access

Prepare the procedures for granting, changing, reviewing and revoking access, with the evidence of each authorisation. Document least privilege, separation of duties, the separation of administrative credentials, credential strength and rotation, and the use of multi-factor or continuous authentication, which Article 21 lists among the measures to apply where appropriate. Exported configurations and a sample of revoked accounts show that the procedure works in daily practice.

3.2 Human resources security and training

Keep the procedures and records relating to personnel reliability checks, in particular for system administrators, within the limits your employment and data protection law allows. Add the approved training plan, with activities, content and any assessment of what was learned, and the current register of the people trained. Article 20(2) requires members of the management body to follow training themselves and to offer similar training to employees, so their attendance records belong in the same file. Specialised roles, system administrators first among them, usually need dedicated training on secure configuration and operation, known threats and expected behaviour during an event.

3.3 Protection of data, networks and physical environments

Collect the procedures and evidence on cryptography and encryption, removable media, physical access protection, perimeter systems such as firewalls, and remote access. Keep a current list of systems reachable remotely, with the access methods and the documented definition of what is permitted. Exported configurations, authorisations and control records are useful proof, provided each one points to an identifiable system and a verifiable date. Secured voice, video and text communications and secured emergency communication systems are part of the same area where appropriate.

3.4 Secure acquisition, development and maintenance

Document software updating, including any justified exceptions, and secure development practices where you build software or have it built for your systems. Add secure baseline configurations for in-scope systems, records of hardware maintenance, and procedures for the secure transfer and disposal of media. Keep the evidence of testing before critical updates are deployed. If you rely on certification schemes, note that Article 24 allows Member States to require the use of certified ICT products, services and processes.

3.5 Business continuity, backup and recovery

Prepare the approved business continuity, disaster recovery and crisis management plans, consistent with your in-scope systems and complete with purpose, continuity requirements, scope, roles, responsibilities, contacts and internal and external communication channels. Add the procedures and results of periodic backups of data and configurations, consistent with the requirements set in those plans, including offline copies for the systems that matter most.

Protect the confidentiality and integrity of backups through physical protection of the media or encryption, and test restoration periodically on in-scope systems. Whatever your national requirements say about the frequency, a restoration test that was actually carried out remains the single most persuasive piece of evidence in this area.

4. Supply chain: suppliers, contracts and dependencies

4.1 Supplier register and assessment of direct suppliers

Article 21(2)(d) covers supply chain security, including the security of relationships with direct suppliers and service providers. Article 21(3) is more specific: you must take into account the vulnerabilities specific to each direct supplier and service provider, the overall quality of their products and their cybersecurity practices, including their secure development procedures.

Keep a register of the suppliers that matter for the security of your network and information systems, with the criterion you used to qualify each one. Two criteria cover most cases: the supplier provides ICT products or services to your in-scope systems, or an interruption or compromise of the supply would significantly affect your ability to deliver the activities and services that bring you within scope, including because no alternative provider is available. Where national law requires you to file that list with the authority, keep the submission receipts too.

4.2 Inventory of supplier services and dependencies

Keep the inventory of IT services supplied by providers, cloud services included, and connect it to your risk scenarios: access to systems, data processed, operational dependencies and the consequences of an outage. Any security roles and responsibilities assigned to third-party personnel should appear in your security organisation, be communicated to the functions concerned, and be listed alongside your own named roles.

4.3 Assessment, contractual requirements and verification

Prepare the risk assessments of supplies that could affect the security of your network and information systems, the security requirements written into the contracts, and the checks on whether suppliers meet them. Contracts, verified questionnaires, meeting records and audit reports document the process; the contract with your IT provider covers only part of it. Article 22 adds a further input: the Cooperation Group, together with the Commission and ENISA, carries out coordinated security risk assessments of critical supply chains, and the results are something you are expected to take into account.

5. Incidents: detection, handling and reporting

5.1 Logging, monitoring and detection

Keep the procedures for recording, protecting and retaining logs, with retention periods defined and justified against your risk assessment. Make available the evidence that all remote and privileged access is logged, that logs from in-scope systems are collected securely and, where feasible, centrally, and that your detection tooling, endpoint protection included, is operating.

Document the expected service levels of your activities and services, defined among other things so that a significant incident can be detected in time. Analysis and filtering of inbound traffic, email included, monitoring of remote access, perimeter system activity, significant administrative events and successful and failed logins, and the thresholds you use to spot unauthorised or privilege-abusing access all belong here.

5.2 Incident handling plan and communication

Prepare an approved plan covering responsibilities, contacts, response and reporting procedures, escalation to the management body, and internal and external communication, including notices to the recipients of your services under Article 23(2) and public communication where the authority requires it under Article 23(7). Review and update the plan. Include templates for documenting an incident and the procedures for restoring normal operation.

Define which decisions sit with the person handling the incident and which escalate to the management body. It is one of the points on which documentation is usually silent, and the one that costs the most time during a real event. Records of tabletop exercises are useful proof of organisational readiness: link them to the weaknesses they revealed and to the changes you made.

5.3 Incident files and reporting

Article 23(3) defines when an incident is significant: when it has caused or is capable of causing severe operational disruption of your services or financial loss, or when it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. The trigger is the effect, not the cause, and the cause can be accidental as much as deliberate. Record the reasoning that led you to classify an event one way or the other, not just a general judgement about severity. Sector-specific thresholds may apply, including under Implementing Regulation (EU) 2024/2690 for the entity types it covers.

For each incident keep the timeline, the objective facts, the decisions, the actions taken and the communications sent. Where reporting is due, document the stages set out in Article 23: an early warning without undue delay and in any event within 24 hours of becoming aware of the significant incident, indicating whether it is suspected to be unlawful or malicious or could have cross-border impact; an incident notification within 72 hours, updating the early warning and including an initial assessment of severity and impact and, where available, indicators of compromise; an intermediate report on the request of the CSIRT or the competent authority; and a final report within one month of the notification, with a detailed description, the type of threat or root cause, the mitigation measures applied and any cross-border impact.

If the incident is still ongoing when the final report falls due, submit a progress report and then the final report within one month of handling the incident. Trust service providers report within 24 hours of becoming aware of a significant incident. Keep the evidence of any voluntary notifications made under Article 30, and of any parallel reporting you owe under other instruments, so that a reviewer can see the full picture from one file.

Making the package usable during an inspection

The requirement-evidence matrix

Having the evidence is not enough: it has to be retrievable. An archive of hundreds of files with no reference to the requirements makes the work you did almost impossible to reconstruct. A matrix with these columns solves the problem:

The matrix is a recommended way of organising the work, not a template imposed by any authority. Paper or digital is a matter of choice, as long as the material stays easy to consult for the people who need it.

Inspection procedure

An inspection procedure sets out who does what the moment officials arrive. It is not a document the Directive requires; it is organisational preparedness, and it stops the quality of your response from depending on who happens to be in the office that day. Anyone who has handled a regulatory inspection before will recognise the pattern: the counterparties and the subject matter change, the logic does not.

Start: reception, checking the mandate and internal activation

Write down what reception staff do: identify and record the officials in line with your site access procedure, make the privacy notice for visitor data available, issue the visitor pass, notify the legal representative and the contact point without delay, and hand the inspectors to someone tasked with taking them to a room identified in advance.

The contact point checks the instrument authorising the visit. Requests for information under Article 32 have to state the purpose and specify what information is required, so recording the stated purpose and scope is the first item in the inspection file and it frames what you will hand over. From that check follow two things: informing the management body, and a short internal message to the people involved covering three points, namely cooperate, do not obstruct the checks, and keep what you learn confidential. This has a sanctions dimension too: failure to cooperate with the authority or the CSIRT is treated as an infringement in its own right in most national frameworks.

Finally, name who covers each of the five evidence areas and who deputises. They should be the same names that appear in the requirement-evidence matrix.

During: one channel and a record of what you hand over

Route all requests through a single point of contact, who keeps a log of what was asked and what was provided, with the title, version, date and format of every document. Answer what was asked, without reconstructing anything from memory. If a document does not exist or is out of date, saying so and noting it is better than an approximate answer that ends up in the record. Keep oral statements separate from documents produced, because they travel differently through the minutes.

Close: minutes, document list and open commitments

Before the inspection closes, check that the minutes reflect what happened and that the list of documents handed over is complete and correct, ask for a copy of the minutes, and agree the list of points to clarify and documents to send with the deadlines attached. Verify what your own people stated and have any observations entered into the record. That is the moment when an inaccuracy costs nothing to fix.

What follows is procedural and worth knowing in advance. Before enforcement measures are adopted, authorities generally notify their preliminary findings and allow a period for you to submit observations, and many national regimes provide for an instruction to comply which, if met within the time allowed, closes the matter without a fine. Both stages go better when your delivery log and remediation plan are already updated with the findings.

Rehearsal: test the procedure before you need it

Half a day is enough. Pick five requirements at random, one per area, and measure how long it takes to retrieve the document, the approval and the operational proof in the right version. Simulate reception and the mandate check, assign the roles exactly as you wrote them, record the exercise and link every weakness to an action with an owner and a date. You are probably already running incident exercises; extending the same method to the documentary side costs little and shows you in advance where the package jams.

Where to start: classification, applicable law and deadlines

Start by establishing which regime governs you: your classification as an essential or important entity, the national act that transposes the Directive in each country where you are established, and any sector-specific rules. The Directive fixes some dates directly and leaves others to national law.

If you operate in more than one Member State, check jurisdiction before anything else: Article 26 attaches most entities to the country where they are established, while certain digital providers fall under the Member State of their main establishment, which determines who supervises you and whose deadlines you follow.

Then take stock of the evidence you hold. For each requirement, ask four questions: does the document exist, is it current, does it carry the approvals it needs, and can we show that it is applied?

Assess your organisation’s evidence package

PrivacyRise works alongside compliance and IT security teams to review NIS2 evidence: we identify the gaps area by area, set the priorities and build a remediation plan you can actually verify. You get the requirement-evidence matrix already mapped to your classification, your jurisdiction and your deadlines, ready to use with your internal owners and your suppliers.

Request your NIS2 evidence package assessment