Your NIS2 Audit Evidence Guide: Logs, Training Records & KPIs to Prove It

Proving NIS2 compliance in an audit requires more than well-written policies. You must provide tangible, operational proof that your cybersecurity controls are effective, especially concerning human risk. An upcoming audit, whether internal or from a national authority, will demand this specific NIS2 evidence.

The NIS2 Directive fundamentally redefines compliance requirements. It’s no longer enough to simply have security policies; the C-suite and management now bear a direct, legal responsibility for proving their operational effectiveness. This replaces simple assurances with a legal requirement for hard evidence.

When your auditor asks, "How do you prove compliance?" you'll need a clear answer. This guide provides a practical checklist focused on the crucial evidence related to managing your human risk—from governance documentation to the technical logs and training records that provide a clear record of your due diligence.

NIS2 Audit Fundamentals

What is the biggest change NIS2 introduces for compliance audits?

The primary change is the shift from policy-based assurance to evidence-based proof. Management is now legally accountable for demonstrating that security measures are actively working.

Is this guide only about technical logs?

No. This guide focuses on the critical intersection of governance documentation, technical logs, and the specific NIS2 evidences related to your people, such as detailed training records and security awareness KPIs.

Does NIS2 apply if my company is already ISO 27001 certified?

Yes. While ISO 27001 is an excellent framework, NIS2 is a legal mandate with specific, non-negotiable requirements, including management liability and supply chain risk. Certification helps, but it is not a substitute for providing specific NIS2 evidence.

Foundational Evidence: Governance and Risk Management Documentation

For a NIS2 audit, your foundational evidence is your governance documentation. This isn't just about having policies; t's about proving your teams actively use and regularly update these documents that are approved, reviewed, and actively used to manage risk. Without this paper trail, your technical controls lack context and authority.

Auditors will start with your core risk management documentation, which Article 21 on Cybersecurity risk-management measures mandates. Use this checklist to organize your evidence package for NIS2 compliance.

Auditor's Evidence Request List: Governance

• Documented Risk Management Policies: Don't just provide the policy. Show the policy's entire lifecycle. This means including version histories, review logs, and the meeting minutes showing formal approval by management or the board. This demonstrates the top-down oversight NIS2 demands.
• Incident Response and Crisis Management Plans: An untested plan is not evidence. Your evidence must prove the plan is tested and effective. You'll need the plan itself, plus attachments like logs from tabletop exercises, post-incident reports from actual events, and a changelog showing revisions based on post-incident analysis.
• Supply Chain Security Policies: NIS2 is serious about third-party risk. Your Supply Chain Security Policies are the starting point. The complete evidence package must also include your documented procedures for vetting suppliers, copies of contracts with explicit cybersecurity clauses, and the assessment records you've completed.

Auditing Your Governance Documents

How often do policies need to be reviewed for NIS2? 

While NIS2 doesn't set a rigid date, industry best practice is annually or after any significant organizational or threat landscape change. The key evidence is the log showing the review happened, not just the date on the document.

Is a tabletop exercise log enough evidence for incident response? 

It's a strong start. The best evidence combines tabletop logs with post-incident reports from real (even minor) events. This proves your team follows the plan under pressure and, more importantly, improves from it.

What kind of supply chain evidence will an auditor ask for beyond the policy?

Auditors will want to see your "live" evidence. This includes your supplier vetting checklist, completed supplier security assessments, and examples of contracts with updated cybersecurity clauses, proving the policy is enforced.

People-Centric Proof: Assembling Your Training and Awareness Records

The most critical NIS2 evidence for human risk isn't a policy; it's detailed training records and performance logs that prove behavioral change. Auditors no longer accept a 100% completion rate as proof of compliance. They demand to see a data-driven program that measurably reduces human risk over time.

Comprehensive Security Awareness Training Records

When an auditor asks for your training records, "weak" evidence is just a list of names with a "completed" status. This is useless for an audit.

Strong NIS2 evidence is granular and continuous. You must provide exportable, timestamped logs showing:

• Who was trained (including new hires, specific departments, and management).
• What specific modules they completed (e.g., "Phishing," "Password Hygiene," "NIS2 Obligations").
• When they completed it and what their assessment scores were.

This is the only way to demonstrate a tailored, ongoing program rather than a one-time, check-the-box exercise.

Phishing Simulation Performance Logs and KPIs

This is where your data becomes most persuasive. Avoid focusing primarily on failure rates. Your most powerful evidence is the upward trend of positive behaviors. Provide dashboards and phishing simulation logs that track your key security awareness KPIs:

• Report Rates: The percentage of employees who actively report a simulation. This is your single best metric.
• Mean Time to Report (MTTR): How quickly your team reports a threat, enabling your SOC to respond.
• Click/Failure Rates: This metric should be shown in a downward trend over time.

Showing quarterly improvement in positive metrics like report rates is far more convincing than any static "pass/fail" metric.

C-Suite and Management Training Evidence

This is a non-negotiable piece of NIS2 evidences. The directive explicitly requires management to be trained on their personal and legal risk oversight obligations.

You must keep separate, dedicated training records for this group. An auditor will specifically ask for proof that your board and C-suite understand their personal liability and how to oversee cybersecurity risk. This aligns with industry maturity models, like those found in the SANS 2025 Security Awareness Report, which details how to mature a program to effectively engage and measure leadership.

Measuring Security Awareness Effectiveness

What's stronger evidence: a low click rate or a high report rate?

A high report rate is infinitely stronger. A low click rate can mean your simulation was too easy or your employees were just busy. A high report rate is a conscious, positive action that proves your team is an active part of your defense.

Do I need to show records for all employees?

Yes, but you must also show segmentation. Auditors want to see you've identified high-risk groups (e.g., finance, HR, new hires) and can provide evidence of targeted, additional training and interventions for them.

How do I prove my C-Suite and management were actually trained?

This evidence must be separate and specific. You need dedicated training records showing they completed modules on their specific legal obligations under NIS2, not just general phishing awareness. Signed attestations or minutes noting the training's completion in a board meeting are also powerful evidence.

Technical Proof: The Logs and Dashboards That Tell Your Story

Your technical proof consists of the audit logs and security KPIs that show your controls are actively working. For a NIS2 audit, you must present data that specifically correlates to human behavior and risk management. This is the tangible evidence that proves you are actively enforcing your governance policies at the endpoint.

Access Control Review Logs

From our experience, this is the first thing auditors test your enforcement of the principle of least privilege. You must provide audit logs from your Identity and Access Management (IAM) systems that prove you conduct periodic reviews.

Weak evidence is just a current list of users and permissions. Strong evidence includes these specific logs:

• Timestamped records of quarterly or semi-annual access control reviews, especially for critical systems.
• Logs showing who approved the access and when.
• Evidence from your HR or IAM system showing that your team disabled ex-employee accounts within the required timeframe (e.g., within 24 hours of separation).

Security Monitoring and Event Logs (SIEM)

Your SIEM is a critical source of evidence for an audit, but don't just dump raw data. For a human risk audit, focus your evidence on continuous monitoring logs that flag risky behavior. Provide specific examples of alerts your SOC investigates.

Key logs to assemble include:

• Repeated failed login attempts for high-value accounts (management, admins).
• Impossible travel alerts (e.g., a user logging in from Spain and then Singapore 30 minutes later).
• Endpoint Detection and Response (EDR) logs showing a user downloaded a malicious file and the automated response that blocked it.
• Data Loss Prevention (DLP) alerts showing attempts to move sensitive data to unauthorized locations (like a personal USB or cloud drive).

Human Risk KPIs and Reporting

This is what connects your technical controls back to governance. You must prove you analyze this data and report it to leadership to inform risk decisions.

Show the auditor the dashboards you provide to management. This is the ultimate evidence that your security KPIs (like EDR alerts or high-risk user scores) are part of your risk management lifecycle. This practice aligns with formal IT control verification, which uses audit programs and tools from associations like ISACA to ensure controls are not only active but also measured and reported.

Clarifying Technical Log Evidence

What's the difference between a SIEM log and an audit log?

A SIEM log is typically a raw, real-time event (e.g., "login failed"). An audit log is often a record of a review or change (e.g., "Admin X reviewed user Y's permissions on Sept 1"). You need both for a NIS2 audit.

How many logs should I show for access control?

Focus on quality over quantity. Evidence of one comprehensive, completed quarterly access review for your most critical systems is far stronger than 10,000 daily access logs with no context.

How do I present technical logs as "governance evidence" to an auditor?

Do not show the auditor raw logs. Show them the result of the logs. Present the management dashboard or the KPI report that you provide to leadership. This is the evidence that proves you are analyzing the data to make risk decisions, connecting your technical controls back to governance.

Conclusion: Turn Your Audit Preparation into a Strategic Advantage

Preparing for a NIS2 audit isn't a last-minute fire drill. It's the strategic result of continuous due diligence. An organized, data-driven evidence repository is your best and most effective defense in any audit.

Use this checklist to stop reacting to audits and start building a proactive library of your compliance evidence.

When you treat proof of due diligence as a data-driven routine, you transform a regulatory burden into a mature, resilient, and provable security posture. This satisfies regulators and builds lasting trust with your partners and customers.

Strategic View of NIS2 Compliance