Guidelines on the processing of personal data through blockchains by the European Data Protection Board
The European Data Protection Board (EDPB) published its draft guidelines on processing of personal data through blockchains:
No surprise here, their main advice is: just don't. And if you do (do you need to? really?), you better have a good argumentation ready. Considering one of the core properties of public blockchains is their immutability, then well... Good luck implementing the 'right to rectification', 'the right to be forgotten', ... 😅
Also not a surprise, they mention the use of zero knowledge technology, which obviously seems a great enabler of privacy. Other recommendations are relying on private blockchains, or off-chain storage (but then why use blockchain in the first place though?)
EDPB recommendations
The most interesting part (probably) of the paper are the 16 recommendations in the annex:
Recommendation 1. Architecture – Documentation
The EDPB recommends to controller and processors to document:
i. Will the data on the blockchain contain personal data?
ii. If so, why is a blockchain a necessary and proportionate means for this processing? (i.e. What is the rationale for this choice? What were the eventual alternatives?)
iii. What type of blockchain should be used? (i.e. Is a private blockchain sufficient? Can a permissioned blockchain be used? Is a “zero-knowledge” architecture possible?)
iv. What technical and organisational measures are used? (i.e. Will personal data be stored off-chain? Which privacy-preserving technologies are used?)
Recommendation 2. Architecture – Off-chain storage
The EDPB recommends controllers to store any additional personal data off-chain, beyond the identifiers already present on-chain in transaction metadata, to mitigate data protection risks.
Recommendation 3. Information
Data controllers must inform data subjects in clear terms on the rationale of the processing, the existence of their rights and the modalities to exercise them. Suitable times to provide such information are when a data subject is about to commit data to the blockchain and on creation of the blockchain itself. The information should also be available for data subjects to find at other times, e.g.
on the controller's website.
Recommendation 4. Minimisation
Controllers should assure that only data that is relevant and limited to what is necessary in relation to the purposes are processed. The amount of personal data stored on- and off-chain, the period of their storage and their accessibility should be minimised. Assessment in this regard should be documented for the metadata as well as for the payload of the transactions.
Recommendation 5. Trust
The choices of implementation should include mechanisms for assuring trust including in software and nodes’ identities. It might be done, for example, through certification by international standards and independent third parties.
Recommendation 6. Legal provisions if use of blockchain is mandated by law
Where the use of a blockchain is mandated by Union or Member State law, legislators should include provisions regarding the acceptable level of publicity and discourage any breach of confidentiality.
Recommendation 7. Software Vulnerabilities
The EDPB recommends setting out technical and organisational procedures to disclose software vulnerabilities to all participants, including an emergency plan that allows algorithms to be changed when a vulnerability is identified and to notify security incidents and personal data breaches to the relevant SAs, and to communicate the incident to the involved data subjects
Recommendation 8. Governance
The governance of changes to the software used to create transactions and to create and validate blocks should be documented and technical and organisational procedures should be set out to ensure an alignment between specification and implementation.
Recommendation 9. Consent
If any use of the consent legal basis is made, it must be ensured that it is freely given and that the data subject is able to refuse or withdraw consent without detriment. Technical choices for the implementation of the processing should ensure these two points. In particular, this requires that no personal data is stored on the blockchain that cannot be rendered anonymous by the erasure of off-
chain data and an effective procedure for assuring such erasure in the case of withdrawal of consent is implemented. Consent should not be used for a processing which requires transactions with individuals if the blockchain architecture does not provide a way to delete the personal data regarding
the parties in a transaction.
Recommendation 10. Data protection by design and by default
All data protection principles should be included by design and by default in any processing from the outset and throughout the processing life cycle. All processing operations need to be necessary and proportionate in relation to the purposes of processing. By default, personal data should not be made accessible on a public blockchain without the data subject’s intervention.
Recommendation 11. Data retention – duration
The data retention period of metadata, such as users’ identifiers, and payload should be established pursuant to Art. 17 in conjunction with Art. 25(1) GDPR and taken into account when deciding which kind of blockchain and which format to store those data to use. In cases where a data retention period is not as long as the lifetime of the blockchain, a technical solution should guarantee the appropriate data retention period. At the end of the retention period for personal data stored on the blockchain, this solution should either allow for data deletion or, if applicable, render the data anonymous. If such solution does not exist, then no personal data should be stored on the chain.
Recommendation 12. Security – Evaluation
Carry out an evaluation of the security safeguards necessary to assure the security of the blockchain appropriate to the risks.
Recommendation 13. Security – Limit the impact of algorithm failure
Set out technical and organisational procedures to limit the impact of a potential algorithm failure (as an attack on one of the cryptographic primitives used in the blockchain).
Recommendation 14. Security – Governance of evolution
The governance of software and protocol evolution should be documented.
Recommendation 15. Security – Confidentiality
Whenever it is not necessary for the purposes of the processing, that a public blockchain is used for, then the measures need to be implemented to limit accessibility of the blockchain and ensure the blockchain’s confidentiality. Those measures should be documented and verified.
Recommendation 16. Data subjects’ rights
Data subjects’ rights cannot be restricted – neither by choice of technical implementation nor by the data subjects’ consent. They must be fulfilled in accordance with the GDPR. Technical choices for the implementation of the processing should ensure this. In particular, personal data needs to be erased or rendered anonymous in the event of an objection to processing pursuant to Art. 21 GDPR or a request for erasure pursuant to Art. 17 GDPR.
