Glosario

NIS2 evidence

NIS2 evidence is the documented, auditable proof that an organisation's cybersecurity risk-management and incident-response measures required under the EU's NIS2 Directive are actually in place and followed — not the controls themselves, but records (logs, reports, approvals) that let a regulator, auditor, or customer verify they were applied.

The NIS2 Directive (EU 2022/2555) extends the EU's baseline cybersecurity rules to a much wider set of organisations than its predecessor — energy, transport, health, digital infrastructure, cloud and managed service providers, public administration, and more, split into "essential" and "important" entities with different oversight intensity. It requires risk-management measures (covering supply chain security, access control, incident handling, business continuity, encryption, and vulnerability handling), incident reporting to a national authority within tight deadlines (an early warning within 24 hours, a fuller notification within 72), and, for management bodies, personal accountability for oversight. EU member states transpose NIS2 into national law, so exact scope and enforcement details vary by country, but the underlying obligation is consistent: know your risks, manage them, and be able to show you did.

Having security controls and being able to prove you have them are different problems. A firewall rule, a patch policy, or an access-control model can exist on paper or in a dashboard without anyone being able to reconstruct, after the fact, who changed what, when, and under whose authorization. Evidence is what closes that gap: an append-only record of actions taken (not just current state), timestamped and tied to an identity, that survives being asked for during an incident-report deadline or a supervisory audit. Practically, this includes change and access logs that cannot be silently edited or backdated, records of who approved a given action, an inventory of what infrastructure exists and who is responsible for it, and documentation of data flows and sub-processors. Without it, "we have good security" is a claim; with it, it is a query someone else can run themselves.

Why NIS2 evidence matters

Under NIS2, failing to produce evidence when asked is not a technicality — in practice it can be treated the same as failing to have the control in the first place. Regulators can request records during a supervisory review, and boards face personal liability for inadequate oversight, so vague assurances do not hold up. The reporting deadlines make this worse: a 24-hour early warning after a significant incident leaves no time to reconstruct what happened from memory or scattered logs. Organisations that run infrastructure across several providers face a sharper version of the problem, because each provider's console produces its own logs in its own format, and stitching together "who did what, when" across all of them after the fact is exactly the kind of work an incident deadline does not allow.

How Sencai helps

Sencai keeps a single, append-only, hash-chained audit log of every action taken across every connected cloud account and on-premise server — who did it, when, and on what resource — regardless of which of the eleven supported providers it touched. That log is exportable, so "who changed this, and when" becomes a query instead of a reconstruction project. Sencai itself does not hold ISO 27001 or SOC 2, and says so directly; instead it hands over the evidence a review usually asks for — an audit-trail export, records of processing, a published sub-processor register, a data-residency statement, and a published Data Processing Agreement — from a company operating under EU law in Prague.

Explore security and compliance →