On 8th April, the European Data Protection Board (EDPB) published draft guidelines on the processing of personal data through blockchain technologies. These guidelines aim to help controllers use blockchain technology while complying with the General Data Protection Regulation (GDPR). Stakeholders can comment on these guidelines until 9th June 2025. This article summarises the key points relevant to data controllers using blockchain.
This article is the first part of our article series on this topic. Part 2 will follow soon.
Blockchain technology and personal data
A blockchain means both an ecosystem or a branch of technologies, and a specific digital record of transactions. In the ecosystem sense, it is a distributed digital ledger system that confirms a record of transactions. Among others, blockchain technology can be used to establish ownership of digital assets, such as cryptocurrency or digital artworks (such as NFC). It ensures secure handling of data, maintaining the integrity of its data entries and the traceability of any changes.
When we are talking about blockchain as a digital record (not the whole ecosystem), these blockchains (such as the public “mainnet” of Bitcoin) store a chain of blocks on a changing set of different computers (“nodes”). Each block is made of block metadata (such as timestamps) and transaction data. Within the transaction data, the draft guidelines differentiate between payload and transaction metadata. For some blockchains and transaction types, the “payload” is usually just a value (how many units are transferred to an address), while for other, more complex blockchains, this can include a computer code or a reference to a computer code (running or referencing either on- or off-chain as well).
Both transaction metadata and this latter type of payload can qualify as personal data under the GDPR if they point to and directly or indirectly identify individuals. While it is easy to hide direct identifiers, even these hashed or cryptographically processed unique identifiers will still be considered personal data as long as their function is to lead to specific individuals, in accordance with the definition of "identifiable natural persons" under Article 4(1) of the GDPR. This is similar to how bank account numbers’ function, ultimately leading to the identification of specific individuals.
Computer nodes running the blockchain (in the ecosystem sense) also process additional data, such as IP addresses but this additional data may or may not be stored on-chain.
Roles and responsibilities under GDPR: data controllers, processors, joint controllers?
The guidelines underscore the critical importance of evaluating the roles and responsibilities associated with each processing activity within the blockchain, which wholly depends on the how the actual blockchain works. The roles depend on the governance framework implemented; therefore, although it is theoretically possible to assess the roles based on a particular implementation (such as Bitcoin or Ethereum), the guidelines do not address these questions directly and instead offer only general guidance.
In the case of permissioned blockchains, there is an “authority” that grants participation permissions, restricting both writing and reading rights to a select group of actors. This offers greater control over the governance of the blockchain ecosystem, making it easier for supervisory authorities to identify the entities responsible for data processing activities.
On the other hand, permissionless (and public) blockchains work in a way that all planned changes have to be verified along the same, predefined rules to take effect.
The difficulty for supervisory authorities is that rules can be defined and implemented in practice without a closed set of entities who undertake responsibility for the operation of said rules. In these cases, supervisory authorities have to enforce privacy rules against practically anyone who has any role in the data processing activity, whether just running the infrastructure or the application operated on the infrastructure. In the context of Bitcoin or Ethereum, this could involve tens of thousands of nodes, making the task of identifying each one an extremely challenging undertaking in its own right.
This task is both challenging and resource-intensive for supervisory authorities, which is the underlying reason for the EDPB’s stated preference in the draft guidelines for permissioned blockchains or consortia to assume the role of controller.
Operators at the application level, specifically those who deploy smart contracts onto the blockchain, could also be exceedingly difficult to identify in permissionless blockchains, despite their numbers being orders of magnitude smaller.
The EDPB reluctantly suggests that, in the case of genuinely public, permissionless blockchains - where no consortium assumes the responsibility of acting as a controller - all node operators might be regarded as joint controllers.
It is highly improbable that any supervisory authority would attempt to identify tens of thousands of node operators or even a few deployers of smart contracts, except in extreme circumstances. Instead, they are likely to focus on identifying controllers at the application level by tracing the flow of money and advertisements to pinpoint the actual data controller or joint controllers. In the worst-case scenario, supervisory authorities might be compelled to identify the most significant nodes from a governance perspective, such as the so-called bootstrap nodes in Ethereum or DNS seed nodes in Bitcoin. Ultimately, all these steps and roles are heavily contingent on the specific operation of the blockchain.
Restrictions on data processing on blockchain
Controllers must ensure personal data is not accessible to an indefinite number of people by default, as per Article 25(2) of the GDPR. The EDPB notes that public blockchains should only be used if public access is necessary for at least one processing purpose. Therefore, measures must limit data accessibility and protect against unauthorised processing.
When it is necessary to store personal data on the blockchain, the EDPB recommends that such data should be stored off-chain. The primary assertion of the EDPB in its draft guidelines on the processing of personal data on blockchain is that personal data should not be processed on the blockchain at all. Although this may seem highly restrictive, it underscores the previously mentioned distinction between "blockchain as a specific record of transactions" and "blockchain as an ecosystem".
Data Protection by Design and by Default, data security on blockchain
The concept of data protection by design and by default, as clarified by the EDPB, centres on effectiveness. Controllers must demonstrate the application of context-specific measures to implement data protection principles and integrate necessary safeguards to secure the rights and freedoms of data subjects, even in scenarios where traditional methods may not be as effective. The emphasis is on the actual impact of these measures, rather than merely documenting formal compliance with GDPR. In the context of blockchain, this approach is not just important - it is essential. Blockchain’s core features - immutability, decentralisation, and transparency - create unique and heightened challenges for data protection by design and by default, especially regarding security and the exercise of data subject rights. Unlike traditional databases, where data can be modified or deleted, blockchain’s append-only structure means that once data is written, it cannot be changed or erased. This has direct and significant implications for GDPR compliance, particularly in relation to the rights to erasure and rectification. As a result, ensuring adequate data protection for individuals often requires the use of a combination of privacy-enhancing technologies.
Blockchain security relies on participant behaviour, node quantity, and cryptographic mechanisms. Safeguards should protect against misuse, such as 51%-attacks, and include administrative privileges and permissions governance. The EDPB highlights the need for safeguards against attacks unique to blockchain, such as the 51%-attack, where a group of participants could gain control over the network and potentially manipulate data or disrupt operations - risks not present in centralised systems.
Blockchain security is also heavily dependent on cryptographic mechanisms, which can become obsolete or vulnerable over time (for example, due to advances in quantum computing). The EDPB recommends that controllers plan for algorithm updates and have emergency procedures in place to address vulnerabilities - something that is far more complex in a decentralised, consensus-driven environment.
The EDPB insists that security assessments must cover the entire blockchain ecosystem, including off-chain storage, node security, key management, and the software used to interact with the blockchain. For example, even if the blockchain itself is secure, a vulnerability in a user’s wallet software could lead to a data breach.
The essential point, specific to blockchain, is that the technology’s core features - immutability, decentralisation, and transparency - create unique and heightened challenges for data protection by design and by default, especially regarding security and the exercise of data subject rights.
Key Takeaways for Clients
- Assess the necessity of using blockchain.
- Assess roles and responsibilities for each involved actor during the design phase.
- Favour permissioned blockchains where possible for clearer responsibility allocation.
- Avoid storing personal data on-chain.
- Limit data accessibility to what is necessary for each specific purpose.
- Implement technical and organisational measures early.
- Use encryption and hashing techniques to protect personal data.
The article was co-authored by Helena Siebenrock
Social Media cookies collect information about you sharing information from our website via social media tools, or analytics to understand your browsing between social media tools or our Social Media campaigns and our own websites. We do this to optimise the mix of channels to provide you with our content. Details concerning the tools in use are in our Privacy Notice.