Provability
NIS2 and your software: what you actually have to produce in an audit.
The directive states what you owe. It does not state how the software must be built so you can prove it. This page translates the duties into architecture requirements — and into what ends up on the table on audit day.
Most teams have documentation. Few have evidence.
After an audit finding we hear the same sentence in almost every conversation: “But we documented all of it.” Usually true. An auditor, however, does not ask for a description of a process. They ask for proof that it ran that way in one specific case — on a given day, for a given record, by a given person.
No directive and no concept paper answers that question. The system does. If it does not produce the evidence itself, the evidence gets reassembled by hand from logs, backups and memory. That is where NIS2 becomes expensive — not in implementing the measures, but in recovering proof that was never created.
The expectation itself is not new. What is new is that management is personally accountable and that reporting deadlines are measured in hours. Both move the requirement out of the organisation and into the architecture.
From duty to architecture requirement.
The left column is in the directive. The middle one is what your system has to be able to do. The right one is what you produce when asked.
| NIS2 duty | What the system must do | What you produce |
|---|---|---|
| Risk management and effectiveness of measures (Art. 21) | Security-relevant state changes are captured as domain events, not only as technical logs. | A complete, time-ordered history of security-relevant operations — machine-readable rather than a screenshot. |
| Reporting: early warning within 24 hours, notification within 72 hours (Art. 23) | Impact can be narrowed down within hours: which tenants, which records, which time window. | A reconstructable answer to “who was affected and from when” — derived from history, not estimated. |
| Access control and identity management (Art. 21(2)) | Roles, permissions and their changes are versioned and attributed to an accountable person. | Who held which permission when, who granted it, and on whose approval. |
| Security in acquisition, development and maintenance | Changes to code, configuration and permissions follow the same chain of evidence as business data. | Provenance of every change: trigger, approval, timestamp, released version. |
| Supply chain security | Dependencies and their access to your data are modelled explicitly, not granted implicitly through network access. | Proof of which vendor and which third-party system accessed which data, and when. |
| Management accountability and oversight (Art. 20) | The current picture can be queried without developer help — reporting is part of the system. | Regular evidence generated by the system instead of a hand-maintained sheet. |
This mapping is our implementation view, not legal advice. Which duties apply to you depends on sector, size and the national transposition law — implemented differently in Austria and Germany.
The four gaps we keep finding.
Not in weak teams. In systems built before provability was a requirement.
Logs anyone can change
Logging goes into the same database as the business data, writable by the application user. Technically clean, worthless as evidence: no auditor accepts a history the same instance can rewrite.
State without reason
The table says a record is approved. It does not say who approved it, when, and on what basis. Good enough for operations. Not for a question about a specific date.
Tenant separation as a filter condition
Isolation comes from a WHERE clause in application code. One forgotten filter is a reportable incident — and the proof of separation is a code review, not evidence.
Permissions without history
The current permission model is known. The one from eight months ago is not. That is exactly what gets asked after an incident.
How we close the gap.
Not as a full rebuild. At the process that hurts when it matters.
1 — Assess what you can actually prove
We walk through the concrete questions an auditor or a large customer asks and mark which ones your system answers today. The result is a list with effort and risk per gap — not a presentation.
2 — The most critical slice first
One process gets an immutable history and a clean permission model. Small enough to run in production within weeks, large enough to count in an audit.
3 — Make identity and tenant separation provable
Permissions get versioned, isolation gets enforced technically instead of by filter — with Keycloak where sovereignty over identity is required.
4 — A handover with a name on it
Someone internal owns it afterwards. We document for the person who has to pass the next audit without us.
When this fits — and when it does not.
Fits when
- an open audit finding cannot be closed cleanly in-house
- a large customer demands tenant separation, SSO and audit trails
- an incident revealed that your history does not hold up
- a new domain system is being built and provability should be designed in
Does not fit when
- you need a certification or a formal opinion — that is an auditor's job, not ours
- you are looking for legal advice on whether NIS2 applies to you
- there is no trigger and the topic is just “modernisation”
- you are looking for development capacity by the hour
Frequently asked
- Isn't a tamper-proof logging tool enough?
- For infrastructure events, often yes. For domain questions, rarely: a log entry says an update ran, not that a credit check was skipped. It becomes provable when the business decision itself is recorded as an event.
- Do we have to rebuild the whole system?
- No, and we usually advise against it. Provability pays off where the questions are asked — typically one to three processes. The rest stays as it is.
- What does event sourcing have to do with NIS2?
- As a pattern, nothing. As an answer to “can you prove immutably who changed what and when”, it is the most direct shape. Simpler routes exist and we say so when they suffice.
- How long does an assessment take?
- Two to four weeks, depending on how many systems touch the affected process. You get a prioritised gap list you can act on without us.
- Do you advise on whether NIS2 applies to us?
- No. Scope is a question for your legal counsel or the competent authority. We start once it is clear that evidence is required.
Sources
We cite the consolidated legal texts so you can verify every statement yourself.
Do you know which of these questions your system answers today?
The provability check walks through ten questions an auditor will ask. Ten minutes, no sign-up, result right away.