Several recently published EU and US institutions' and authorities' research papers analyse the relationship between blockchain technology and the GDPR. Given the myriad possible uses for blockchain technology and the GDPR compliance challenges that that technology poses, it is not surprising that the studies grapples with - and reach different conclusions on - the issue of whether blockchain is or can be made to be GDPR compliant. The approach and conclusions appear to split along geographic lines. Below, we briefly summarize each study, as each offers interesting - and differing - approach to assessing suitability of blockchain technology usage; and offer practical suggestions for using blockchain technology in a GDPR compliant manner.
The Studies - A summary
The studies discuss the technological aspects of blockchain systems, albeit in different level of detail. The US National Institute of Standards and Technology's ("NIST") report concludes that the technology is hyped but not well understood. Although it is one of the most innovative technological systems of all time, blockchain is not suitable for use in all cases.
Each study takes a different view to assessing whether blockchain technology can be GDPR compliant.
(i) Blockchain and the GDPR: Are they Incompatible?
The NIST study concludes that it is impossible to evaluate whether blockchain technology itself meets regulatory - including GDPR- requirements. Only its case by case implementation can be assessed for GDPR compliance .
But - perhaps not surprisingly - the French Data Protection Authority's (Commission nationale de l'informatique et des libertés) ("CNIL") and the European Union Blockchain Observatory and Forum's ("EUBOF") reports take a different approach, concluding that blockchain technology is subject to the GDPR.
EUBOF's report describes three main issues:
- identifying data controllers and processors and describing their duties;
- the anonymization of personal data; and
- the exercise of data subject rights.
EUBOF's report goes on to say that, to address those issues, the below principles should be taken into account before implementing blockchain technology:
- Consider whether blockchain use is necessary, based on the use of customer data and how user value is created.
- Avoid storing personal data in the blockchain. Make full use of data obfuscation, encryption and aggregation techniques in order to anonymise data.
- Collect personal data off-chain or, if blockchain use can’t be avoided, on private, permissioned blockchain networks. Consider personal data carefully when connecting private blockchains with public ones.
- Continue to innovate and be as transparent as possible with users.
(ii) Is Blockchain Technology use even necessary?
The NIST and the EUBOF papers also raise an important threshold question: does one need to use a blockchain system at all? Does one need to store data in a shared way so that that multiple entities may be able to access it? Does one need to keep that data intact for eternity? Does one need this data to be tamper proof?
The NIST report recommends evaluating the following issues before deciding to use blockchain technology:
- the number of distributed participants;
- the availability of trusted third parties;
- whether the workflow is transactional in nature (e.g., transfer of digital assets/information between parties);
- the need for a globally scarce digital identifier (i.e., digital art, digital land, digital property) ;
- the need for a decentralized naming service or ordered registry;
- the need for a cryptographically secure system of ownership;
- the need to reduce or eliminate manual efforts of reconciliation and dispute resolutions;
- the need to enable real time monitoring of activity between regulators and regulated entities; and
- the need for full provenance of digital assets and a full transactional history to be shared amongst participants.
Having considered those, if one still decides to use blockchain technology, then the NIST report says that one must choose a blockchain type: permissioned or permissionless. Each has its strengths and weaknesses but, for private companies looking for increased GDPR compliance, NIST recommends a permissioned solution.
To address the key issues highlighted in the NIST and the EUBOF reports and to satisfy privacy compliance requirements, one may want to carry out a data protection impact assessment ("DPIA") alongside an initial information security risk assessment. However, the European Data Protection Board ("EDPB") disagrees, stating that the use of new or innovative technology in itself does not trigger the need to conduct a DPIA. The need to do so arises only when the new technology is combined with another processing factor that raises the data processing risk to a high level.
How to Implement a GDPR compliant Blockchain?
From a GDPR compliance perspective, blockchain technology itself seems irrelevant. Instead, its implementation must be assessed on a case by case basis for GDPR compliance.
Given the considerations raised by the recent CNIL, NIST and EUBOF studies, and based on our experience advising on data privacy and security issues, the following should be considered when designing a blockchain solution that strives to be GDPR compliant:
1. What business goal will the blockchain system help achieve? - answering that question helps to identify the risks involved in processing personal data via blockchain technology and how the solution should work. Concluding financial transactions within a permissioned private blockchain may pose less risk to the rights and freedoms of the individuals than participating in a permissionless public cryptocurrency network.
A data-safe solution which does not help to achieve commercial business goals is not a good solution. Neither is a solution that only focuses on the achievement of business targets but disregards GDPR and other compliance risks.
2. What data flows are involved? – define: who will be able to input data into the blockchain; how nodes will interact with each other; and who will have access to the output data. If the solution will be based on a permissioned implementation, then the relevant permission levels and their granularity (e.g. administrators, super-users and users) must be defined. Blockchains usually do not accept any input from the outside world but also do not check whether input data from a blockchain ecosystem participant is accurate.
The NIST's study recommends addressing the “Oracle problem” inherent in blockchain technology: namely, blockchain has no actual knowledge about the data "truth" . If input of personal data is involved, then the data controller is also required to implement measures to ensure the accuracy of that personal data.
3. Classify the data to be used on the blockchain – does personal data really need to be involved? Consider the principle of data minimization and exclude personal data where it is unnecessary to process or store it. If this can’t be avoided, identify the relevant risk mitigation techniques, such as Zero-knowledge proofs ("ZKP"), homomorphic encryption or secure multi-party computation, as recommended by the EUBOF.
The NIST report warns that quantum computing poses risks to current encryption methods and will render most Public Key Infrastructure ("PKI") based encryption solutions unsecure.
4. Define the legal basis of processing if personal data will be involved – the legal basis of processing personal data may differ depending on the blockchain type used. Permissionless blockchains may rely on the consent of the users whist permissioned blockchains may rely on the performance of a contract. Each has different implications relative to enabling the exercise of data subject rights.
If a legal basis cannot be identified and the lawfulness of the processing of personal data cannot be ensured upfront, then further mitigation measures (e.g. full anonymization) should be sought. In such a case,it may also be prudent to re-consider the appropriateness of using blockchain technology at all.
5. If personal data needs to be processed in the blockchain, define the roles upfront – consider who the data controllers and processors will be and whether these roles will be singular or joint. Define the governance model of the planned solution.
Relative to permissionless blockchains that are susceptible of the "51 % attack" ( where the attackers control more than the half of the resources), the CNIL report suggests that their operators and participants should agree in advance on the allocation of resources and the consensus model to follow.
The definition of roles should be set out in written agreements .
6. If personal data needs to be processed, define procedures to allow the exercise of data subject rights – according to the CNIL paper , the right of access and data portability is compatible with the concept of blockchain. However, the right to restrict processing and the right to be forgotten is not supported by the technology's design.
For this reason we recommend identifying and designing the procedures that will enable data controllers to satisfy the requirements of GDPR's Articles 12 – 23 .
One should be aware of the nature of smart contracts, as those may fall under the provisions of automated decision making under the GDPR - and human intervention would hinder the advantages of the execution of smart contracts. This needs to be addressed at the design stage of the blockchain.
7. Plan functional and non-functional requirements – consider the (half-) immutable nature of blockchain technology and the required resource usage, inadequate block publishing rewards and public key infrastructure and identity the relevant issues, as NIST recommends.
If designing a public blockchain, remember that due to the decentralized nature of the technology, a blockchain never really shuts down.
8. Assess, evaluate and mitigate the related information, security and data protection risks – those include: privacy related risks (e.g. reversal risk or linkability risk of personal data even in encrypted or hashed format); cybersecurity risks (e.g. vulnerabilities of the underlying infrastructure, the blockchain software, malicious users, etc.); and the risks related to the “no trust” environment. Implement the measures necessary to address these risks (e.g. penetration and vulnerability testing of the applied solution; testing of the data subject rights management process, data breach test simulations, etc.)
8. Continuously assess, evaluate and improve – this requirement is often overlooked; however, GDPR's Articles 24 and 32 require data controllers and processors to maintain, evaluate and improve their organizational and technical controls to mitigate the risks posed by their data processing activities.
The GDPR is not a rigid list of steps to follow. It is a framework that allows data controllers and data processors to carry out their business in a manner that protects the rights and freedoms of data subjects. GDPR compliance can only be measured on a case by case basis by considering the actual implementation of technology through which personal data is channelled. Yet the GDPR's rules are not technologically friendly or technology neutral. The manner in which technology is implemented to suit a particular purpose is key to the analysis of whether that technology can be GDPR compliant.
Given the current lack of in depth understanding of blockchain technology and the ambiguity of interpretation of the GDPR's requirements, ultimately, the passage of time will reveal how the use of blockchain technology and the application of the GDPR relative to that technology will evolve.In the meanwhile, a pro active, considered assessment (and re-assessment as time passes) of blockchain technology and its privacy implications seems critical to enabling GDPR compliant blockchain technology use.