Skip to content


Harry Cassin
Publisher and Editor

Andy Spalding
Senior Editor

Jessica Tillipman
Senior Editor

Bill Steinman
Senior Editor

Richard L. Cassin
Editor at Large

Elizabeth K. Spahn
Editor Emeritus

Cody Worthington
Contributing Editor

Julie DiMauro
Contributing Editor

Thomas Fox
Contributing Editor

Marc Alain Bohn
Contributing Editor

Bill Waite
Contributing Editor

Russell A. Stamets
Contributing Editor

Richard Bistrong
Contributing Editor

Eric Carlson
Contributing Editor

Vera Cherepanova: Can GDPR and blockchain ever coexist?

The General Data Protection Regulation (GDPR) came into effect in May. With the risk of hefty fines, it’s no surprise that GDPR compliance tops the agenda for many organizations. But one area of technology faces even greater challenges under GDPR: blockchain.

The tension comes from the definition of personal data in GDPR terms, and how the personal data is stored on the blockchain, thereby triggering the applicability the GDPR requirements.

Some solutions are now claiming to be GDPR compliant, while commentators argue that blockchain and GDPR are mutually exclusive concepts.

In this post and the next one, I make an attempt to understand where the truth falls — that is, what complying with GDPR means for blockchain operators.

Distributed ledger processing. GDPR was first proposed by the European Commission in 2012 at a time when blockchain technology was mostly limited to cryptocurrencies. The regulation, therefore, follows the centralized logic when data is collected, processed, and stored on one server or a group of managed servers — the data controller/processor. Under Article 4, the data controller is the party that determines the purposes and means of processing of personal data, whereas the processor is the party which processes personal data on behalf of the controller. Many “data subjects” (i.e. individuals) interact with a single data controller/processor, the latter two held accountable for the underlying processing of personal data.

However, articulating the logic of the GDPR and the blockchain, using the “data controller/processor” vs “data subject” divide, seems difficult. In a distributed ledger system, anyone who joins the peer-to-peer network and runs the software becomes a “node.” The nodes process data without having full control over how the system works. At the same time, the party which originally designed the software doesn’t necessarily process any personal data itself through the blockchain. Apparently, in GDPR terms, this party would be a data controller, whereas every node would be a data processor.

If this is true, then under Article 28(3) these parties are supposed to conclude a controller-processor agreement which would govern the data processing performed by the node. This doesn’t sound like a feasible solution. Although decentralized transaction processing employed by blockchain systems removes the vulnerabilities commonly exploited in centralized data repositories, it appears to be at odds with the GDPR logic.

The network of nodes, each keeping a local copy of the blockchain, provide transparency to the whole system as any transaction processed is visible to all nodes and can be independently viewed and verified. However, it obviously takes a toll on privacy. Under Article 15 the data subjects have a right to obtain from the controller confirmation as to whether or not their personal data is being processed, including the information on recipients to whom the personal data have been or will be disclosed. This could never be guaranteed in a public blockchain.

The right to be forgotten. Under Article 16 the data subject has the right to ask the data controller to correct his or her personal information in case it is inaccurate (the “right to rectification”).

Under Article 17(1) the data subject has the right to request from the data controller to erase his or her personal data, thereby exercising “the right to be forgotten” for the reasons including the following:

  • If the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed (Article 17(1)(a)). Under Article 5(1)(e) personal data will be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed (“data minimization principle”).
  • If the data subject withdraws consent on which the processing is based. Under Article 7(3) the data subject has the right to withdraw his or her consent to the processing of his or her personal data at any time.

With blockchain, however, an immutable ledger of data when each “block” contains a hash of the previous one (“proof chain”) cannot offer that level of flexibility by design.

Blockchain is a system where the trust is built into the architecture: the immutability of transactions it contains means that people can’t simply change/remove inconvenient information at will. This is a key factor to ensure this trust. Therefore, if personal information is stored on an immutable ledger, it cannot be modified or erased to meet GDPR requirements.


In my work with GDPR and blockchain, I’ve come to a clichéd yet relevant conclusion: complexity is the enemy of security. In this case there are no perfect solutions, only strategies to help us reconcile the two competing forces. I’ll discuss those strategies in the next post.


Vera Cherepanova, FCCA, CIA, MSc (pictured above), has more than 10 years’ experience as a compliance officer. She’s the founder of Studio Etica, a boutique consultancy that provides advice on corporate ethics and compliance programs to companies around the world. She speaks English, French, Italian, and Russian. She can be contacted here.

Share this post


Comments are closed for this article!