Ask an infrastructure team what NIS2 compliance evidence looks like and you usually get a policy pack: an information security policy, an incident response plan, a supplier questionnaire, all signed and versioned. Those documents matter, but they are not evidence. They describe what you intend to do. Evidence is the record of what you actually did - who changed the firewall rule, when, on whose authority, and what the configuration was before. Assessors ask for the second thing, and the gap between the two is where most teams get uncomfortable.

A quick recap of what we are dealing with. NIS2, formally Directive (EU) 2022/2555, had a transposition deadline of 17 October 2024, and national laws have been landing on their own schedules since. It widened the scope well beyond the old NIS categories, pulled supply chains in explicitly, and attached obligations to management bodies personally rather than to an abstract organisation. If you supply anything to an in-scope entity, expect their obligations to arrive on your desk as contract language, whether or not you are directly in scope.

What the directive actually asks for

Article 21 lists the risk-management measures: policies on risk analysis and information system security, incident handling, business continuity and backup, supply chain security, security in acquisition and development, procedures to assess effectiveness, basic cyber hygiene and training, cryptography, access control and asset management, and multi-factor authentication. Read that list as a set of questions you will be asked to answer with records. Every item ends in the same follow-up from an assessor: show me. Show me the backup you restored, the access you revoked, the change you approved.

Article 23 is the one that changes engineering rather than paperwork. An early warning within 24 hours of becoming aware of a significant incident. A fuller notification within 72 hours, including an initial assessment of severity and impact. A final report within one month. Those clocks start when you become aware, which makes your detection timeline part of the evidence itself. If you cannot say when you knew, you cannot demonstrate that you reported on time - and an incident timeline reassembled from memory a week later convinces nobody.

NIS2 compliance evidence is a record

Here is the practical shape of what an assessor asks for. A list of systems in scope and who owns each one. A record of changes to security-relevant configuration over a stated period. Proof that access was granted, reviewed and removed, with dates. Evidence that backups were not only taken but restored. And for every significant incident, a timeline you can defend: detection, escalation, containment, notification. All of it dated, attributable to a named identity, and produced from something other than a person's recollection.

The awkward truth is that almost all of this already exists somewhere in every company. It is in a ticket system, a chat channel, three consoles, one engineer's terminal history and a spreadsheet. Compliance work then becomes archaeology: two weeks of somebody reconstructing what happened from artefacts that were never designed to be evidence. That is expensive, it is demoralising, and it produces a document nobody entirely trusts - including the person who assembled it.

The property that makes a log evidence

A log becomes evidence when it is append-only and tamper-evident. The distinction matters more than it sounds. A table an administrator can update is a record of what that administrator wants you to believe. What an assessor wants is a sequence in which any modification to an earlier entry is detectable, without having to trust whoever operates the system - including us. That property is what turns "here are our logs" into something a third party can rely on rather than merely receive.

Sencai's audit trail is append-only and hash-chained. Every entry carries its own hash and the hash of the entry before it, so the records form a chain rather than a pile. The CSV export includes both values, entry_hash and prev_hash, which means your auditor does not have to take our word for anything. They can recompute the chain themselves, offline, with a script they wrote, and see whether it holds. If a single entry had been altered or removed, the recomputation stops matching from that point onward.

Supply chain questions you will be asked

Article 21 puts supply chain security in the list, and Article 20 makes management personally accountable for approving and overseeing those measures, which is why these questions now arrive with real weight behind them. Expect to be asked which subprocessors touch your data, in which jurisdictions they operate, how you would detect a compromise originating with one of them, and how quickly you could remove one. If you cannot enumerate your providers today, you cannot answer any of it - and an incomplete inventory is the fastest way to fail this section.

This is where per-organisation isolation and a real role model stop being product features and become audit answers. Who can create infrastructure, who can only view it, who invited whom and when, and which of those invitations were actually accepted rather than merely sent - these are questions with dates attached. The same applies to the configuration that genuinely protects you: firewall rules, network boundaries and DNS records, each with a record of who changed them at the provider, and when.

How to prepare without a compliance department

Start by writing down the questions you would struggle to answer in a room with an assessor. Usually there are four: what do we run, who can touch it, what changed last quarter, and how do we prove any of it. Then fix the recording, not the reporting. A system that captures the answers as the work happens costs almost nothing at the time; reconstructing them afterwards costs weeks, every single time. NIS2 did not create that gap - it just made it expensive to keep.

None of this makes compliance pleasant. It does change its shape. Evidence you can export, hand to an auditor and let them verify independently is a very different conversation from a folder of screenshots and a promise that nothing was edited. That is the bar we built for: your estate in one place, changes recorded as they happen, and an export designed to be checked by someone whose entire job is to doubt it.