On 7 July 2026 the EDPB adopted the final version 2.0 of its Guidelines 02/2025 on processing of personal data through blockchain technologies, following the public consultation on draft version 1.1 (8 April 2025). The synopsis below shows every textual change side by side: deleted text is struck through in the left column, inserted text is highlighted in the right column. Margin numbers (paras.) refer to version 2.0.
53 change locations, mapped to the section and margin numbers of version 2.0.
| Section / para. (v2.0) | Version 1.1 (draft, 8 April 2025) | Version 2.0 (final, 7 July 2026) |
|---|---|---|
| Title page— | Version 1.1 — Adopted on 08 April 2025 — "Adopted – version for public consultation" | Version 2.0 — Adopted on 07 July 2026 — with version history (v1.1: adoption before public consultation / v2.0: adoption after public consultation) |
| Executive Summary— | The distributed nature of blockchain and the complex mathematical concepts involved imply a high degree of complexity and uncertainty that leads to specific challenges with respect to the processing of personal data. In this context, in order to ensure that the processing of personal data complies with the GDPR, risks for rights and freedoms of data subjects need to be carefully assessed. Some of these risks can be mitigated through technical measures upfront, while finding a solution for other risks of non-compliance might be more challenging at this stage. Furthermore, blockchains have certain properties that can lead to challenges when dealing with the requirements of the GDPR. Such properties require to reinforce data protection by design measures in order to implement principles and rights, for example/like the principle of storage limitation and data subjects’ rights such as the right to rectification and the right to be forgotten. Therefore, the controller should carefully assess the blockchain solution it intends to use to avoid non-compliance risks and specific risks to the rights and freedoms of data subjects. These guidelines provide a framework for organizations considering the use of blockchain technology, outlining key GDPR compliance considerations for planned processing activities. They provide an overview of the fundamental principles of blockchain technology, assessing the different possible architectures and their implications for the processing of personal data. Furthermore, they clarify that roles and responsibilities of different actors in a blockchain related processing need to be assessed during the design of a processing and what elements need to be considered in this respect. Depending on the purpose of processing for which blockchain technology is used, different categories of personal data may be processed. The guidelines highlight the need for Data Protection by Design and by Default and adequate organisational and technical measures. They also provide examples of different techniques for data minimisation and for handling and storing personal data. As a general rule, storing personal data on a blockchain should be avoided, if this conflicts with data protection principles. To assist with the compliance with data protection principles, one of several available advanced techniques, appropriate organisational measures and appropriate data protection policies1 should be used when considering storage of personal data on-chain. The guidelines detail technical aspects and different ways of implementation for such techniques, highlighting their strengths and weaknesses in order to help organizations on choosing appropriate measures. Additionally, the guidelines discuss the interplay between the technical aspects of blockchain and the data protection principles of Article 5 GDPR. They emphasize the importance of the rights of data subjects especially regarding transparency, rectification and erasure. The guidelines also highlight the importance of carrying out a Data Protection Impact Assessment (DPIA) prior to implementing a processing using blockchain technology and provide key aspects to be considered in a structured way when conducting a DPIA. Finally, in Annex A the guidelines provide a set of concise recommendations for organizations planning to set up a blockchain based processing. 1 GDPR Art 24 (1) and (2) | — removed entirely — |
| 1 Introductionparas. 1–2 | Blockchain – or, in a more general manner, Distributed Ledger Technologies (hereinafter “DLT”) – can replace intermediation-based transactions. | Blockchain – or, in a more general manner, Distributed Ledger Technologies – can replace intermediation-based transactions. |
| 1 Introductionparas. 3–4 | • distributed (data is replicated by multiple participants peer-to-peer and so stored in multiple locations) • disintermediated (validation of data added to the database does not need the endorsement of a trusted or central party, but rather the agreement of participants in the blockchain) • consistent and tamperproof (any update or removal of validated data can be detected) • transparent (access to data and its auditing is available to all participants in the blockchain) There is no unique implementation mechanism – an actual blockchain used in a processing could modify, extend, or restrict these general properties in any way, for example, by restraining the public access to the data. | • distributed (data is replicated by multiple participants peer-to-peer and so stored in multiple locations) • disintermediated (validation of data added to the database does not need the endorsement of a trusted or central party, but rather the agreement of participants in the blockchain); • consistent and tamperproof (any update or removal of validated data can be detected) • transparent (access to data and its auditing is available to all participants in the blockchain) There is no unique implementation. A blockchain used in a processing could modify, extend, or restrict these general properties in any way, for example, by restraining the public access to the data. |
| 1 Introductionparas. 5–7 | One of the main promises of blockchain technologies is that they can offer strong technical guarantees in terms of integrity and availability due to the cryptographic tools used (hashing and digital signatures) and the decentralised storing system. However, this is a general assumption; in practice, there may not be standardised or formal agreement on the level or quality of service provided. Blockchains show a number of properties, that create specific non-compliance risks and risks for the rights and freedoms of natural persons 3 when dealing with personal data. | One of the main promises of blockchain technologies is that they can offer strong technical guarantees in terms of integrity and availability due to the use of cryptographic tools (hashing and digital signatures) and decentralised storage. However, this is a general assumption; in practice, there may be no standardised or formal agreement on the level or quality of service provided. Blockchains show a number of properties, that create specific non-compliance risks and risks for the rights and freedoms of natural persons3 when dealing with personal data. |
| 1 Introductionparas. 9–10 | The controller should analyse thoroughly whether the use of a blockchain will allow them to comply with data protection law. In particular, regarding the application of the principles of minization and storage limitation, and the effective exercise of rights like erasure and rectification Moreover, the use of decentralized technologies may trigger different compliance risks and risks to individuals' rights and freedoms due potential international transfers, multiple stakeholders, new processing operations for maintenance of blockchain system4, allocation of responsibilities, and governance and management issues. | Controllers should analyse thoroughly whether they comply with data protection law when using a blockchain. In particular, controllers must ensure the application of the principles of data minimisation and storage limitation, and the effective exercise of data subjects’ rights like erasure and rectification. Finally, the use of decentralised technologies may trigger different compliance risks and risks to individuals' rights and freedoms due to potential international transfers, multiple stakeholders, new processing operations for maintenance of blockchain system 4, allocation of responsibilities, and governance and management issues. |
| 2 Context and Scope of Applicationparas. 11–12 | Many uses of blockchain technology will involve international transfers and the use of cloud computing or alike. This is especially true if a blockchain includes nodes that are based outside of the EU, and controllers should be especially aware of their legal obligations when using blockchain technologies in such circumstances. Issues arising from those circumstances are not specific to blockchains. | Many uses of blockchain technology involve international data transfers and cloud computing or alike. This is especially true if a blockchain includes nodes 5 outside the EU. In such circumstances, controllers should be especially aware of their legal obligations. These issues are not specific to blockchains. |
| 2 Context and Scope of Applicationpara. 13 | However, the evaluation of the necessity of such blockchains should still be carried out when personal data are processed, and mitigation measures found in this document could prove useful for any blockchain processing personal data. | However, the evaluation of the necessity of such blockchains should still be carried out when personal data are processed. The mitigation measures found in this document could prove useful for any blockchain processing personal data. |
| 3 Description of the technology of blockchainsparas. 14–15 | 3 DESCRIPTION OF THE TECHNOLOGY OF BLOCKCHAINS Blockchains provide a distributed database consisting of a public ledger of use-case specific transactions. | 3 Description of the technology of blockchains Blockchains provide a distributed database 6 consisting of a public ledger of use-case specific transactions in a chronological sequence of blocks. |
| 3 Description of the technology of blockchainspara. 16 | This helps to prevent any single point of failure or manipulation of the data. As more nodes join the network, the blockchain network’s size grows, making it harder for an attacker to alter the data. | This helps prevent any single point of failure or manipulation of the data. As more nodes join the network, its size grows, making it harder for an attacker to alter the data. |
| 3 Description of the technology of blockchainsparas. 16–17 | Overall, the interconnected nature of nodes in a blockchain network is essential for maintaining the desired properties of the blockchain. Common consensus algorithms rely on the proof of work or the proof of stake mechanism, but other consensus mechanisms also exist. | Overall, the interconnected nature of nodes is essential for maintaining the desired properties of the blockchain. Common consensus algorithms rely on the proof of work8 or the proof of stake9 mechanism, but other consensus mechanisms also exist. |
| 3.1 Different types of blockchainsparas. 21–22 | Permissionless blockchains provide for participants with equal rights and capacities: anyone can read, write, or create blocks. | Permissionless blockchains provide participants with equal rights and capacities: anyone can read, write, or create blocks. |
| 3.1 Different types of blockchainsparas. 22–23 | Permissioned blockchains diverge from the original concepts and include an authority that must give permission to participate: only selected nodes can read, write, or create blocks, depending on the rules that apply to the blockchain. | Permissioned blockchains require an authority that gives permission to participate: only selected nodes can read, write, or create blocks, depending on the rules that apply to the blockchain and defined by that authority. |
| 3.1 Different types of blockchainsparas. 23–24 | The initial concept of blockchain includes transactions where the identities of the parties involved are visible to all. Some blockchains provide ways of hiding those identities to most people reading the chain using advanced cryptographic tools. | In the initial concept of blockchain, the identifiers of the parties involved in the transactions are visible to all. Some blockchains provide ways of hiding those identifiers to most people reading the chain using advanced cryptographic tools. |
| 3.2 Data inside a blockchainparas. 24–25 | 3.2 Data inside a blockchain Blockchains store metadata of the transaction combined with a payload. | 3.2 Data inside a blockchain Blockchains store transaction metadata combined with a payload. |
| 3.2 Data inside a blockchainpara. 29 | This can be an amount of cryptocurrency, a link to a document, an item purchased, a smart contract procedure call, etc. | This can be an amount of cryptocurrency, a link to a document, an agreement or part thereof, using a sequence of electronic data records and ensuring their integrity and the accuracy of their chronological ordering”. item purchased, a smart contract procedure call, etc. |
| 3.2 Data inside a blockchainpara. 31 | — | These approaches may alter the way data is stored on-chain and the types of on-chain data to be assessed, as further described in the paragraphs below. |
| 3.3 Roles and responsibilitiesparas. 40–41 | Participants are not always equal, even in permissionless public blockchains: the role and responsibilities of each participant depends on the elements recalled above and in particular on the governance system. | Participants are not always equal, even in permissionless public blockchains: the role and responsibilities of each participant depend on the elements recalled above and in particular on the governance system. |
| 4.1 Introductionparas. 44–45 | 4 EVALUATING BLOCKCHAIN-BASED PROCESSING 4.1 Introduction Blockchain is only a technology, as cloud computing or peer-to-peer networks, and it is not a processing of personal data as such. Nevertheless, the choice of technology does affect the processing activity and its compliance with GDPR (Article 24 GDPR). | 4 Evaluating Blockchain-Based Processing 4.1 Introduction Blockchain is only a technology, as cloud computing or peer-to-peer networks. It is not, by itself, a processing of personal data. Nevertheless, it does affect the processing activity and its compliance with the GDPR (Article 24 GDPR). |
| 4.1 Introductionpara. 45 | Some of these non-compliance risks can be easily mitigated through technical measures upfront, while finding a solution for other risk might may be challenging at this stage. It is therefore of the utmost importance that controllers make a proper evaluation for their own processing before implementing a blockchain – and that this evaluation is used to ensure that blockchains are only deployed in a way which is compliant with the GDPR and provides the proper protections for data subject rights. | Some of these non-compliance risks can be easily mitigated through technical measures upfront, while finding a solution for other risks might be challenging at this stage. It is therefore of the utmost importance that controllers make a prior evaluation for their own processing before implementing a blockchain. Controllers use this evaluation to ensure GDPR-compliant deployment of blockchains and the proper protections for data subject rights. |
| 4.2 Processing of personal dataparas. 48–50 | 4.2 Processing of personal data Controllers are reminded that, according to Article 25(2) GDPR, technical and organisational measures shall ensure “(…) that by default personal data are not made accessible without [the data subject’s] intervention to an indefinite number of natural persons.” This requirement applies to the storing of personal data on both public and non-public blockchains, and public blockchains should only be employed if public access to the blockchain is necessary for at least one of the purposes of the processing. If the blockchain is not public then, pursuant to Article 5(1)(f), 25(2) and 32 GDPR, measures should be taken to limit the accessibility of personal data stored on the blockchain to what is necessary for each specific purpose of the processing and to protect the data against unauthorised processing. Storing personal data in a directly identifying form on a blockchain has several implications. First of all, once stored on a blockchain, the data will stay on the blockchain with no practical possibility of deletion or modification in most cases. Even though it is technically possible to modify a blockchain, such modifications are very hard to put in place as it requires that all nodes update their copy of the chain (or to delete their copy) and agree upon the change. This undermines the principles of consistency and tamperproof processing, which are the core of most blockchains design. In practice, such modification may not even impact all copies of the original block, meaning that the original data might still be available. The EDPB emphasises that technical impossibility cannot be invoked to justify non-compliance with GDPR requirements 17. | 4.2 Processing of personal data on the blockchain Controllers are reminded that, according to Article 25(2) GDPR, technical and organisational measures shall ensure “(…) that by default personal data are not made accessible without [the data subject’s] intervention to an indefinite number of natural persons.” This requirement applies to the storing of personal data on both public and non-public blockchains. Public blockchains should only be employed if public access to the blockchain is necessary for at least one of the purposes of the processing. If the blockchain is not public then, pursuant to Article 5(1)(f), 25(2) and 32 GDPR, measures should be taken to limit the accessibility of personal data to what is necessary for each specific purpose of the processing and to protect the data against unauthorised processing. Storing personal data in a directly identifiable form on a blockchain has several implications. Once stored on a blockchain, the data will, in most cases, stay on the blockchain with no practical possibility of deletion or modification. Even though modifications are technically possible, they are very hard to implement, as it requires that all nodes update their copy of the chain (or to delete their copy) and agree upon the change. This undermines the core blockchain principles of consistency and tamperproof processing. In practice, such modifications may not even impact all copies of the original block, meaning that the original data might still be available. The EDPB emphasises that technical impossibility cannot be invoked to justify non-compliance with GDPR requirements 24 . |
| 4.2 Processing of personal datapara. 51 | To address this issue, one way is to encrypt personal data before storing it on a blockchain. | To address this issue, one measure is to encrypt personal data before storing it on a blockchain. |
| 4.2 Processing of personal dataparas. 53–54 | Whenever it is necessary to store personal data on the blockchain, it is better to store the data in a form which is primarily intended to function as a proof of existence18 (e.g. by use of a pointer, a cryptographic commitment or a hash generated from a keyed hash function, etc.) on the blockchain, with the data that should be used to verify the proof being kept outside of the blockchain (such as, for example, on the data controller’s information system). | Whenever it is necessary to store personal data on the blockchain, it is better to store on-chain the data only in a form which is primarily intended to function as a proof of existence 25 (e.g. by use of a pointer, a cryptographic commitment or a hash generated from a keyed hash function, etc.). The data that should be used to verify the proof should be kept outside of the blockchain (such as, for example, on the data controller’s information system). |
| 4.2 Processing of personal dataparas. 55–57 | In these particular cases, it may be appropriate to store personal data on a public blockchain in a directly identifying form, but only if it is justified by the purpose of the processing and a DPIA has been conducted and concluded that the risks for data subjects have been properly addressed and mitigated. The measures presented above can be helpful for reducing risks to data subjects. Nevertheless, they will also need to be accompanied by other appropriate technical and organisational measures to ensure that the processing meets all applicable GDPR requirements and grants the data subject rights. 4.3 Principles of Data Protection The data protection principles are those enshrined in Article 5 GDPR. Controllers are responsible for their implementation in an accountable way and in an effective manner19. | In these particular cases, it may be appropriate to store personal data on a public blockchain in a directly identifiable form, but only if the purpose of the processing justifies it and a DPIA has concluded that the risks for data subjects have been properly addressed and mitigated. The measures presented above, together with emerging Privacy-Enhancing Technologies such as zero-knowledge proofs and other advanced cryptographic protocols, can be helpful for reducing risks to data subjects. Nevertheless, they should be carefully tested, validated and will also need to be accompanied by other appropriate technical and organisational measures to ensure that the processing meets all applicable GDPR requirements and grants the data subject rights. 4.3 Principles of Data Protection The data protection principles are enshrined in Article 5 GDPR. Controllers are responsible for their implementation in an accountable and an effective manner 26. |
| 4.3 Principles of Data Protectionparas. 57–59 | Below, the EDPB presents some issues in a non-exhaustive manner that should be taken into account by data controllers when evaluating their processing of personal data with regard to the data protection principles. Fairness principle20 requires that personal data should not be processed in a way that is unjustifiably detrimental, unlawful, discriminatory, unexpected or misleading to the data subject. Measures and safeguards implementing the principle of fairness also support the rights and freedoms of data subjects, specifically the right to information (transparency), the right to intervene (access, erasure, data portability, rectify) and the right to limit the processing (right not to be subject to automated individual decision-making and non-discrimination of data subjects in such processes) When considering the transparency principle 21, the controller must be clear and open with the data subject about how they will collect, use and share personal data. | Below, the EDPB presents some issues in a non-exhaustive manner that should be taken into account by data controllers when evaluating their processing of personal data based on blockchains, with regard to the data protection principles. The fairness principle 27 requires that personal data should not be processed in a way that is unjustifiably detrimental, unlawfully discriminatory, unexpected or misleading to the data subject. Measures and safeguards implementing the principle of fairness also support the rights and freedoms of data subjects, specifically the right to information (transparency), the right to intervene (access, erasure, data portability, rectify) and the right to limit the processing (right not to be subject to automated individual decision-making and non-discrimination of data subjects in such processes). When considering the transparency principle 28, the controller must be clear and open with the data subject about how they will collect, use and share personal data. |
| 4.3 Principles of Data Protectionparas. 59–60 | Pursuant to the principle of purpose limitation, data shall be processed for a specified, explicit, and legitimate purposes and not further processed in a manner that is incompatible with these purposes. However, blockchain technology, by design, is disintermediated22 in nature and the relationships between participants cannot always be governed by contracts or other legal acts that bind them to implement appropriate technical and organisational measures to ensure compliance 23. Controllers should therefore be very careful to understand their particular role while also ensuring their purposes of processing personal data is clear and unambiguous to all stakeholders. Once those purposes has been achieved, data should either be deleted or rendered anonymous in line with the storage limitation principle (which will be discussed in more detail below). | Pursuant to the principle of purpose limitation, personal data shall be processed for a specified, explicit, and legitimate purposes and not further processed in a manner that is incompatible with these purposes. However, blockchain technology, by design, presents particular challenges for applying this principle. Its disintermediated 29 nature means that the relationships between participants cannot always be governed by contracts or other legal acts that bind them to process personal data only for the initially specified purposes and to implement appropriate technical and organisational measures to ensure compliance 30 . Controllers should therefore be very careful to understand their particular role while also ensuring their purposes of processing personal data are clear and unambiguous to all stakeholders. Once those purposes have been achieved, data should either be deleted or rendered anonymous in line with the storage limitation principle (which will be discussed in more detail below). |
| 4.3 Principles of Data Protectionpara. 61 | This tension needs to be reconciled and controllers must ensure that they have appropriate measures in place for doing so. Data minimisation, in connection with the purpose and storage limitation principles, is crucial and only data which is necessary data to achieve the purpose may be processed in a blockchain. Finally, the data minimisation principle should also include a reflection on the level of publicity applicable for any personal data involved. Seen through this lens, the data minimisation principle is an obligation for controllers to demonstrate that the technique chosen is the one assuring that only the minimum of information necessary for the processing is used and with the minimum level of publicity. | Controllers must ensure that appropriate measures are in place for reconciling this tension. Data minimisation, in connection with the purpose and storage limitation principles, requires that only data which is necessary data to achieve the purpose may be processed on a blockchain. Finally, the data minimisation principle also entails an assessment on the level of publicity applicable for any personal data involved. Seen through this lens, the data minimisation principle is an obligation for controllers to demonstrate that the chosen technique ensures that only the minimum of information necessary for the processing is used and with the minimum level of publicity. |
| 4.3 Principles of Data Protectionparas. 62–63 | Personal data must be erased once the purposes of the processing has been achieved and any regulatory periods for retention have expired in order to conform to the principle of storage limitation. | Personal data must be erased once the purposes of the processing have been achieved and any regulatory periods for retention have expired in order to conform to the principle of storage limitation. |
| 4.3 Principles of Data Protectionparas. 63–64 | Where this would require the deletion of part of the blockchain, including the deletion of any copies held by nodes or other parties, controllers should ensure that sufficient technical and organisational measures are in place for doing so24. If the future identification of a data subject is to be prevented, it should be possible to prevent the linking, with means reasonably likely to be used, of an existing transaction involving a particular data subject with a future transaction involving that same person. It might be possible, depending on the type of blockchain and the way transactions are recorded, to modify off-chain data so that the data subjects involved in the transaction are no longer identifiable with reference to data remaining on the chain. | Where this would require the deletion of part of the blockchain, including the deletion of any copies held by nodes or other parties, controllers should ensure that sufficient technical and organisational measures are in place for doing so 31. To prevent future identification of a data subject, any linking, with means reasonably likely to be used, between an existing transaction involving a particular data subject and a future transaction involving that same person should be prevented. Depending on the type of blockchain and the way transactions are recorded, it might be possible to modify off-chain data so that the data subjects involved in the transaction are no longer identifiable with reference to data remaining on the chain. |
| 4.3 Principles of Data Protectionpara. 67 | Trust cannot be enforced but can only be incentivised, e.g. by the use of certified software for interacting with the blockchain, by ensuring a way to identify nodes and if necessary and by using permissioned blockchain. | Trust cannot be enforced but can only be incentivised, e.g. by the use of certified software to interact with the blockchain, by ensuring a way to identify nodes and if necessary, by using permissioned blockchain. |
| 4.3 Principles of Data Protectionparas. 69–70 | This may include means to disclose software vulnerabilities to all affected stakeholders, an emergency plan that allows algorithms to be changed when a vulnerability is identified, and ways to notify security incidents and personal data breaches to the relevant SAs and to communicate the incident to the involved data subjects. Furthermore, the governance of changes should be documented in a way to reduce the risk of misalignment between the specification and its implementation. 4.4 Lawfulness of processing Given the fact that a Blockchain infrastructure allows certain data processing to be implemented on it, there is no one legal basis for all processing activities using blockchains. For each processing of personal data, the legal basis specific most appropriate for the processing’s purpose has to be determined. The legal basis for the processing of personal data must be one of those set out in Article 6 GDPR. Further, if data relevant for Article 9(1) GDPR is processed, then one of the exceptions mentioned in Article 9(2) GDPR apply. Several alternatives may exist permitting such processing, the assessment if there is a valid legal basis should be based on the specific context of the processing at stake. | This may include means to disclose software vulnerabilities to all affected stakeholders, an emergency plan to update algorithms when a vulnerability is identified, and procedures to notify security incidents and personal data breaches to the relevant SAs and to communicate them to the involved data subjects. Furthermore, the governance of changes should be documented to reduce the risk of misalignment between the specification and its implementation. 4.4 Lawfulness of processing Given the fact that a blockchain infrastructure allows certain data processing to be implemented on it, there is no single legal basis for all processing activities using blockchains. Each processing of personal data must rely on one of the legal bases set out in Article 6 GDPR, taking into account its specific purpose. Further, if the processing involves personal data relevant for Article 9(1) GDPR, then one of the exceptions mentioned in Article 9(2) GDPR must apply. The assessment of whether a valid legal basis exists should be based on the specific context of the processing at stake. |
| 4.4 Lawfulness of processingparas. 72–76 | Examples may include cases where blockchain solutions are implemented for anti-money-laundering requirements or for certain asset (e.g. real estate) inventories, which can be imposed by Union or Member State law. In those circumstances, as required by Article 23 GDPR28, restrictions on individuals’ rights must be proportionate, strictly defined in the law and respond to the specific requirement of necessity in a democratic society. A blockchain might also be used where the processing operation is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject to whom the personal data refer in line with Article 6(1)(f) GDPR29 30 31. . 4.5 International transfers Chapter V GDPR lays down the rules under which transfer of personal data outside the EEA make take place. Blockchain technology will often involve international data transfer, in particular when information are shared across nodes that are based outside of the UE. These nodes are neither necessarily chosen or vetted, such as in public blockchains32 which may raise compliance concerns. Nevertheless, any transfer of personal data outside of the EU has to comply with the provisions of Chapter V GDPR33. Controller should be aware of these obligations and identify transfers as well as relevant mechanisms to facilitate these data flows. As an example, controller could incorporate standards contractual clauses in any existing contract that should be signed before being accepted as a node. In any case, ensuring a proper application of the data transfers requirements should be addressed from the design of blockchain activities34. A privacy by design architecture may help assess compliance obligations. 4.6 Data protection by design and by default As clarified by the EDPB in its Guidelines 4/2019 on Data Protection by Design and by Default, effectiveness is at the heart of this concept35. | Examples may include cases where Union or Member State law requires blockchain solutions for anti-money-laundering purposes or for certain asset (e.g. real estate) inventories. In those circumstances, as required by Article 23 GDPR 35, restrictions on individuals’ rights must be proportionate, strictly defined in the law and respond to the specific requirement of necessity in a democratic society. A blockchain might also be used where the processing operation is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject to whom the personal data refer in line with Article 6(1)(f) GDPR 36 37 38. 4.5 International transfers Chapter V GDPR lays down the rules under which transfer of personal data outside the EEA may take place. Blockchain technology often involves international data transfers, in particular when data is shared across nodes that are based outside of the EU. These nodes are neither necessarily chosen or vetted, such as in public blockchains 39, which may raise compliance concerns. Nevertheless, any transfer of personal data outside of the EU has to comply with the provisions of Chapter V GDPR 40. Controllers should identify these transfers as well as the relevant mechanisms to allow these data flows. As an example, a controller could incorporate standard contractual clauses in any existing contract that should be signed before being accepted as a node. In any case, ensuring a proper application of the data transfers requirements should be addressed from the design of blockchain activities 41. A data protection by design architecture may help assess compliance obligations. 4.6 Data protection by design and by default As clarified by the EDPB in its Guidelines 4/2019 on Data Protection by Design and by Default, effectiveness is at the heart of this concept 42. |
| 4.7 Data retention periodspara. 78 | It is one of the characteristics of blockchains that the data registered on a blockchain is tamper-proof and that, once a block in which a transaction is recorded has been accepted by the majority of nodes, alterations to that transaction would be detected. However, this is not a reason to assume that the lifetime of the blockchain is an appropriate data retention period; rather, data should be deleted when the end of the processing activity is reached and in line with the data processing principles discussed above. | Data registered on a blockchain is tamper-proof: once a block in which a transaction is recorded has been accepted by the majority of nodes, alterations to that transaction would be detected. However, this is not a reason to assume that the lifetime of the blockchain is an appropriate data retention period. Rather, data should be deleted when the end of the processing activity is reached, in accordance with the data processing principles discussed above. |
| 4.7 Data retention periodspara. 80 | It is important to recall that the data retention period also applies to these identifiers and, if the identifiers take the form of public signature verification keys, the transactions signed by the corresponding private signing keys. | It is important to recall that the data retention period also applies to these identifiers and, if the identifiers take the form of public signature verification keys, to the transactions signed by the corresponding private signing keys. |
| 4.7 Data retention periodsparas. 80–81 | The EDPB considers that, in cases where processing does not require a retention period equal to, or longer than, the lifetime of the blockchain, personal data should not be written to the blockchain unless it is done in a way that allows for the effective prevention of identification of the data subjects with reference to that data employing means reasonably likely to be used. If the data retention period is the lifetime of the blockchain, the controller should be able to justify that such retention period is necessary and proportional in relation to the purpose and the analysis that led to this conclusion should be properly documented. | 43 The EDPB considers that, in cases where processing does not require a retention period equal to, or longer than, the lifetime of the blockchain, personal data should not be written to the blockchain unless it is done in a way that allows for the effective prevention of identification of the data subjects with reference to that data employing means reasonably likely to be used. If the data retention period is the lifetime of the blockchain, the controller should be able to justify that such retention period is necessary and proportional in relation to the purpose. The analysis that led to this conclusion should be properly documented. |
| 4.8 Securityparas. 83–84 | There should also be appropriate safeguards in place to protect against unintended or unauthorized transactions by participants who may have had their wallets compromised or have a rogue employee. This also implies an obligation for participants to implement corresponding technical and organisational safeguards on their sides. | There should also be appropriate safeguards in place to protect against unintended or unauthorised transactions by participants who may have had their wallets compromised or have a rogue employee. This also implies an obligation for participants to implement corresponding technical and organisational safeguards on their own processing systems. |
| 4.8 Securitypara. 85 | Such failures could arise from, for example, the publication of a vulnerability on a cryptographic mechanism, or due to implementation issues. | Such failures could arise from, for example, the publication of a vulnerability on a cryptographic mechanism, or from implementation issues. |
| 4.8 Securityparas. 85–89 | Furthermore, the governance of changes to the software or protocols used in or by the blockchain should be documented, and technical and organisational procedures should be set out to ensure an alignment between planned permissions and practical application. Particular attention should be granted to the measures implemented to ensure the blockchain’s confidentiality if it is not public. Any data controller carrying out processing through transactions on a blockchain should ensure the security of the secret keys used, for example by ensuring that they are stored on secure media. Further, as data breaches can result from vulnerabilities in the infrastructure used to interact with the blockchain, such as stolen identities, the security of the blockchain processing should be assessed as a whole, including when personal data is stored off-chain. Thus, including for security reasons, the data uploaded to the blockchain and processed by nodes should be assessed to only include minimized personal data as set out in the data protection context. The EDPB recalls that security of processing is a requirement under the GDPR36 . Nevertheless, while the specific measures may vary from case to case, they have to ensure a level of security appropriate to the risks for the rights and freedoms of natural persons when personal data is being processed; if it is not possible to achieve the necessary level of security that is appropriate to the risk while using blockchain solutions, controllers should not utilise blockchain solutions as part of their personal data processing activities. | Furthermore, the governance of changes to the software or protocols used in or by the blockchain should be documented. Technical and organisational procedures should be set out to ensure an alignment between planned permissions and practical application. Particular attention should be granted to the measures implemented to ensure the confidentiality of a non-public blockchain. Any data controller carrying out processing through transactions on a blockchain should ensure the security of the secret keys used, for example by storing them on secure media. Further, as data breaches can result from vulnerabilities in the infrastructure used to interact with the blockchain, such as stolen identities, the overall security of the blockchain processing should be assessed, including when personal data is stored off-chain. Thus, including for security reasons, the data uploaded to the blockchain and processed by nodes should be assessed to only include minimised personal data as set out in the data protection context. The EDPB recalls that security of processing is a requirement under the GDPR 44 . Nevertheless, while the specific measures may vary from case to case, they have to ensure a level of security appropriate to the risks for the rights and freedoms of natural persons when personal data is being processed. If it is not possible to achieve the necessary level of security that is appropriate to the risk while using blockchain solutions, controllers should not utilise them as part of their personal data processing activities. |
| 4.9 Data Protection Impact Assessmentparas. 91–95 | The Working Party 29 has already clarified the criteria that should be followed to determine if a processing operation requires a DPIA37. If the use of a specific model of blockchain in a processing activity creates risk to the rights and freedoms of individuals that cannot be mitigate with appropriate technical and organisational measures, the controller always has the option to instead use a different model of blockchain or another technology that reduces, or does not introduce, such risks. Sources of risk in a blockchain-based processing come not only from the storage of data in the blockchain, but also from other operations inherent to the blockchain model. Some elements that might introduce such risks include the communication of transactions and blocks among different stakeholders, the gathering and storage of transactions awaiting validation for block creation, the management of blocks in dead-end branches, the off-chain storage of personal data related to in-chain identifiers or hashes, the generation and storage of communication metadata, and the management of cryptographic information (keys, seeds, salts and so on), among others. All such related risks, as well as any others which are identified, should be managed. As part of their analysis, the controller should assess if the accountability and governance mechanisms implemented in the blockchain allows it to handle the processing risks. This could include, for example, mechanisms for access control, access record, traceability and audit, data breach management among others. In some blockchain models, and particularly due to their distributed nature, personal data not related with the primary processing purposes could be processed in the blockchain ecosystem by third parties, like communication metadata or encryption management data. The controller should assess the data involved in such related processing and take measures to guarantee the application of GDPR principles, in particular, minimising such data, controlling the access to and storage of such data, and making such processing transparent to the data subject. | The Working Party 29 has already clarified the criteria that should be followed to determine whether a processing operation requires a DPIA 45. If the use of a specific model of blockchain in a processing activity creates risk to the rights and freedoms of individuals that cannot be mitigated with appropriate technical and organisational measures, the controller always has the option to instead use a different model of blockchain or another technology that reduces, or does not introduce, such risks. Risks in a blockchain-based processing come not only from the storage of personal data on the blockchain, but also from other operations inherent to the blockchain model. These include: the communication of transactions and blocks among different stakeholders, the gathering and storage of transactions awaiting validation for block creation, the management of blocks in dead-end branches, the off-chain storage of personal data related to on-chain identifiers or hashes, the generation and storage of communication metadata, and the management of cryptographic information (keys, seeds, salts, etc.). All identified risks, included those listed above, should be managed. As part of their analysis, the controller should assess whether the accountability and governance mechanisms implemented in the blockchain enable to manage the processing risks. Examples of such mechanisms include: access control, access record, traceability and audit, and data breach management. In some blockchain models, particularly due to their distributed nature, third parties in the blockchain ecosystem can process personal data unrelated with the primary processing purposes, such as communication metadata or encryption management data. The controller should assess the data involved in such related processing and take measures to guarantee the application of GDPR principles, in particular, by minimising such data, controlling the access to and storage of such data, and making such processing transparent to the data subject. |
| 4.9 Data Protection Impact Assessmentpara. 96 | The computational effort needed to break encryption systems, and the possibility of technical advances such as cryptanalytically-relevant quantum computers, should be balanced with regard to the sensitivity and value of the data, and the risks to the data subject, not for the processing itself. Such risk should be assessed in the design phase of the processing and should be part of the risk management process along the life cycle of the processing, including with periodic reassessment. | When assessing these risks, the computational effort needed to break encryption systems, including the potential impact of technical advances such as cryptanalytically-relevant quantum computers, should be balanced with regard to the sensitivity and value of the data, as well as the risks to the data subject, rather than to the processing itself. This risk assessment should take place during the design phase and be part of the risk management process throughout the lifecycle of the processing, including with periodic reassessment. |
| 4.9 Data Protection Impact Assessmentparas. 97–98 | It should be considered in the risk management with regards new vulnerabilities, malfunctions or updates in the nature, scope, context and purpose of the processing. When conducting a DPIA for a blockchain-related processing, there are additional aspects that should be specifically addressed: • A systematic description of the blockchain processing operations, including, for example, the processing purposes, the specific use case, the identification of the blockchain infrastructure, the blockchain model, the definition of roles and responsibilities, the categories and (where appropriate) identities of data recipients and other potential third parties, the data governance model, the type of operations carried out over the life cycle of the processing, the data sensitivity, whether there is any on/off-chain processing, whether there are any smart contracts and means of automatic personal data inference, the implementation of the exercise of rights, any data protection by design and by default measures, to the existence of any international transfers and related safeguards, any data communications, and any other processing activities supported in the same blockchain infrastructure. • An assessment of the necessity and proportionality of the processing operations that are carried out depend on the blockchain. In particular, the DPIA should explain if the use of blockchain is considered necessary and why the objective cannot reasonably be as effectively achieved in a way that is less invasive of privacy and carries less risk for the rights and freedoms of natural persons. • An assessment of the risks to the rights and freedoms of data subjects of the processing as a whole, including the risks that are specific of the use of blockchain such as those described in previous sections, an assessment of possible data breaches, an estimation of the extend and scale of processing and the blockchain infrastructure, and an assessment of the risks for data protection rights and safeguards in case of international transfers among others. | It should be considered in the risk management with regards to new vulnerabilities, malfunctions or updates in the nature, scope, context and purpose of the processing. When conducting a DPIA for a blockchain-related processing, the following aspects should be specifically addressed: • A systematic description of the blockchain processing operations, including, for example, the processing purposes, the specific use case, the identification of the blockchain infrastructure, the blockchain model, the definition of roles and responsibilities, the categories and (where appropriate) identities of data recipients and other potential third parties, the data governance model, the type of operations carried out over the lifecycle of the processing, the data sensitivity, whether there is any on/off-chain processing, whether there are any smart contracts and means of automatic personal data inference, the implementation of the exercise of rights, any data protection by design and by default measures, the existence of any international transfers and related safeguards, any data communications, and any other processing activities supported in the same blockchain infrastructure. • An assessment of the necessity and proportionality of the processing operations that depend on the blockchain. In particular, the DPIA should specify if the use of blockchain is considered necessary and explain why the processing objective cannot reasonably be effectively achieved in a less privacy-invasive way that carries less risk for the rights and freedoms of natural persons. • An assessment of the risks to the rights and freedoms of data subjects arising from the processing as a whole. This includes: the risks specific of the use of blockchain, such as those described in previous sections, an assessment of possible data breaches, an estimation of the extent and scale of processing and of the blockchain infrastructure, and an assessment of the risks to data protection rights and safeguards in case of international transfers among others. |
| 4.9 Data Protection Impact Assessmentpara. 98 | This could include accountability measures, data protection by design and by default measures, data minimisation and guarantee of data accuracy strategies, cryptography guarantees and other security issues, PETs used in the blockchain itself and its ecosystem, and personal data breach management measures, among others. | This could include accountability measures, data protection by design and by default measures, data minimisation and guarantee of data accuracy strategies, cryptography guarantees and other security measures, PETs used in the blockchain itself and its ecosystem, and personal data breach management measures, among others. |
| 5.1 Information of data subjectspara. 99 | 5 DATA SUBJECT RIGHTS 5.1 Information of data subjects, right of access and right to data portability The data controller must provide concise information that is easily accessible and formulated in clear terms to the data subject before submitting personal data to nodes for validation (see section 4.3 for possible points in time to provide such information). The same applies for the right of access and the right to portability: the EDPB considers that the exercise of these rights can be compatible with blockchains’ technical properties as long as the controller fulfils all GDPR requirements concerning the exercise of those rights39. 5.2 Right to erasure and right to object The rights to erasure and to object40 must be complied with by design. The EDPB observes that it might be technically impracticable to grant the request for actual deletion41 made by a data subject when personal data is stored directly on a blockchain. | 5 Data subject rights 5.1 Information of data subjects, right of access and right to data portability 100 The data controller must provide the data subject with concise information that is easily accessible and formulated in clear terms, before submitting personal data to nodes for validation (see section 4.3 for possible points in time to provide such information). 101 The same applies for the right of access and the right to portability: the EDPB considers that the exercise of these rights can be compatible with blockchains’ technical properties, as long as the controller fulfils all GDPR requirements concerning the exercise of those rights 47. 5.2 Right to erasure and right to object 102 The rights to erasure and to object 48 must be complied with by design. 103 The EDPB observes that it might be technically impracticable to grant the request for actual deletion 49 made by a data subject when personal data is stored directly on a blockchain. |
| 5.4 Right to object to a solely automated decisionpara. 99 | 5.4 Right to object to a solely automated decision. The execution of a smart contract may, in some cases, constitute an automated decision. When these automated decisions fall into the scope of Article 22, the data controller should ensure that the safeguards in that provision are satisfied, including the possibility of human intervention, and allowing the data subject to contest the decision, even if the smart contract has already been performed and regardless of what is registered on the blockchain. | 5.4 Right to object to a solely automated decision-making 107 The execution of a smart contract may, in some cases, constitute an automated decision-making. When these automated decisions fall into the scope of Article 22, the data controller should ensure that the safeguards in that provision are satisfied. These include the possibility of human intervention, and the right for the data subject to contest the decision, even if the smart contract has already been performed and regardless of what is registered on the blockchain. |
| Recommendation 1para. 99 | Architecture – Documentation The EDPB recommends to controller and processors to document: i. | Architecture – Documentation 108 The EDPB recommends to controllers and processors to document: i. |
| Recommendation 7para. 99 | 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. | Software Vulnerabilities 114 The EDPB recommends setting out technical and organisational procedures to disclose software vulnerabilities to all participants, including an emergency plan to update algorithms 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 115 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 11para. 99 | 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. | Data retention – duration 119 The data retention period of metadata, such as users’ identifiers, and payload should be established pursuant to Article 17 in conjunction with Article 25(1) GDPR and taken into account when deciding which kind of blockchain and which format to store those data to use. 120 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. |
| Recommendation 12para. 99 | Security – Evaluation Carry out an evaluation of the security safeguards necessary to assure the security of the blockchain appropriate to the risks. | Security – Evaluation 121 Controllers should carry out an evaluation of the security safeguards necessary to assure the security of the blockchain appropriate to the risks. |
| Recommendation 13para. 99 | 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). | Security – Limit the impact of algorithm failure 122 Controllers should 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 15para. 99 | 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. | Security – Confidentiality 124 Whenever the purposes of the processing do not require the use of a public blockchain, measures need to be implemented to limit accessibility of the blockchain and ensure its confidentiality. |
| Recommendation 16para. 99 | 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. ANNEX B – GLOSSARY Disintermediated Refers to the removal of intermediaries or middlemen in a transaction or process. | Data subjects’ rights 125 Data subjects’ rights must be fulfilled in accordance with the GDPR. Neither technical implementation choice nor data subjects’ consent can restrict these rights. Technical implementation choices of the processing should ensure compliance with these rights. In particular, personal data needs to be erased or rendered anonymous in the event of an objection to processing pursuant to Article 21 GDPR or a request for erasure pursuant to Article 17 GDPR. ANNEX B – Glossary 126 Consensus Agreement among blockchain nodes that a transaction has been validated and that the blockchain contains a consistent set and ordering of records of validated transactions. Consensus does not necessarily require agreement by all nodes. There are different types of consensus mechanisms. Depending on the design of the blockchain system, consensus may be probabilistic or eventual rather than absolute or permanent, and competing versions of the chain may temporarily or persistently arise, for example through forks. 127 Disintermediated Refers to the removal of intermediaries or middlemen in a transaction or process. |
| ANNEX Bpara. 99 | Ledger A ledger is a record of transactions that have taken place on a blockchain. It is a decentralized and distributed, digital bookkeeping system that allows multiple parties to agree on the state of a transaction without the need for a central authority. Mining/Validating The process of verifying and adding new transactions to a blockchain. | 129 Ledger A ledger is a record of transactions that have taken place on a blockchain. It is a decentralised and distributed, digital bookkeeping system that allows multiple parties to agree on the state of a transaction without the need for a central authority. In most blockchain implementations, the ledger data and especially the world-state are materialised at the node level using key-value databases such as LevelDB or RocksDB. 130 Mining/Validating The process of verifying and adding new transactions to a blockchain. |
| ANNEX Bpara. 99 | — | 135 Publicity For the purposes of these Guidelines, the degree to which data processed in connection with a blockchain, including transaction metadata, payload data or other on-chain data, is visible, accessible or otherwise available to blockchain participants, nodes, users or third parties. The level of publicity may vary depending on the blockchain architecture and the measures implemented, ranging from data being publicly available to anyone, to data being available only to selected or authorised participants, or to limited information being available on-chain while the underlying data is kept off-chain or otherwise protected. 136 Smart Contract Computer program stored in a blockchain, where the outcome of any execution of the program is also recorded on-chain. Smart contracts may take different forms and serve different functions, including, for example, token contracts, governance contracts, multisignature or escrow contracts, bridge contracts, proxy or upgradeable contracts, factory contracts, oracle-related contracts, or other contract architectures. They execute automated actions when certain conditions programmed in them are met and they are invoked by a transaction. Their execution may result in changes to the state of the information stored in the blockchain infrastructure, including smart contract storage, and may also generate internal transactions or trigger the execution of other smart contracts in cascade. 137 Wallet address/account/public key A wallet address/account/public key is an identifier linked to a cryptographic key pair in a blockchain network. This identifier qualifies as personal data under Article 4 GDPR when it can be associated with an identified or identifiable natural person (‘data subject’). |
Purely renumbered or identical footnotes are not listed. Numbering: v1.1 → v2.0.
| Footnote | Version 1.1 (draft) | Version 2.0 (final) |
|---|---|---|
| — → fn. 5 (new) | — | See ANNEX B – Glossary. |
| — → fn. 6 (new) | — | In most blockchain implementations, the ledger data and especially the world-state are materialised at the node level using key- value databases such as LevelDB or RocksDB. |
| — → fn. 7 (new) | — | See ANNEX B – Glossary. |
| — → fn. 8 (new) | — | See ANNEX B – Glossary. |
| — → fn. 9 (new) | — | See ANNEX B – Glossary. |
| fn. 5 → fn. 10 | The EDPB notes that this term is not unique to the blockchain environments. Article 2(39), Regulation 2023/2854 (‘the Data Act’) defines a smart contract as “a computer program used for the automated execution of an agreement or part thereof, using a sequence of electronic data records and ensuring their integrity and the accuracy of their chronological ordering”. | See ANNEX B – Glossary. The EDPB notes that this term is not unique to the blockchain environments. Article 2(39), Regulation 2023/2854 (‘the Data Act’) defines a smart contract as “a computer program used for the automated execution of an |
| — → fn. 12 (new) | — | On-chain metadata, including transaction identifiers, wallet addresses, event logs, receipts, state transitions and smart contract storage and related traces, may constitute personal data when they enable direct or indirect identification of a natural person |
| — → fn. 22 (new) | — | See ANNEX B – Glossary |
| fn. 18 → fn. 25 | Bunch of data that links or references to existing data stored off-chain | Bunch of data that links or references to existing data stored off-chain. See also ANNEX B – Glossary. |
| — → fn. 43 (new) | — | In certain cases, Union or Member State law may establish specific retention periods that should also be taken into account. For example, the Markets in Crypto-Assets (MiCA) Regulation (EU) 2023/1114, Arts. 68(9) and 76(15), and the Anti-Money Laundering Regulation (AMLR) (EU) 2024/1624, Art. 77, require identification and transactional data to be retained for at least five years after the end of the business relationship. The AMLR will be applicable from 10 July 2027; currently, Article 40 of Directive (EU) 2015/849 (AMLD) remains applicable. |
Official EDPB documents: the final guidelines, version 2.0 (PDF), the EDPB’s own track-changes version (DOCX) and the report on the outcome of the public consultation (PDF).
See also the opinions on the draft guidelines and the BC4EU status report (PDF).
