Depending on who you listen to, the combination of GDPR and distributed ledger technology (DLT, AKA blockchain) is either a poisonous cocktail or a magic potion. As you’d expect, the reality is more nuanced: While GPDR poses a challenge to DLT-based architectures, it doesn’t make them obsolete or unviable. Furthermore, DLT can actually form an integral part of an organization’s GDPR compliance program.
Here’s what you need to take into consideration (or ignore at your peril):
- Public blockchains and GDPR really don’t go together, at least not today. There are several reasons for this. For example, there’s no support for data privacy in the main public blockchains (ways of addressing this remain in their infancy); it’s not possible to appoint a data controller in an environment where (nominally at least) nobody is in charge; you can’t control data processing and storage locations; and there’s no way of exercising one’s right to be forgotten. Finally, encrypted and hashed data is still personal data. Only fully anonymous data is exempt from the rules, but this doesn’t apply to the techniques used on the main public chains today, which are pseudonymous; it requires technical skills, but it’s possible to identify individuals by using a combination of other data and pattern analysis.
- Don’t expect the EU to grant exceptions. There have been some calls for the EU to relax GDPR compliance requirements in order not to stifle innovation. While the EU is on the whole positively disposed toward DLT, it won’t tear a great big hole into GDPR legislation to accommodate a specific technology concept.
- Design permissioned/private DLT-based networks with GDPR in mind. And that means right from the beginning — unless you’re very lucky — you won’t be able to retro-fit GDPR compliance and will have to start again from scratch. While DLT platforms designed specifically for enterprise use typically offer support for confidentiality, this doesn’t automatically amount to GPDR compliance. Take a privacy-by-design approach, and make sure you involve security and privacy specialists in DLT design from the start — any later is too late.
- Keep personal data off-chain. While a lot of DLT use cases involve personal data, there’s no reason why personally identifiable information (PII) should be stored on-chain. Quite the contrary: It just shouldn’t. Using data encryption is of course an option but shouldn’t be the default fallback solution. While encryption clearly helps, it isn’t a panacea: Key theft and brute force attacks remain risks. And in a distributed ledger environment, the risk actually increases in line with the number of fully replicated nodes; the old adage still holds true: A chain is only ever as strong as its weakest link.
- Involve legal counsel every step of the way. There are, and likely always will be, gray areas in GDPR compliance, and many requirements remain uncertain until tested in courts. But with careful design and appropriate techniques (e.g., ensuring that on-chain hashes are meaningless once the corresponding data has been deleted and the keys destroyed), a permissioned blockchain can be in line with GDPR requirements.
- DLT can be a valuable element in your GDPR compliance framework. For example, a blockchain can be used to store all events related to data capture and subsequent processing (but not the data itself), as well as consent and deletion where applicable. We already see startups offering such solutions. We’re also seeing more ambitious initiatives that seek to leverage DLT to protect privacy — for example, by using a blockchain as an automated access control manager.
For more detail and further background reading, check out the report, “Don’t Let GDPR Derail Your Blockchain Strategy.”