Immutable logs for NIS2, ISO 27001 and Spain's ENS: how to anchor syslog on a public blockchain
Equipo Proovik · Sep 17, 2026 · 9 min read
An immutable log is an activity record whose integrity can be checked by someone other than its administrator. It is achieved by chaining each block of records to the hash of the previous one and periodically anchoring that hash on a public proof-of-work blockchain, so that altering or deleting an old entry breaks the chain and contradicts a timestamp nobody controls. NIS2, ISO/IEC 27001 and Spain's ENS all require protected activity logs; anchoring is how you demonstrate that protection.
This article extends Immutable audit logs: syslog to blockchain with what the three most common compliance frameworks in Spain and the EU ask for, and with a concrete architecture. It belongs to Proovik's independent-verification cluster; the foundation of the seal is in What is a blockchain timestamp?.
Why logs are the first thing an attacker touches
Whoever breaks into a system and wants to stay deletes or edits the records. Whoever holds administrator privileges and makes a mistake, or worse, faces the same temptation. And when an audit or an incident notification comes, the question is not whether you have logs, but whether they are the same ones that were generated. A SIEM with write permissions for the systems team does not answer that question; it only repeats what that team may have changed.
Log integrity has two components: that no entry has been modified (content integrity) and that none is missing or was inserted afterwards (sequence integrity). A hash per file covers the first; an anchored hash chain covers both.
What each framework requires
| Framework | Requirement on logs | What anchoring adds |
|---|---|---|
| NIS2 (Directive (EU) 2022/2555), Article 21 | Risk-management measures, including incident handling and policies to assess the effectiveness of the measures | Evidence that the records used in an incident investigation are the originals |
| NIS2, Article 23 | Early warning within 24 hours, notification within 72 hours and a final report within one month of becoming aware of a significant incident | A verifiable date of when the incident was detected and of which records existed then |
| ISO/IEC 27001:2022, Annex A, control 8.15 | Produce, store, protect and analyse logs of activities, exceptions, faults and relevant events | Protection that is demonstrable, not just declared, against alteration and deletion |
| ISO/IEC 27001:2022, controls 8.16 and 8.17 | Monitor networks and systems; synchronise clocks with an approved time source | An external time reference (the block timestamp) against which internal clocks can be checked |
| ENS (Royal Decree 311/2022), op.exp.8 | Log user activity, with date, time and action performed | Same as 8.15: the log exists and is complete |
| ENS, op.exp.10 | Protection of activity logs: integrity, access control and retention | Integrity verifiable by the auditor without privileged access to the platform |
None of the three frameworks requires blockchain. All three require logs to be protected in a way that can be demonstrated. A write-once (WORM) store, a separate log server or an HSM meet part of it; none lets an external auditor verify integrity without trusting whoever administers that mechanism.
Architecture: chain and anchor
The design is the same with rsyslog, syslog-ng, journald or a cloud SIEM. What changes is where the hashing step runs.
- Rotate in short windows. Close a log file every hour (or every five minutes if volume or risk demands it). A short window narrows the interval in which an alteration would go unnoticed.
- Hash every closed file. SHA-256 over the compressed file, already immutable on disk.
- Chain. Each window manifest includes the file hash, a sequence number and the hash of the previous manifest. A manifest without a valid predecessor is an alarm.
- Anchor. Send the manifest hash to a public proof-of-work blockchain. The block timestamp is the upper bound of when that state of the chain existed.
- Keep files, manifests and proofs in storage separate from what the systems team administers. Proofs are small: they can be replicated in several places.
A window manifest can be as simple as this:
{
"window": "2026-09-19T10:00:00Z/2026-09-19T11:00:00Z",
"sequence": 4127,
"file": "syslog-2026-09-19T10.log.gz",
"file_sha256": "3b8f1c0c4c2e7a9d5f6b1a2c3d4e5f60718293a4b5c6d7e8f9a0b1c2d3e4f5a6",
"prev_manifest_sha256": "9e107d9d372bb6826bd81d3542a419d6b0f2a1c3d4e5f60718293a4b5c6d7e8f",
"entries": 184233,
"host": "log-collector-01",
"anchor": {
"network": "kaspa",
"txid": "pending",
"block_timestamp": null
}
}After anchoring, the anchor field is completed with the transaction identifier and the block timestamp, and the manifest is stored next to the proof certificate.
How an auditor verifies without trusting you
- Take any log file and its manifest.
- Recompute the file hash and compare it with file_sha256.
- Recompute the manifest hash and check that it appears in the anchored transaction, that the transaction is in the block and that the block header satisfies the proof of work. All of that is in the proof package.
- Check that prev_manifest_sha256 matches the hash of the previous manifest, and walk backwards as far as needed.
If someone edited an entry from three months ago, the file hash no longer matches. If someone deleted a whole file, a link in the sequence is missing. If someone rewrote the whole chain, the hashes no longer match what is in the blocks, and the blocks cannot be changed without redoing the work of every later block.
Complements: signing and clock synchronisation
Anchoring proves integrity and date, not origin. To know that a file was produced by a specific collector and not another, sign each manifest with a collector key; RFC 5848 additionally defines signing of individual syslog messages. And keep clocks synchronised (NTP or PTP with a trusted source): the block timestamp is the external reference, but log entries carry local time, and a large drift weakens correlation.
What the law and the standards say
Directive (EU) 2022/2555 (NIS2), Article 23(4): essential and important entities shall submit an early warning without undue delay and in any event within 24 hours of becoming aware of the significant incident; an incident notification within 72 hours; and a final report not later than one month after the incident notification. Article 21 lists the risk-management measures, among them incident handling and policies and procedures to assess the effectiveness of the measures.
ISO/IEC 27001:2022, Annex A: control 8.15 (logging) requires producing, storing, protecting and analysing logs of activities, exceptions, faults and other relevant events; 8.16 (monitoring activities) and 8.17 (clock synchronisation) complete the requirement. The standard is paid and its text is not reproduced here.
Royal Decree 311/2022 (Spain's National Security Framework, ENS), Annex II: measure op.exp.8 (activity logging) requires recording user activity in the system, and op.exp.10 (protection of activity logs) requires protecting those logs, including their integrity, with requirements that increase with the system's category.
Regulation (EU) 910/2014 (eIDAS), Article 41(1): an electronic time stamp cannot be denied legal effect or admissibility as evidence solely for being electronic or non-qualified. Anchoring a manifest is a non-qualified electronic time stamp over that manifest.
How to do it with Proovik
Proovik's API receives the SHA-256 hash of the manifest (never the file) and writes it in a transaction on the Kaspa network, which produces about ten blocks per second, so the seal is normally confirmed within seconds; it returns the transaction identifier and the block timestamp, and lets you download the PVK-PROOF/1 proof package and a PDF certificate. Verification is done without Proovik using the specification and the reference verifier on the verify page. For a first manual trial, the certify page accepts any file. If you want us to review your anchoring architecture, write to us through contact.
What it proves: that this manifest, and therefore this log file, existed no later than the block timestamp and has not changed. What it does not prove: that the log is complete or truthful (an entry that was never written leaves no trace), or that you comply with NIS2, ISO 27001 or the ENS; those frameworks demand policies, procedures and audits. Anchoring is the integrity evidence those audits ask for.
Frequently asked questions
Do I have to anchor every log line?
No. You anchor the hash of each window (for example, each hour). An alteration in any line changes the file hash and, with it, the manifest hash. The cost is one transaction per window, not per entry.
What about logs between two anchors?
During the open window the file is not yet sealed. That is why the window should be short and the file should be closed and sealed as soon as it rotates. An alteration within the current window would not be detected by anchoring, only by other controls.
Do my logs leave my network?
No. Only the 32-byte hash travels to the API. The content of the records, which may include personal data, stays where it is.
Does it replace a WORM store or a SIEM?
No. It complements them. The SIEM analyses; the WORM store prevents writes; anchoring lets a third party check that nothing changed, without trusting the SIEM, the WORM store or whoever administers them.
Sources
- Directive (EU) 2022/2555 (NIS2): eur-lex.europa.eu/eli/dir/2022/2555/oj
- Royal Decree 311/2022, Spain's National Security Framework (BOE, Spanish): boe.es/eli/es/rd/2022/05/03/311/con
- ISO/IEC 27001, official ISO page: iso.org/standard/27001
- RFC 5848, Signed Syslog Messages: rfc-editor.org/rfc/rfc5848
- RFC 5424, The Syslog Protocol: rfc-editor.org/rfc/rfc5424
- Regulation (EU) 910/2014 (eIDAS): eur-lex.europa.eu/eli/reg/2014/910/oj
Proovik team. Published 19 September 2026; last reviewed 6 September 2026.