At every compliance conference the blockchain demo lands well: an immutable audit trail, cryptographically timestamped, non-repudiable. The promise is technically real. Yet in 2026 only 4 percent of European GRC teams run blockchain in production for compliance purposes (Gartner, 2025). The other 96 percent either abandoned the pilot or never scaled it. What they learned is worth stating.
What an audit trail requires, and why blockchain looks perfect
The audit trail is the foundation of NIS2, DORA and ISO 27001 compliance. A supervisor does not want your good intentions. They want evidence of past actions, timestamped, unalterable, attributable to who and when. Blockchain promises exactly that: immutability through distributed consensus, cryptographic timestamping, a chain of evidence nobody can rewrite.
The problem is not the technology. It is its fit with the real constraints of a European enterprise information system under regulatory pressure. Five use cases where the gap between promise and operational reality is widest.
Case 1: real-time system logs
The pitch: your SIEM logs are immutable on chain, unfalsifiable evidence in an incident.
The problem: logs come from your systems. If a system is compromised before the write, you have immortalised falsified data. Immutability does not guarantee source integrity. It guarantees that what was written will not change afterwards. In a sophisticated attack, that is precisely the wrong guarantee.
Latency compounds it: even Hyperledger Fabric, the enterprise reference, adds 300 ms to 1 s per transaction. In an environment producing tens of thousands of events per second, you will create gaps or batch, losing the granularity you were trying to preserve.
What works: append-only storage with S3 Object Lock in WORM mode, combined with an RFC 3161 timestamping authority. Same immutability, negligible latency, an order of magnitude less operational cost, readable by your auditors without specialist infrastructure.
Case 2: GDPR consent traceability
The pitch: immutable proof of consent, unassailable in a regulatory inspection.
The problem: GDPR Article 17 establishes the right to erasure. A public blockchain makes deletion impossible, which directly contradicts the regulation you are trying to meet. A private chain sidesteps the technical issue, but then decentralisation is centralised with you: it is a database with extra steps.
Data protection authorities have confirmed the point: blockchain-based consent systems require a specific impact assessment including an erasure mechanism, which cancels the immutability advantage. Two years of legal work to arrive back at the start.
What works: a SQL store with an internal hash chain, each entry hashing the previous one, plus an external timestamping authority. Equivalent legal weight, native erasure, standard impact assessment.
Case 3: privileged access management under DORA
The pitch: decentralised access control, maximum traceability of actions on critical systems.
The problem: DORA imposes operational resilience requirements that involve near real-time access decisions. Hyperledger Fabric latency in production, 200 to 500 ms for a confirmed transaction, is incompatible with production IAM service levels. For a bank, sub-100 ms is a necessity, not a preference.
DORA audits do not ask for on-chain access evidence. They ask for a privileged access register, timestamped, readable, with verifiable separation of duties. That is a PAM problem, not a distributed ledger problem.
What works: a PAM solution with session recording, signed logs, and immutable retention in a dedicated SIEM. Deployable in weeks, auditable without a blockchain interpreter.
Case 4: sharing audit evidence between organisations
On paper this is the most convincing case: share audit evidence with suppliers, subcontractors or regulators through a consortium chain. NIS2 explicitly requires third-party security management, and a shared register sounds elegant.
The problem: a consortium chain requires every party to adopt the same protocol, fund nodes, maintain cryptographic keys, and agree on governance. In practice you negotiate eighteen months of inter-company governance before writing the first transaction. Meanwhile your third parties have changed, your requirements have moved, and a secondary regulatory framework has appeared.
The enterprise blockchain consortia that reached production, TradeLens and We.Trade among them, were largely wound down between 2022 and 2024, for exactly these governance reasons.
What works: a secured API with mutual digital signatures plus contractual service level agreements. Equivalent evidentiary weight under European law, deployable in weeks, extensible without consortium consensus.
Case 5: automated regulatory reporting
The pitch: your NIS2 and DORA reports are generated automatically and cannot be falsified.
The problem: European supervisors accept PDF exports, structured files and electronically signed reports. None of them operate infrastructure to read blockchain transactions. Your immutable report will have to be re-exported into a conventional format anyway, losing most of the promised advantage while adding a layer your team has to maintain.
The DORA guidelines published in 2024 were clear: audit evidence must be readable, reproducible, and produced in standard formats. Technological innovation is not a compliance evaluation criterion.
What works: a GRC workflow with qualified electronic signature under eIDAS. Full legal weight in European law, accepted without reservation by every EU regulator, available in any modern GRC tool.
The question to ask before any blockchain GRC project
Blockchain is not useless. It excels precisely where no central trusted authority can exist: public cryptocurrencies, cross-border interbank settlement without a shared clearing house. There, distributed consensus solves a real problem.
In most European enterprise GRC architectures, that condition does not hold. You are the central authority. Your CISO, your DPO, your CIO are identified parties. Simpler, cheaper, already audited solutions, WORM storage, RFC 3161 timestamping, eIDAS signature, certified PAM, meet the regulatory objective at a fraction of the cost and complexity.
The question to ask: what does this solve that a signed, timestamped database could not? If the answer is not immediately clear, you have your decision.
Conclusion
Three things to keep. Immutability is not integrity: if your data source is compromised before the write, blockchain immortalises a falsification. Decentralisation is a poor fit for enterprise systems that are centralised by nature, and a private chain is a database with extra steps. And simple alternatives cover 95 percent of EU regulatory needs: WORM storage, RFC 3161, eIDAS, certified PAM.
Organisations that reach NIS2 and DORA inspections with solid audit trail architectures are not the ones that bought the most impressive technology. They are the ones that picked the right technology for the right problem.
Read next: TPRM 2026: seven pitfalls when mapping third parties.