Audit readiness for NIS2: concrete evidence, reports and audit documentation for authorities

The expectation for audit readiness under NIS2 is pragmatic: authorities and competent bodies require reliable, traceable and timely evidence that an operator has implemented the statutory requirements. In this practical guide I explain which specific audit documents are necessary, how to structure reports and evidence, and which operational changes this entails. The target audience is IT leadership, compliance officers and security officers who must bridge policy, management and the operational side.

Audit readiness for NIS2: what auditors expect

By audit readiness we mean here the ability to present, within defined timeframes, complete, consistent and auditable documentation demonstrating that the requirements of the NIS2 Directive have been implemented. NIS2 requires not only technical controls but also governance, risk analysis, supply‑chain review, reporting processes and documented responsibilities. Authorities review both processes and operational evidence — i.e. logs, configuration states, change records and incident reports.

Concrete audit areas (brief overview)

• Scope and responsibilities: evidence of who is accountable (RACI, organizational chart).
• Risk management: methodology, result documents, action plan and evidence of recency.
• Incident response and reporting obligations: runbooks, communication chains, sample reports.
• Technical controls and hardening: patch status, access control, encryption, backup strategy.
• Monitoring & logging: SIEM configurations, stored logs, integrity evidence.
• Supply chain and third parties: contracts, due‑diligence checks, SLA evidence.

Governance, roles and responsibilities

Authorities want to see clear responsibilities. This is not bureaucratic excess but a prerequisite for audits to be traceable. Crucial is that responsibilities are not only named but are operationally practiced and documented.

Which documents suffice as governance evidence?

• Organizational chart showing responsibilities for IT security and incident response.
• RACI matrix for critical processes (incident management, change, backup, supplier management).
• Mandated role descriptions: CISO/CRO scope of responsibilities, service owner responsibility.
• Minutes of governance meetings (e.g. CAB minutes, decision evidence for security‑relevant changes).

Documentation: which audit documents do you need specifically?

Audit documentation must be verifiable, versioned and retrievable. For auditors it is important how old a document is, who authorized it and whether it matches the current operational reality.

Must‑have documents

• Scope and system inventory: complete asset list with criticality, owner, location and version. (Asset = server, cloud service, network component, interface.)
• Risk assessment and action plan (with prioritization, owners and target dates).
• Incident response policy including reporting path, deadlines and escalation levels.
• Sample incident reports and confirmations of reporting to authorities (anonymized is allowed, originals are preferable).
• Change and release records including rollback protocols.
• Backup and recovery evidence: RESTore protocols, RESTore tests, RPO/RTO reports.
• Monitoring and SIEM configurations: use cases, alert definitions, dashboards.
• Configuration documentation: baselined configs, hardening checklists, patch reports.
• Supplier assessments, contracts and cybersecurity clauses.

Practical evidence examples

Auditors expect not only policies but their implementation. Example: For the patch policy a patch report is required that demonstrates patches were applied within the defined timeframes, plus a change record for critical outages.

# Beispiel: vereinfachte Evidence-Mapping-Tabelle (CSV-Format)
control,evidence_type,location,owner,retention
Patch-Management,Patch-Report,sysrepo/patch-reports/2026-07.csv,IT-Operations,3y
Incident-Response,Incident-Report,siem/archive/incidents/2026/,CISO,5y
Asset-Inventory,Asset-DB,gitops/assets.csv,Asset-Owner,10y

Logs, monitoring and SIEM: what is actually auditable

Logs are central evidence sources. Critical aspects are integrity (immutability or verifiable changes), time synchronization (NTP) and sufficient level of detail for forensic analysis.

Technical minimum requirements for log evidence

• Central log repository (SIEM/log store) with access control.
• Retention policy documented and implemented (e.g., WORM, write-once media or signed archival processes).
• Time-sync evidence (NTP/Chrony configuration and drift monitoring).
• Indexing and searchability: auditors must be able to reproduce selective queries.
• Proof of log integrity: hashes, signatures or storage snapshots with checksums.

A typical audit path: An auditor requests logs for an incident (timeframe + IDs). You present the extracted logs, the extraction query log and checksums. This includes an explanation of which filters were applied and who authorized the extraction.

# Beispiel: Log-Extraktion (kopierbar) - ersetze Parameter
# Extrahiere Nginx-Fehlerlogs für Host web01 zwischen zwei Timestamps
elastic-search-query --index=logs-* --match='host:web01 AND facility:nginx' --from='2026-07-01T00:00:00Z' --to='2026-07-01T12:00:00Z' > evidence/web01-nginx-20260701.json
sha256sum evidence/web01-nginx-20260701.json > evidence/web01-nginx-20260701.sha256

Automation of evidence collection

Manual compilation is error-prone and expensive. Automate extraction, hashing and storage in a tamper-evident archive, ideally via a CI/CD pipeline or orchestrator.

Best-practice steps

1. Define evidence packages per control (e.g., a patch-management package includes the list of patched systems, patch report, change ticket IDs).
2. Implement automated export jobs that produce the query, result and checksum.
3. Store artifacts in a read-only archive with metadata (owner, creation time, authorization).
4. Version policies and playbooks in Git with signed releases.

Mock audits and audit samples

Mock audits are essential to identify gaps. Conduct semi-annual exercises in which an external auditor or an internal team issues representative requests. Samples should simulate real evidence requests (e.g., logs for a specific incident, proof of backup RESTore).

Checklist for a mock audit

• Search time: How long does it take to obtain the requested documents?
• Completeness: Is metadata context, versioning or authorization missing?
• Integrity: Can the immutability of the evidence be demonstrated?
• Communication: Is the notification chain tested internally (who receives the request, who coordinates the response)?

Examples of audit documentation: templates and formats

Below is a compact incident-report template and an SQL example demonstrating how to filter asset inventory. These templates save time and ensure consistency in responses.

# Incident-Report-Template (kopierbar)
id: IR-2026-0001
date_time_detected: 2026-07-01T08:12:00Z
reported_by: SIEM-Alert-Rule-420
classification: security-incident / high
affected_assets: [web01, db-primary]
actions_taken: [isolate-host-web01, block-ip-198.51.100.23]
root_cause_summary: 'Unauthorisierte Anfrage über veraltete API-Endpunkt-Config'
notifications: [CISO, IT-Operations, Legal]
attachments: [evidence/web01-nginx-20260701.json, evidence/incident-shell.log]
next_steps: [forensic-image-db, change-hardening-api]

-- Beispiel: Asset-Inventarabfrage (Postgres)
SELECT asset_id, hostname, owner, criticality, last_patch_date
FROM assets
WHERE criticality IN ('high','critical')
ORDER BY last_patch_date ASC;

Supply chain, third-party evidence and contractual documentation

NIS2 requires due diligence in the supply chain. Auditors check whether third‑party risks have been assessed and contractual clauses on cybersecurity implemented. Relevant documents include assessment reports, current SLA reports, penetration test results from service providers and contract appendices with security requirements.

What you should have available for third parties

• Due‑diligence report and risk score for each supplier.
• Contractual security requirements and evidence of implementation (e.g., supplier audit reports).
• Communication logs during the incident: did the supplier notify in a timely manner?

Handling requests from authorities: deadlines, format and transparency

Authorities typically set deadlines for submitting documents. A coordinated response is important, combining technical evidence, a management summary and legal assessment. Internal escalation paths must be clarified beforehand.

Recommended operational procedure for authority requests

1. Formal acknowledgement of receipt by the security team and Legal.
2. Initial scope: which specific information is requested (timeframes, assets, formats).
3. Collect evidence packages according to predefined mapping.
4. Review by Legal/Compliance before submission.
5. Transparent logging of all steps (who submitted what and when).

Prioritization, effort and costs: how much is required?

Audit readiness is not purely an IT project but an organizational task. Prioritize by risk and regulatory relevance. The largest cost drivers are often:

• Implementation of centralized logging and SIEM.
• Automation of evidence exports and archives.
• Personnel resources for governance, legal review and audit management.

Budget decisions should be based on a cost‑benefit analysis: investment in automation reduces long‑term effort and audit risk.

Responsibilities in practice: who does what?

Typical allocation:

• Management / executive management: strategic decisions, budget, escalations.
• CISO / security officer: technical leadership, incident response, compliance mapping.
• IT management / Operations: implementation of technical controls, patch and backup reporting.
• Legal / Compliance: review of legal requirements, communication with authorities.
• Service owner / asset owner: provide technical evidence for their domain.

Quick‑Start-Checklist for the first 90 days

• Create an audit playbook: defines scope, contacts, tools and evidence packages.
• Inventory critical assets and prioritize them by business impact.
• Set up automated exports for the top‑5 controls (Logs, Patch, Backup, Change, Incident).
• Conduct an initial mock audit and document gaps.
• Define retention and integrity mechanisms for evidence.

Evidence‑Mapping: Process, Artifacts and Responsibilities

An evidence mapping assigns controls to concrete artifacts (e.g., Policies, Logs, Reports). Mapping creates transparency, reduces search times and establishes responsibilities. It is the basis for automated export jobs and for mock audits.

Steps for a robust Evidence‑Mapping

1. Identify controls according to NIS2‑categories (Governance, Risk, Incident, Technical Controls, Supply Chain).
2. Define an evidence package for each control: type, storage location, owner, retention and export query.
3. Document authorization rules: who may approve and send exports?
4. Automate export, hashing and archiving; store metadata (who, when, why).
5. Regularly test reproducibility: the same query must produce the same artifact.

# Chain-of-Custody Log (Beispiel CSV)
artifact_id,control,filename,created_by,created_at,sha256,stored_at,owner,access_notes
ART-0001,logs,web01-nginx-20260701.json,svc-log-export,2026-07-01T12:10:05Z,3a7bd3...,archive/worm/2026/,CISO,'Only read access to Legal'

Chain of Custody and Proof of Integrity

Chain of Custody describes how Evidence is created, transferred and stored. Auditors examine this proof to exclude tampering. Important elements are hashes (e.g., SHA‑256), timestamps and separate storage of hash lists.

Practical measures

• Generate hashes immediately after export and store hash and artifact separately.
• Use signed timestamps or timestamping services where possible to additionally substantiate the creation time.
• Store Evidence in a write-once archive (WORM) or in storage with audit logs about accesses.
• Maintain a Chain-of-Custody file that logs every access, every copy and every transfer.

Auditable Backup and RESTore Documentation

Backups are only auditable if RESTore tests are documented. Auditors expect evidence for successful RESTorations, including test protocols, involved personnel and times.

# RESTore-Test-Protokoll (Template)
RESTore_id: RST-2026-07-01-01
date: 2026-07-01
backup_source: backup-server-03:/archives/db-primary/2026-06-30
target: testlab/db-primary-RESTore
performed_by: Backup-Admin
steps:
  - mount backup
  - RESTore database to test environment
  - run data-consistency-checks
  - perform application smoke-tests
results: success
duration: 42m
issues: none
signed_by: IT-Operations-Lead

Data Protection and Evidence Disclosure: GDPR Interfaces

When disclosing logs or reports to authorities you must observe data protection requirements. Logs may contain personal data; anonymization or pseudonymization are standard measures here. Legal must review the disclosure and, if necessary, provide a legal basis.

Practical Guidance

• Pre-filter personal data and document which fields were removed or pseudonymized.
• Document the legal basis for data sharing (e.g., statutory reporting obligation, authority request).
• Set up an editorial review: Security provides technical evidence, Legal reviews and approves submissions.

National differences and authority practices

NIS2 is an EU directive and national authorities implement it differently. Auditors in different member states have varying expectations regarding formats, deadlines and scope. Therefore clarify early which national authority is responsible and which local requirements apply.

What to consider

• Ask about the preferred submission formats and deadlines of the responsible supervisory authority.
• Document country-specific deviations in your audit playbook.
• If you operate cross-border, clarify coordination and who will provide the lead response.

Risk-based prioritization and Quick Wins

Start where risk and effort diverge most: a basic SIEM setup and automated log exports are generally very effective measures. Quick wins often include:

• Automated hashing jobs for critical exports.
• A simple chain-of-custody protocol for evidence.
• RESTore tests for the most important backup sets.
• A concise incident report template that is ready for immediate use.

Implementation roadmap (concrete, 6 months)

1. Month 0–1: Define scope, finalize asset inventory, write audit playbook.
2. Month 1–3: SIEM baseline, export workflows, first automated evidence packages.
3. Month 3–4: Implement chain-of-custody process, set up WORM archive or read-only store.
4. Month 4–5: Conduct mock audit, close gaps, document RESTore tests.
5. Month 5–6: Introduce governance routines, establish regular audit cycles.

Conclusion: Audit readiness is organizational and technical

Audit readiness for NIS2 is more than collecting documents. Authorities expect traceable processes, automatable evidence pipelines and transparent responsibilities. Start with a pragmatic scope, automate recurring exports, and perform regular mock audits. This reduces audit effort, lowers operational risk and creates robust decision-making foundations for management and authorities.

FAQ

See the FAQ section below for quick answers to typical questions from IT and compliance officers.

For this topic, NIS2 evidence and compliance reporting are also important. This article places these aspects into context and shows what matters in day-to-day operations.