The future of storage is no longer about raw capacity, but about the ability to demonstrate, over time, the integrity and chronology of preserved data.
A concrete use case
A French company overseeing industrial networks deploys an AI-based behavioural analysis module. During a NIS2 audit, inspectors ask: "Can you demonstrate that the datasets used for model training on 15 January 2025 have not been altered and are associated with the required retention policy?"
The company only has a CSV file on a network share. No versioning, no qualified timestamping, no immutability. The file exists, but its authenticity cannot be proven. The audit fails.
The NIS2 shift
| Aspect | Before NIS2 | After NIS2 |
|---|---|---|
| Approach | Policies and tools in place, evidence based on "we have a firewall" | Proving every decision, action, and control, dated and attributed |
| Accountability | Delegated to technical teams | Management (CISO, DPO, executive committee) bearing ultimate responsibility |
| Required evidence | No framework, documents for guidance purposes only | Reliable, dated, traceable evidence protected against tampering (Art. 13-14) |
Expected qualities of evidence
- authenticity: the document originates from the declared source;
- integrity: no elements modified since creation (hashes, signatures);
- traceability: every read or modification logged with identity;
- qualified timestamping: legally recognised timestamp;
- attribution: the author or system is clearly identified;
- contextualisation: the evidence fits within a business process;
- availability maintained for the required legal duration;
- long-term readability: sustainable formats independent of vendors;
- independent verifiability by a third-party auditor.
The limitations of ordinary documentation practices
The mere presence of a file is never sufficient to establish its authenticity, date, or integrity. A shared folder can be modified silently. A renamed file loses its history. A spreadsheet does not preserve differences between versions. An administrator account can erase traces without leaving a log.
Immutability as a trust mechanism
| Mechanism | Operation | Contribution to evidence |
|---|---|---|
| WORM storage | No rewriting possible after initial write | Guarantees non-alteration since deposit |
| Append-only log | Append-only writing | Exact sequence reconstruction |
| SHA-256 fingerprints | Separate hash or recorded in private blockchain | Detects any minor modification |
| Merkle chaining | Each entry incorporates the previous hash | Rapid global verification |
| GPG-signed Git | Signed timestamped commit + tag | Author and date associated with each version |
| S3 Object Lock | Server-side deletion/modification blocking | WORM compliance without dedicated hardware |
These mechanisms are complementary: immutability ensures non-alteration, encryption guarantees confidentiality, and electronic signatures attest to the producer's authenticity.
The chain of custody, from time zero to archiving
- automated creation or collection (log export, report generation);
- source identification via metadata and UUID;
- qualified timestamping via a recognised TSA;
- hash calculation and storage in an immutable ledger;
- deposit into a WORM bucket or Object Lock storage;
- classification by sensitivity and retention policy;
- RBAC access control with consultation logging;
- periodic verification (monthly hash recalculation);
- consultation or export as a timestamped archive;
- end of life: secure destruction or Legal Hold according to procedure.
Evidence Register - operational example
| Category | Source | Frequency | Format | Retention |
|---|---|---|---|---|
| Network logs | SIEM | Continuous | JSON append-only | Minimum 6 months |
| Security policies | Git repo | At each update | Signed Markdown | 5 years |
| Incident reports | Incident file | Post-event | PDF + signatures | 10 years or legal closure |
| Staff training | LMS | Monthly | CSV export + hash | 3 years |
The limits that should not be masked
- false immutability: a sealed file may contain erroneous data from the moment of its creation;
- source quality: a biased or illegally collected dataset remains non-compliant despite archiving;
- retention conflicts: indefinite retention may violate the GDPR right to erasure;
- immutability ≠ prevention: protection only occurs in the post-incident phase;
- local vs qualified timestamping: only the latter provides legal probative value.
What KARL brings to this strategy
KARL natively applies versioning, WORM immutability and traceability on S3 storage. The temporal layer is integrated: every past state of the system can be replayed, and every piece of evidence exported with its timestamp and hash. Storage ceases to be a simple container and becomes a source of truth.
Find out more
Find out more:
Read the Challenges article on KARL →