What NIS2 evidence and documentation do supervisors expect to see?
NIS2 creates no certificate of compliance, so an organization cannot hand a supervisor a single document that closes the question. Instead, the competent authority will ask for three things: documented cybersecurity policies, the results of audits with the underlying evidence, and proof that the Article 21 measures actually run day to day. Under Article 32(2), an authority can request information to assess risk-management measures, including access to data and documents and evidence of implementation. The practical test is whether each claim in your policies can be traced to a dated record that someone other than the author could check. The organization owns its controls and is accountable for them. An implementation partner can configure systems, collect logs, set up backup and access records, and organize the evidence, but the partner does not issue reports. Only an independent auditor or qualified assessor produces audit results that a supervisor will treat as independent.
The answer depends on three variables: your scope, your entity type and your evidence maturity. A company classed as essential faces ex ante supervision, which means inspections and security scans can happen before any incident, while an important entity faces ex post supervision that is usually triggered by evidence of a failure or a complaint. Scope determines which systems and suppliers the authority will look at first. Evidence maturity determines whether you can answer quickly. Ask yourself which records you could produce within a short window, who would sign them, and whether they cover the systems that matter most. Confirm with your national competent authority what format and level of detail it expects, because transposition laws differ between Member States.
Start with a gap review of your evidence, not just your policies. Pick two or three measures, such as privileged access or backups, and trace each claim back to the system log, approval record or restore test that proves it. Where an external audit is needed, agree its scope in writing, confirm that the auditor is independent of the area reviewed, and check that the underlying evidence is kept with the report. Targeted security audits under Article 32(2) can also be ordered by the authority, and the audited entity generally pays for an independent body, so budget for that possibility. The NIS2 Directive text on EUR-Lex sets out the supervisory powers in full.
Which evidence answers each supervisory question
What logging and detection evidence will a supervisor ask for under NIS2?
Supervisors usually want proof that security events are collected, analyzed and acted on, not just that a tool is installed. ENISA's June 2025 guidance lists examples such as SIEM systems, EDR or XDR tools, log samples containing the elements required by point 3.2.3 of the Implementing Regulation, configured alarm thresholds and records of past alarms. Keep the configuration exports, a recent log sample and the tickets showing how alarms were triaged. ENISA's guidance is non-binding and does not by itself establish compliance, so use it as a map of expected evidence and confirm each requirement against the regulation text and your national transposition law.
What backup evidence proves NIS2 backup requirements are met?
A supervisor will look for records showing that backups run, that copies leave the primary site, that their integrity can be verified and that restores have been tested. ENISA's June 2025 guidance gives examples including backup software logs, evidence of off-site copies, checksum or hash settings, restore test records and a backup plan review that refers to the 3-2-1 rule. Restore test records carry the most weight because they show recovery actually works. The guidance does not by itself establish compliance, so confirm each expectation against the Implementing Regulation and your national law.
How do you evidence secure configuration baselines for NIS2?
Show a documented secure baseline for each system class, a record of every approved deviation, and a trail of how configurations changed over time. ENISA's June 2025 guidance lists documented secure baseline configurations, approved exceptions with compensating measures, configuration snapshots before and after changes, and alerts on unexpected configuration changes as examples of evidence. Exceptions are the item auditors and supervisors question most, so each one should name the risk accepted, the compensating control and the approver. The guidance is non-binding and does not by itself establish compliance.
What testing evidence should be ready for a NIS2 security audit?
Keep a test plan with a schedule, the reports that came out of each test and a list of the tools used. ENISA's June 2025 guidance lists test plans and schedules, reports covering vulnerability assessments, penetration tests and code reviews, internal or external audit reports and a list of testing tools as examples of evidence. Reports should show scope, findings, severity and the status of remediation. Where an audit is performed by an independent body, the audited entity typically pays for it unless the authority decides otherwise in duly substantiated cases, so confirm who bears that cost before the audit is scheduled.
Which privileged access records do supervisors expect to see?
Supervisors expect a current list of privileged users and the systems each can reach, approval records for granting that access, periodic access reviews, revocation records and audit trails of privileged activity. ENISA's June 2025 guidance names each of these as an example of evidence. Reviews matter as much as the list itself, because they show that access is checked and removed when no longer needed. Confirm with your platform team which privileged activity logs are retained, for how long, and where they are stored.
What policy evidence does a supervisor request first under NIS2?
A supervisor will first ask for the documented cybersecurity policies that set out the Article 21 measures, along with proof that management approved them. Under Article 32(2), authorities can request documented policies, access to data and documents, and evidence of implementation. ENISA's guidance lists the ten topic-specific policies it identifies, and the policy set should be traceable to the risk assessment and to the evidence listed above. Record approval dates, review dates and version history, because a policy without an owner and a review cycle is hard to defend. Confirm the full policy list against the regulation and your national law, since ENISA's guidance does not by itself establish compliance.
How to keep evidence ready: continuous records or a pre-inspection sprint
Many organizations already produce much of the evidence a supervisor may ask for, because security tooling and service management write records as a side effect of daily operations. The work is to confirm that these records are complete, protected and tied to the NIS2 measures they support, rather than to build new collection processes. Start by mapping each measure under Article 21 to the system that produces its records, such as a SIEM for logging and detection, an identity provider for access, or a change ticketing system for configuration changes.
- Collect exports on a schedule: Keep dated exports or read-only snapshots of alarm thresholds, access review results and change tickets, so the state at a given date can be shown later.
- Protect log integrity: Confirm that logs are forwarded to a store that administrators of the source system cannot edit, and record who can change retention settings.
- Link tickets to measures: Tag change, incident and access tickets with the measure or policy they serve, so an assessor can follow one control from policy to record.
- Set retention in writing: Document how long each record type is kept, and check that the setting in the tool matches the written rule.
- Name a sign-off owner: Assign someone outside the team that runs the system to review the periodic extracts and record the review.
Likely gaps are logs that exist but are never reviewed, alarm records that were deleted when a tool was upgraded, and tickets closed without a note on what was checked. Confirm retention and export settings in each tool directly, since default values differ between products.
Some measures, such as policy reviews, supplier assessments, restore tests and privileged access reviews, depend on people completing steps and writing them down. These controls often work in practice but leave little trace, so the evidence is the weakest part of the program. The aim is to turn each recurring manual activity into a repeatable record with a date, an owner and a reviewer.
- Use a fixed template per control: Give each recurring activity a short form that records the scope, the method, the person who performed it and the result.
- Keep the underlying material: Store the screenshot, export or signed list the person relied on, not only a line saying the check was done.
- Schedule reviews in a calendar with owners: Record planned dates, completed dates and any overdue items, since missed reviews are often what an assessor notices first.
- Record exceptions with compensating measures: When a control could not be performed, document the approved exception and what covered the gap.
- Separate performer and reviewer: Where size allows, have someone outside the line of authority review the output, or document the alternative impartiality measure used.
Likely gaps are reviews that happened informally, restore tests that were run but not recorded, and access reviews where the list was approved without comparing it to the directory. Check that each manual control has a named owner, a dated record and a reviewer before relying on it.
When a competent authority announces an inspection or sends an information request, the organization has a short window to assemble and check its evidence. In this situation the priority is to confirm what exists, identify what does not, and avoid creating records that look backdated. Any gap should be disclosed accurately with the corrective plan that follows, rather than covered by newly written documents presented as earlier ones. Your legal counsel should set the response approach and confirm the deadlines in the request itself.
- Build an index against the request: Map each item the authority asked for to a named document or system export, with its owner and storage location.
- Check dates and versions: Confirm that policies carry approval dates, version histories and the management approval record, since these are often requested first.
- Pull recent audit results: Gather internal or external audit reports and the list of findings with their status, including those still open.
- Test the evidence once: Have a second person open each file and confirm it shows what the index says it shows.
- Prepare a gap and remediation list: Record known gaps, the planned corrective action, the owner and the date, so the answer is consistent.
Likely gaps are policies approved without a management record, audit findings without tracked closure, and privileged access lists that do not match current staff. Ask the authority to confirm the format, scope and deadline of the request in writing, and confirm any retention or disclosure obligations with counsel.
How a supervisor-facing audit file comes together
The sequence below turns scattered controls into an evidence file that a competent authority can test, starting from a defined scope and a documented risk assessment and ending with a review cycle that keeps the file current.
Confirm scope and risk assessment basis
Before collecting anything, the management body confirms which entities, systems and services fall inside the NIS2 scope and which national rules apply. The risk assessment then becomes the basis for every later decision, so its date, method, asset list and approved version are recorded. A supervisor who asks why a measure exists will start here. This step is done when the scope statement and the signed risk assessment sit in one controlled location with a version number and approval date. Ask your counsel or national authority contact to confirm any jurisdiction question before you rely on the scope statement.
Map each Article 21 measure to owners and evidence sources
Build a register that lists each Article 21 measure, the named owner accountable for it, the systems that produce its records, and the policy that governs it. Owners should be people with authority to change the control, not only those who operate it. Evidence sources typically include SIEM and EDR consoles, backup software, configuration management tools, identity systems and ticketing records. The step produces a single matrix where every measure has at least one owner and at least one named source, and gaps are flagged as open items rather than left blank.
Collect underlying records rather than summaries
For each measure, pull the primary records that show the control operated during the period under review: raw log samples, alarm threshold configurations, restore test results, configuration snapshots, access review exports and approval tickets. ENISA's June 2025 guidance gives examples of this kind of evidence for each requirement, and a supervisor may request the underlying material behind a report. Store exports with timestamps, the system of origin and the person who extracted them. The step is complete when each matrix row links to records a third party could re-check without relying on a slide or a spreadsheet written for the file.
Obtain independent review of the evidence
Arrange for a review by people with audit competence who sit outside the line of authority of the area reviewed. Where the organization is too small to separate reviewers in this way, document the alternative impartiality measures it uses instead. Reviewers test whether the records support the stated controls and note exceptions. Under the Annex to Implementing Regulation 2024/2690, this independence requirement applies, so record who reviewed what, their competence and their reporting line. Your implementation partner may prepare the material, but it does not perform or certify this review. The step closes with a signed review report and the reviewer's independence statement.
Record corrective actions for each finding
Every exception, failed test or gap from the review becomes a tracked corrective action with an owner, a planned fix, a target date set by management and a closure check. Where a control cannot be fixed immediately, record an approved exception with compensating measures and the accepted residual risk, signed by the person authorized to accept it. Supervisors often judge the program by how findings are handled, so closed items should point to the new evidence that proves the fix works. The step is complete when the findings log shows status, evidence of closure and the approver for each item.
Set a review cycle and keep the file current
Set a documented calendar for refreshing the risk assessment, the policies, the evidence matrix and the independent review, and assign an owner to each recurring task. Changes to systems, suppliers or the threat picture trigger an earlier update. Store each version so that the file in force on a given date can be reconstructed later. The output is a review schedule, a version history and a short statement from the management body confirming the file was reviewed. Confirm the review frequency your national authority expects, because the NIS2 text leaves several cycles to national transposition.
What independent review records must show
An independent review is only useful to a supervisor if the record shows who performed it, how far they stood from the work they checked, and what happened to the findings. The five points below are the parts a competent authority is most likely to test when it asks for audit results and the underlying evidence. An independent auditor issues the review; the organization and its implementation partner prepare the material it examines.
Auditor competence
The record should show that the reviewer has audit competence, meaning training, relevant experience and a working knowledge of the systems in scope. Ask for the reviewer's name, role and qualifications in the review file, not only the firm name. A reviewer who has never tested logging or backup restoration will produce a weak report, and a supervisor reading it will notice. Confirm competence before the engagement starts, not after the report arrives.
Impartiality outside the line of authority
Under Implementing Regulation (EU) 2024/2690, the reviewer must sit outside the line of authority of the area being reviewed. A system administrator should not audit their own patching, and an IT manager should not sign off their own access reviews. Document the reporting line of each reviewer and the area they reviewed, so the separation can be seen on paper. Where a reviewer also helped build the control, record that as a conflict and assign someone else.
Alternative impartiality measures
Smaller organizations may not have anyone outside the relevant team who has the skills to review it. Point 2.3.2 of the Annex allows alternative impartiality measures in that case. Typical examples include an external reviewer for a sample of controls, a second-person check by someone outside the team, or a documented rotation of reviewers. The record must state why full separation was not possible and which measure replaced it. Describe the measure in plain terms so the supervisor can judge whether it works.
Scope and sampling disclosed
A review that does not state its scope invites doubt. The record should name the systems, sites, entities and time period covered, and it should say how items were sampled, such as which firewall rules, privileged accounts or restore tests were examined and how they were chosen. Excluded systems need a reason. Without this disclosure, a clean result tells the supervisor very little about the parts of the environment that were never looked at.
Findings and corrective action tracking
Every finding should carry a severity, an owner, a corrective action, a due date and a closure record that cites the evidence proving the fix. Keep the original finding even after closure so the trail is visible. Supervisors often ask how an entity handles recurring issues, so a register that shows repeated findings and their resolution is more persuasive than a report with no open items. Confirm with your auditor how they want closure verified before the review begins.
Who owns, prepares and issues each piece of evidence
This table compares who owns, who prepares and who issues each piece of NIS2 evidence across the organization, an implementation partner and an independent auditor. Read it as a split of responsibilities: the organization decides and approves, the partner prepares systems and records, and only an independent auditor issues a report. No NIS2 certificate exists, so supervisors judge the evidence the organization can show.
| Evidence item | Organization | Implementation partner | Independent auditor |
|---|---|---|---|
| Documented policies | Owns content, approves through the management body, and keeps current versions | Drafts templates and aligns wording to the measures, without approving them | Reviews design and consistency when testing, and reports findings |
| Control operation | Owns each control, its owner and its operating records | Configures tools and documents how controls run | Tests operating effectiveness on samples and records results |
| Evidence collection | Retains logs, tickets, approvals and reports in its own systems | Sets up collection, retention and export so evidence can be produced on request | Selects samples and examines underlying evidence, not summaries alone |
| Technical preparation | Decides scope, risk treatment and accepts residual risk | Hardens, configures and integrates self-hosted platforms and backups | Does not configure or fix systems during an independent review |
| Independent review records | Commissions reviews and acts on findings with a documented plan | May support remediation but must not perform the review of its own work | Carries out the review with audit competence outside the reviewed line of authority |
| Audit report or equivalent statement | Receives, retains and provides the report to the authority when asked | Does not issue reports, attestations or certificates | Issues the audit report; NIS2 creates no certificate of compliance |
Why supervisor files fail review
Supervisors reviewing NIS2 files tend to test whether documents describe what the organization actually does, and whether the records behind audit results can be inspected. The cards below cover the gaps that most often turn a well-written file into a finding, and what to check before an inspection or security audit starts.
Policies that do not match practice
A policy states that access reviews happen quarterly, backups are tested monthly, or patches are applied within a fixed window, but the systems show something else. Supervisors compare the written policy with configuration, tickets and logs, and a gap between the two undermines confidence in every other document. Check each policy against one recent operational record, and confirm that the owner named in the policy can produce it on request. Where practice differs, either change the practice or revise the document and record the decision.
Screenshots without timestamps or context
A screenshot of a firewall rule, MFA setting or alert threshold shows a state at one moment but not when it was taken, which system it came from, or who captured it. A summary slide prepared for the file is not evidence of the underlying system either. Prefer exports or logs that carry a timestamp, the source host or tenant, and the query used to produce them. If a screenshot is the only option, record the date, the operator and the reason no export was available.
Audit results without underlying records
A report from a penetration test or internal audit states that a finding was closed, but the file holds neither the retest output nor the scan data behind it. Authorities can ask for results of security audits together with the underlying evidence, so a conclusion without its supporting records can be treated as unverified. Keep the scope statement, tool list, raw output and retest records next to each report, and confirm the date each finding was validated.
Self-reviews presented as independent
A review written by the team that runs a control, and then labelled as independent, fails when a supervisor asks who reviewed it and to whom they report. Independent reviews must be carried out by people with audit competence outside the line of authority of the area reviewed, or under alternative impartiality measures where the organization is too small to separate those lines. Record the reviewer, their reporting line, their competence and the measures used where separation is not possible.
Exceptions with no compensating measures
A configuration deviates from the approved baseline, such as a legacy server that cannot take a required setting, but the file records no approval, no expiry and no compensating control. ENISA's guidance expects approved exceptions to come with compensating measures, and alerts on unexpected configuration changes help show that the deviation is known and watched. For each exception, record the business reason, the approver, a review date, and the control that reduces the risk while the exception stands.
Scope drift between risk assessment and testing
The risk assessment lists a set of critical systems and suppliers, but the penetration test or vulnerability scan covers a different set, and no one recorded why. Supervisors compare the asset list in the risk assessment with the systems named in test plans and audit reports, and gaps raise questions about whether the measures address the risks actually identified. Reconcile the asset inventory with each test scope before testing starts, and document any system excluded along with the reason and the risk owner who accepted it.
Questions buyers ask about NIS2 evidence
Does NIS2 give us a certificate of compliance?
No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, as set out in Articles 32 to 34 of the Directive. What you hold instead is a body of documented evidence: policies, risk assessments, audit results and the underlying records that show each measure works in practice. Some organizations also pursue a voluntary certification such as ISO/IEC 27001 to show structured management, but that is a separate decision and does not replace the national authority's assessment. Ask your supervisor which documents it expects you to produce on request.
Can an implementation partner make us NIS2 compliant?
No. The organization owns its controls, its risk decisions and its accountability to the supervisor. An implementation partner can prepare systems, configure tooling, document procedures and assemble evidence so that your own staff and management can demonstrate the measures. Management still has to approve the Article 21 measures and oversee them under Article 20. Only an independent auditor, assessor or certification body issues audit reports or certificates. When you scope outside help, write down which decisions stay with your management and which tasks are delegated, so the division of responsibility is clear to a supervisor.
What does the work need from our internal staff?
Most of the effort lands on people who know your systems and your decisions. Expect to need named owners for identity and access, logging, backups, change management, vulnerability handling and incident reporting, plus someone who can approve policies and sign off risk treatment. Staff must also be able to explain how a control works and show a recent record of it operating, such as an access review or a restore test. Ask any provider to list the internal roles and hours it assumes in the written scope, and confirm who will maintain the evidence after the engagement ends, because evidence that is not refreshed quickly goes stale.
Does ENISA's guidance prove that we comply with NIS2?
No. ENISA's June 2025 technical implementation guidance is non-binding, and it states that implementing its guidance, partly or fully, does not by itself establish compliance. Its value is practical: it gives examples of evidence for each requirement and maps them to frameworks such as ISO/IEC 27001:2022 and NIST CSF 2.0. Use those examples to decide what to collect, then confirm with your national competent authority how it assesses the same requirement. Where Implementing Regulation (EU) 2024/2690 applies to your entity type, its technical requirements are the binding reference, so check which one governs you.
Who pays for a targeted security audit ordered by the authority?
Under Article 32(2), targeted security audits are based on risk assessments carried out by the authority or by the entity, and their results go to the authority. The audited entity pays for these audits when they are carried out by an independent body, unless the authority decides otherwise in duly substantiated cases. Your cost therefore depends on who triggers the audit, how the auditor is appointed and how far the authority's own assessment reaches. Keep an up-to-date risk assessment and audit-ready records, because they shorten the work an external body needs to do. Ask the authority in writing how it will select and invoice the body.
How do we handle the overlap between NIS2 evidence and GDPR?
Many security records serve both regimes, including access logs, risk assessments, incident records and supplier controls. Keep one evidence set with clear tags showing which NIS2 measure and which GDPR obligation each item supports. The reporting clocks differ, so an incident may trigger NIS2 notifications and a GDPR breach notification with separate deadlines and recipients. Your data protection officer and your NIS2 lead should agree one incident process that feeds both. Fines under the two regimes are separate, so confirm with counsel how each supervisor will treat shared documents.
What should we confirm with our national authority?
Start with the basics, because the Directive is transposed through national law and details vary by Member State. Confirm which authority supervises your entity and whether you are essential or important, since that decides ex ante or ex post supervision under Articles 32 and 33. Ask which documents it will request, in what format, and how long you have to produce them. Ask how it selects targeted audits, what qualifications it expects of auditors and whether its national rules add requirements beyond the Directive. Also check whether the proposed amendments of January 2026 (COM(2026) 13) are pending in your case, since they are still a proposal.
How DeployOpen prepares systems and evidence for NIS2 reviews
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure so that the logs, backups, configurations, test records and privileged access evidence a supervisor may ask for already exist and can be retrieved. We prepare systems and evidence; the organization owns its controls, and only an independent auditor or assessor issues audit results.
How we scope
- We agree a written scope listing the NIS2 measures, systems and evidence types covered before work starts.
- We confirm with you which entities, sites and cloud accounts fall inside the review boundary.
- Engagements are fixed-scope, with deliverables and timelines set out in writing for your approval.
How we build
- We configure logging, backup, configuration management and privileged access tooling so it produces records a reviewer can inspect.
- We document baseline configurations, approved exceptions and access review routines in the formats your policies reference.
- We run security testing and record test plans, scope, findings and retest results as evidence files.
How we hand over
- We deliver an evidence index mapping each requirement to the systems, logs and documents that support it.
- We provide runbooks showing how to export restore test records, alarm histories and privileged user lists on request.
- We set out which independent reviews remain your responsibility and what an independent reviewer will need from you.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- We can refresh evidence exports and documentation when systems change or after a supervisor information request.
- Confirm with us in writing which evidence is produced by DeployOpen work and which remains with your own staff.
