NIS2 documentation: What auditors expect to see | House of Control

Implementing the security measures required by NIS2 is one thing. Being ready for an audit is something else entirely. Under the NIS2 Directive, preparedness is assessed through evidence. Auditors expect that evidence to be structured, traceable, and integrated into daily operations.

Documentation is therefore not an appendix to NIS2 compliance. It is the very foundation auditors use to verify that an organisation actually complies with the requirements set out in Articles 21 and 23.

Summary

• NIS2 audits assess systems, processes, and documented evidence - not assumptions.
• Auditors expect documentation that shows real implementation, not just policies.
• Evidence must cover governance, risk management, incident handling, and third-party control.
• Documentation must be structured, connected, and available on demand.
• Continuous documentation outperforms last-minute preparation.

Why does NIS2 documentation matter to auditors?

NIS2 introduces significant sanctions for non-compliance. Supervisory authorities will assess not only whether security measures exist, but how effective they are in practice.

For auditors, this means that policies alone are insufficient. They will ask to see how measures have been applied over time: what has been decided, who is responsible, how risks are followed up, and what evidence this leaves behind.

Put simply, NIS2 documentation is the evidence portfolio that proves an organisation’s systems, people, and processes function as intended.

Read more: Why contract management is the foundation of NIS2 compliance.

What do auditors actually look for under NIS2?

In practice, NIS2 audits are often structured around four main areas.

1. Evidence of governance and leadership (Article 23)

Audits start at the top. Auditors will expect to see:

• Documented approval of security measures by the board or executive management
• Clearly defined roles and responsibilities
• Meeting minutes and governance records showing active oversight

This is the core of Article 23: cybersecurity must be a documented leadership responsibility, not an informally delegated IT task.

2. Risk management documentation (Article 21)

Auditors assess whether risk management is systematic, repeatable, and up to date:

• Risk assessments and risk registers
• Documented threat modelling
• Risk treatment plans and evidence of updates
• Supplier and third-party risk assessments

Auditors are looking for living documentation, not static snapshots. Risk must be managed continuously, not archived.

3. Incident response and continuity logs

Preventive measures matter, but auditors will also focus on what happens when incidents occur:

• Documented and tested incident response plans
• Historical incident logs and outcomes
• Evidence of simulations and exercises
• Crisis communication plans

This demonstrates real operational resilience, not just theoretical preparedness.

4. Evidence of supplier and third-party control

Given NIS2’s strong focus on dependencies, auditors will review:

• Contracts containing explicit security requirements
• Documented third-party security assessments
• Supplier risk documentation
• Records of ongoing monitoring and follow-up

This reflects the expectation that risk must be managed across the entire value chain, not only within the organisation itself.

What does good NIS2 documentation actually look like?

Effective NIS2 documentation is connected. Policies must link to decisions. Decisions must link to actions. Actions must link to contracts, ownership, and real-world events.

Examples include:

• Risk treatment plans linked directly to test results
• Incident response plans linked to actual incident logs
• Supplier contracts linked to ongoing risk and performance assessments

This is why folders full of PDFs rarely satisfy auditors. They expect documentation that can be traced across domains - and produced quickly when requested.

For many organisations, this is where structured digital systems become critical. When contracts, responsibilities, risks, and follow-up are connected in one place, documentation supports both Article 21’s operational requirements and Article 23’s governance obligations.

Read more: The NIS2 24-hour rule: Handling incident reporting requirements.

What is the difference between paperwork and audit-ready evidence?

A common pitfall is documentation that looks complete but does not reflect real operations.

Auditors typically test whether:

• Controls are followed over time, not just described
• Incidents are logged with timestamps and ownership
• Documentation reflects organisational and technological change
• Contractual clauses are enforced with measurable outcomes

Here, structure and traceability are decisive. Without them, documentation quickly becomes fragile under audit scrutiny.

How should organisations prepare documentation that stands up to audit review?

• Start early and build continuously. Auditors expect history, not documentation created just before an audit.
• Assign clear ownership. Every control should have a named responsible party.
• Use structured systems. Cloud storage alone is insufficient; documentation must be searchable, linked, and traceable.
• Explicitly reference NIS2 requirements. Articles 21 and 23 should be clearly reflected in governance structures and contractual frameworks.

By treating documentation as a continuous discipline rather than a one-off exercise, organisations not only prepare for audits but also strengthen everyday risk management.

Key takeaways

• Treat documentation as evidence, not paperwork
• Ensure governance and leadership oversight are documented in line with Article 23
• Maintain structured, up-to-date risk documentation as required by Article 21
• Connect contracts, risks, and operational evidence in one coherent structure
• Build audit readiness continuously rather than reacting when scrutiny begins

Disclaimer: House of Control is a software company. We do not offer NIS2 compliance consulting services. Thus, following this guidance does not guarantee compliance with all NIS2 legal requirements. The content of this article is based on our own research of the NIS2 requirements and our experience with regulatory compliance, and includes inspiration from various actors offering compliance services. We do not assume any responsibility or liability for any failure to comply with NIS2 requirements or resulting from the use of this guidance.