The Challenge of Compliance
When the EDPB adopted Guidelines 02/2025 on July 7, 2026, it addressed a key issue: can an immutable ledger comply with a regulation that requires data deletion? For your team evaluating blockchain implementations, this isn't just theoretical. You must acknowledge that blockchain's core architecture creates compliance challenges with Articles 5, 15, 16, and 17 of the GDPR, or risk a supervisory authority intervention.
The guidelines are clear: "technical impossibility cannot be invoked to justify non-compliance with GDPR requirements." This closes the argument that blockchain's tamperproof design excuses it from erasure obligations. The real question is whether the EDPB's proposed workarounds are practical or merely symbolic.
The Argument for Compliance
Advocates for blockchain's compatibility with GDPR point to tools like encryption with key deletion, salted hashing, and cryptographic commitments. If you encrypt personal data before adding it to the blockchain and delete the decryption key upon an erasure request, the data becomes inaccessible. This approach meets the functional test for erasure under GDPR, even if not the literal one.
Similarly, hashing personal data with a secret salt and storing that salt off-chain can achieve effective unlinkability. The EDPB supports this, provided the hash algorithm is strong, the salt is random and long, and the off-chain storage is secure and erasable.
Blockchain's transparency and integrity features also offer compliance benefits. Audit trails are tamperproof, and data lineage is clear. Breach detection is faster when every node sees every transaction. For use cases like supply chain traceability or consent logging, these properties can enhance your Article 5(1)(a) transparency obligations and Article 5(2) accountability. The focus shifts from "can we use blockchain?" to "can we design it correctly?"
The Argument Against Compliance
Critics argue that the EDPB's solutions don't solve the problem; they just shift it and add complexity. Encrypting data requires a separate key management system, which has its own risks and obligations. If the key leaks or the encryption weakens, the data is exposed. The guidelines acknowledge that encrypted personal data remains personal data, and encryption has a limited lifespan.
Hashing with a secret salt also has vulnerabilities. The off-chain database holding the salt processes personal data and requires security measures, a retention schedule, and breach procedures. If the salt is compromised, the hash on the ledger becomes linkable, and you can't remove it.
The deeper issue is retention. The EDPB states that blockchain's immutability "is not a reason to assume that the lifetime of the blockchain is an appropriate data retention period." Retention must be purpose-driven. If indefinite storage isn't necessary, personal data shouldn't be on the chain unless anonymized from the start. This is challenging, as most implementations include metadata that could identify data subjects through off-chain records.
Practical Approaches
In practice, many DPOs are categorizing blockchain use cases. For high-value scenarios where blockchain's properties solve a business problem, they're building the off-chain architecture needed for encryption or hashing: secure key vaults, documented destruction procedures, and ongoing cryptographic monitoring. Here, the blockchain serves as a verification layer, not a data store. Personal data remains off-chain, with only hashes or encrypted references on the ledger.
For other cases, they're opting out. The compliance burden isn't justified when a traditional database with proper controls achieves the same result with less hassle. The EDPB's guidelines make it clear that blockchain doesn't get a regulatory pass, leading many to abandon pilots.
Conclusion
Blockchain can comply with GDPR, but only if you treat the blockchain as a narrow-purpose integrity layer and manage compliance off-chain. Using the ledger as your primary data store creates unsolvable retention issues unless you achieve effective anonymization from the start or maintain a robust key management system.
The EDPB's guidelines rightly dismiss technical impossibility as an excuse, but they don't simplify blockchain compliance. They make it feasible, requiring significant architectural discipline and ongoing cryptographic vigilance. If your team can't commit to this, blockchain isn't a GDPR-compatible choice for your use case.
