NIS2 audit logging requirements and how to satisfy them

The control

NIS2's 24-hour early-warning and 72-hour incident-report deadlines only work if the underlying event log is trustworthy enough to build a timeline from quickly: an authority checking incident reports will often want to see the logging evidence behind the timeline, not just the report.

What an auditor asks for

A NIS2 competent authority or your own security team investigating an incident wants a log they can trust wasn't altered after the fact, not one where "trust us" is the only integrity guarantee, cryptographic proof the record is unchanged, not a policy stating that logs are protected.

Retention requirement

AuditRails retains NIS2 audit logs for a minimum of 5 years by default. Retention extends automatically if you're also subscribed to a framework with a longer requirement.

What AuditRails captures

Incident-detection events capture severity and category directly, so the timeline an authority asks for during the 24-hour early-warning window can be reconstructed from the log itself.

import { AuditRails } from '@auditrails/node';

const audit = new AuditRails({ apiKey: 'at_live_...' });

await audit.log({
  action: 'incident.early_warning',
  actor_id: '...', // required
  metadata: {
    incident_id: '...', // required
    authority: '...', // required
    suspected_malicious: '...', // optional
    cross_border: '...', // optional
    notification_id: '...', // optional
  }
});

What you hand your auditor

Generate an evidence bundle for your audit window and you get a zip containing a PDF summary report, the full event log as NDJSON, and a manifest with SHA-256 checksums of both files plus a hash-chain proof: exactly the cryptographic integrity evidence NIS2's own control text asks for, not a claim you have to make on faith.

Common ways teams fail this control

• Logging that an incident was detected, but not its severity or affected systems. NIS2's tight reporting deadlines need a record detailed enough to draft a timeline from immediately, not after the fact.
• No hash-chaining or equivalent integrity mechanism on the log store at all. NIS2's own control text specifically names cryptographic measures, not just access controls, as the expected safeguard.
• Logs editable by the same administrators responsible for the systems they describe, with no separation of duties: an authority testing integrity finds the same people who could cause an incident can also edit its record.
• Retention shorter than 5 years, missing NIS2's own documentation-retention expectation.
• No consistent actor_id across systems, making it hard to reconstruct a full incident timeline from logs that were never designed to be correlated.

Frequently asked questions

This page describes regulatory obligations for information purposes and does not constitute legal advice. Whether they apply to your organisation should be confirmed with your own advisers.