> ## Content Index > Fetch the complete content index at: https://www.thedelatorrereview.com/llms.txt > Use this file to discover other available public pages before exploring further. # Blockchain: Challenges and solutions for compliance with the GDPR - URL: https://www.thedelatorrereview.com/blockchain-challenges-and-solutions-for-compliance-with-the-gdpr/ - Published: 2019-05-06T21:47:00.000Z - Updated: 2026-08-22T21:55:32.000Z - Description: An overview of blockchain through the lens of the GDPR, examining territorial and material scope, data protection principles, controller and processor roles, lawful bases, data subject rights, cross-border transfers, and security challenges. - Author: Lydia - Tags: Blockchain, GDPR, Lawful Basis, Cross-Border Data Transfers, Automated Decision-Making Technology (ADMT), Right of Access, Right to an Explanation, Right to be Forgotten, Right to Be Informed, Right to Data Portability, Right to Erasure **NOTE:** This article was written March 2019 for the[ Practicing Law Institute’s (PLI) ](https://www.pli.edu/?ref=thedelatorrereview.com)Institute on Privacy and Data Security Law Conference “The Privacy and Security Challenges of New Technologies” panel to be hosted at the [University of San Francisco ](https://www.usfca.edu/?ref=thedelatorrereview.com)on May 7th where I will participate as a panelist. --- ### Introduction Blockchain is a technology with a **high potential for development that covers a very broad range of situations**. Blockchains can serve to transfer assets (e.g.: Bitcoin or property deeds), be used as a ledger ensuring traceability (e.g.: diploma certification) or even to launch a smart contract (an independent program that “freezes” an agreement reached by two people in a blockchain in the form of an algorithm). **When** blockchain entails the **processing** of[ **personal data**](https://www.thedelatorrereview.com/what-is-personal-data-under-eu-data-protection-law/), it raises **legal compliance questions**. For example, aligning the immutability of blockchain with the principle of [storage limitation](https://www.thedelatorrereview.com/what-does-storage-limitation-mean-under-the-gdpr/) can be challenging. At the same time, blockchains can provide effective solutions to meet the requirements imposed by GDPR. For example, the immutability of actions carried out on blockchains can enable solutions that effectively trace [consent](https://www.thedelatorrereview.com/what-is-consent-under-the-gdpr/). This article discusses the responsible use of blockchain in the context of [**personal data**](https://www.thedelatorrereview.com/what-is-personal-data-under-eu-data-protection-law/) and addresses the legal compliance questions of blockchain in the context of [EU data protection law](https://www.thedelatorrereview.com/what-is-data-protection-law/). Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and of the free movement of such data (GDPR) is one of the three main data protection laws of the EU. The other two are the Directive (EU) 2016/680 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data by competent authorities for the purposes of the prevention, investigation, detection or prosecution of crimes offenses or the execution of criminal penalties, and on the free movement of such data (Directive 2016/680) and Regulation (EU) 2018/1725 of the European Parliament and of the Council of 23 October 2018 on the protection of natural persons with regard to the processing of personal data by the Union institutions, bodies, offices and agencies and on the free movement of such data (Regulation 2018/1725). Because Directive 2016/680 and Regulation 2018/1725 do not apply to the private sector they will not be discussed in this paper. GDPR represents an evolution rather than a revolution in the field of EU data protection law. The structure of [EU data protection law](https://www.thedelatorrereview.com/what-is-data-protection-law/) **represented in the GDPR was developed in the 80s and 90s at a time where centralized processing of data was the norm**. The decentralized data government model used by blockchain technology results in a multitude of actors involved in the processing. This adds a layer of complexity to compliance with a legal framework that was not designed with blockchain in mind. The analysis in this article draws heavily from the initial assessment on compatibility of blockchain and GDPR issued by the C[ommission Nationale de l’Informatique et des Libertés (CNIL)](https://www.cnil.fr/en/blockchain-and-gdpr-solutions-responsible-use-blockchain-context-personal-data?ref=thedelatorrereview.com) issued on November 6, 2018. A **summary of advice** for Blockchain GDPR compliance is provided in the table below: ![](https://storage.ghost.io/c/54/ef/54efeb65-4f2f-479e-b4bb-a9ee526feeaa/content/images/2026/08/ChatGPT-Image-Aug-22--2026-at-02_16_08-PM-1.png) ### What is blockchain? A blockchain is a **database** that stores data and that is distributed to a large number of computers. All entries, called “transactions”, are **visible to all users**. Blockchains are defined by the following properties: - **transparency**: all participants can view all data recorded; - **sharing and decentralization**: several copies of the blockchain coexist on different computers; - **irreversibly**: once data is recorded, it cannot be altered or removed; and - **disintermediation**: all decisions are made by consensus between the participants, without a central arbitrator. --- > **Blockchain technology offers unprecedented levels of transparency and trust, allowing public records to be searched, verified, and audited at a level the world has not seen before.** --- The term “blockchain” is often associated with another term that refers to a larger family of technologies: DLTs, or **“Distributed Ledger Technology”**. This article centers specifically on blockchain technology. There are several types of blockchains, which use different permission levels for different categories of participants. This articles uses the following classification: - **Public blockchains** are accessible to all, anywhere in the world. Anyone can record a transaction, take part in the validation of the blocks or access a copy of them; - **Permissioned blockchains** have rules that set out who can take part in the validation process or even register transactions. They can, depending on the case, be accessible to all or be restricted; - **“Private” blockchains** are controlled by a unique actor who alone oversees participation and validation. Because ‘private’ blockchains do not include the traditional properties of blockchains (such as decentralisation and shared validation) they do not raise the same compliance issues raised by non-private blockchain. GDPR compliance for private blockchain is less demanding and will not be discussed in this article. This article distinguishes between three types of blockchain actors: - **“accessors”**, who have the right to read and hold a copy of the chain; - **“participants”** who have the right to make entries (i.e., make a transaction for which they request validation); - **“miners”** who validate a transaction and create blocks by applying blockchain rules for “acceptance” by the community. A blockchain can contain two categories of personal data: - **participants’ and miners’ identifiers:** each participant/miner has a public key, ensuring identification of the issuer and receiver of a transaction; - **additional data** contained “within” a transaction (e.g.: diploma, property deed). If this data concerns natural persons, possibly other than the participants, who may be directly or indirectly identified, such data is considered personal data. ### Blockchain and GDPR compliance As part of its [Data Protection by Design](https://www.thedelatorrereview.com/data-protection-by-design-and-by-default-under-the-gdpr-what-article-25-requires/) obligations (Article 25 GDPR), the [data controller ](https://www.thedelatorrereview.com/what-is-a-controller/)must give prior thought to the appropriateness of choosing this technology to implement its processing. Blockchain is not necessarily the most suitable technology for all data processing and it can be a source of difficulties for data controllers in terms of compliance with the obligations set out by the GDPR. This section analyses blockchain technologies in the light of the scope of GDPR, its data protection principles, the identification of controllers and lawful basis, the [data subject](https://www.thedelatorrereview.com/what-is-a-data-subject/) rights, the obligations of controllers and processors, the issues related to [cross-border transfers](https://www.thedelatorrereview.com/whencanpersonaldataleavetheeu/) and [security](https://www.thedelatorrereview.com/gdpr-data-security-explained-a-practical-guide-to-technical-and-organizational-measures/). It provides provides advice on best practices for blockchain participants based on the analysis which are summarized in the table at the bottom of the Introduction section above. ### Territorial and material scope Although EU data protection law stretches beyond the physical boundaries of the EU, there are boundaries to its applicability established by its territorial scope. GDPR applies to actors that participate in a blockchain provided that they (1) have an ‘establishment’ in the EU and process data ‘in the context of the activities of the establishment’ or (2) offer goods or services targeted to EU residents (Article 2 & 3 of GDPR). Therefore, it is possible for some but not all blockchain actors to fall within the territorial scope of GDPR. Given the fact that controller liability is, by default, joint and several (see Article 26 of GDPR) w**here any of the participants in a blockchain are ‘established’ in the EU or the services of the blockchain are to be offered to EU residents, it would be advisable to ensure that the whole blockchain is compliant with GDPR**. The material scope of GDPR defines the activities to which it applies. Activities that are performed by a natural persona and are **“purely personal or household”** in nature are excluded from applicability of GDPR (see Article 2.2.(c). Therefore, as a general rule, the activities of any natural person that processes personal data on the blockchain are not subject to GDPR if those activities do not relate to a professional or commercial activity pursuant to the **“purely personal or household activity”** exclusion. For example, a natural person who buys or sells Bitcoin, on his or her own behalf, is not subject to GDPR. However, the said person can be considered a data controller if those transactions are carried out as part of a professional or commercial activity, or on behalf of other natural persons. ### Principles There are seven data protection principles that any entity must abide by while processing personal data subject to GDPR (see Article 5 of GDPR). From the seven principles there is **one that arguably directly conflicts with blockchain technology:** [**The principle of storage limitation**](https://www.thedelatorrereview.com/what-does-storage-limitation-mean-under-the-gdpr/) The principle of storage limitation stands for the proposition that personal data **cannot be stored for an unlimited time**. A data retention period must therefore be defined according to the purpose of the data processing. However, one of the characteristics of blockchains is that the **data registered on a blockchain cannot be altered or deleted: once a majority of participants accept a block in which a transaction is recorded, that transaction can no longer be altered in practice**. As a reminder, a blockchain can contain two categories of personal data: - **The identifiers of participants and miners**: Each participant has an identifier comprised of a series of alphanumeric characters which appear random and constitute the public key to the participant’s account. This public key is linked to a private key known only by the participant. - **Additional data (or payload):** Besides the participants’ identifiers, the additional data stored on the blockchain can contain personal data that can potentially relate to individuals other than participants and miners. Data Protection by Design requires data controllers to **choose the format with the least impact on individuals rights and freedoms** (Article 25 of the GDPR). Some technical solutions have been examined by stakeholders in order to solve this issue and are described below. However their **ability to ensure full compliance with the GDPR is questionable**. Some data controllers may have a **legal obligation to publicize some information** and make it accessible, without a retention period: in this particular case, storage of personal data on a public blockchain can be envisaged (see, “Lawful basis” section below). In addition, if justified by the purpose of the processing and if a [**data protection impact assessment (DPIA)**](https://www.thedelatorrereview.com/tag/dpia-pia/)proves that the residual risks are acceptable, personal data may be stored on the blockchain, in the form of a traditional fingerprint (without a key) or even in cleartext. As a matter of best practice: - With respect to the **identifiers of participants and miners** (i.e. their public keys), blockchain architecture means that these identifiers are inherently always visible, as they are essential for its proper functioning. Because miners and participant identifiers in blockchain cannot be stored off the chain or further minimized, the **retention periods are de-facto equal to the duration of the blockchain** itself as they are essential for proper functioning. Given that it is not possible to further minimize the identifiers, no additional steps can be taken to ensure compliance. - With respect to **payload data**, implementing solutions that enable **storage of the data outside of the blockchain is recommended**. The common feature underlying some of these solutions is to store any data in cleartext outside of the blockchain (for example, on the data controller’s information system) and to **store on the blockchain only proof of existence of the data** (e.g. commitment, hash generated from a keyed hash function, etc.). - **Where storage of payload data outside of the blockchain is not feasible**, data could be stored either using a **hash function without a key** or, in the absence of any other possibilities, in **cleartext but only when justified** by the purpose of the processing and where a [**data protection impact assessment (DPIA)**](https://www.thedelatorrereview.com/tag/dpia-pia/)has proven that the residual risks are acceptable. **Where storage of personal data must occur**, registering personal data on the blockchain in the **form of a ‘commitment’ is preferable**for GDPR compliance (a “commitment” is a cryptographic mechanism that allows one to “freeze” data in such a way that it is both possible — with additional information — to prove what has been frozen and impossible to find or recognise such data by using this sole “commit”). **Where this is not feasible,** registering the data in the form of a hash generated using a **hash function with a key** would be the best alternative. **Where that is not a viable option**, data should at least be registered in the form of an **encryption ensuring a high level of confidentiality** (a ciphertext). ### Controllers and processors in a blockchain The first step to identify GDPR obligations is to **identify the role that the different blockchain actors take with respect to the processing**. Determining who acts as the controller is a key exercise, since data subjects (i.e. individuals whose personal data is recorded on the blockchain) must be informed about which entity they can refer to in order to effectively exercise their rights, and supervisory authorities (a.k.a. data protection authorities) must have a contact point who can be held accountable for the processing carried out. Under GDPR, entities processing personal data are either controllers or processors. These roles were designed in a time where data management was centralized within specific technologies. As a general rule, **an entity acts as a controller if it defies the means and purposes of the processing** of personal data while an entity acts as a **processor when it is processing data on behalf of a controller** s (see Article 4 (7)&(8) of GDPR). The test to determine who acts as a controller is factual based: any entity that de facto determines the means and purposes of processing takes the role of controller under GDPR. It is also specific to the processing performed: an entity may act as a controller as to a specific process related to a specific personal data set and simultaneously as a processor regarding a different process related to the same personal data set. In the context of blockchain: - **Accessors** (i.e. persons with the right to read and hold a copy of the chain): Because **processing is defined under GDPR to include access** (see Article 4(2) of GDPR), assessors who access data of individuals other than themselves process data under GDPR unless the “purely personal or household” exemption applies. They **may be acting either as** [**processors**](https://medium.com/golden-data/what-is-a-processor-e9278ee205bf?ref=thedelatorrereview.com)(if they access on behalf of someone else) **or as** [**controllers**](https://medium.com/golden-data/what-is-a-controller-afd99a8ebd0a?ref=thedelatorrereview.com). This classification gives rise to significant practical compliance challenges. - **Participants** (i.e. persons deciding to register data on a blockchain): Because participants determine the means and purposes of the processing they are considered **data controllers.** Where participants have the right to write on the chain, and are able to decide to send data for validation by the miners, they can be considered as data controllers since they define the ‘purposes’ (objectives pursued by the processing) and the ‘means’ (data format, use of blockchain technology, etc.) of the processing. By default, they will be considered [joint controllers](https://www.thedelatorrereview.com/what-are-joint-controllers-a-k-a-co-controllers/), required to document their relationship (see, Article 26 of GDPR). For example, if a notary records his or her client’s property deed on a blockchain, the said notary is a data controller. In addition, if a bank enters its clients’ data onto a blockchain as part of its client management processing, it is a data controller. - **Miners:** Because miners only validate transactions submitted by participants and are not involved in the object of these transactions, they do not define the purposes and the means of the processing and, therefore, are not controllers. In some cases miners can be considered **data processors**, as they follow the data controllers’ instructions when checking whether the transaction meets technical criteria (such as a format and a certain maximum size, and that the participant is allowed, according to the chain rules, to carry out its transaction). This classification gives rise to significant practical difficulties, especially for miners in a public blockchain. Given the complexity this would create, it can be **useful to identify a data** [**controllers**](https://medium.com/golden-data/what-is-a-controller-afd99a8ebd0a?ref=thedelatorrereview.com) **beforehand.** This can be done by creating a legal person in the form of an association or economic interest group or by identifying one participant who is responsible for making the decisions for the group and designating the said participant as a data controller. Such entity/participant could be considered the controller with the other participants acting as processors provided that the participants that act as processors do not de-facto determine the “purposes and means” of the processing (in which case they will be de-facto controllers). Otherwise, all participants will likely be considered joint controllers subject to joint and several liability and required to determine, in a transparent way, their respective responsibilities to ensure compliance with GDPR (see Article 26 of GDPR). Regarding **software developers for smart contracts solutions**, the algorithm developer may simply be a solution provider or, when the said algorithm developer participates in the processing, may be qualified as a data **processor or data controller depending on its role** in determining the purposes of the processing. For instance, a software developer offers a solution to an insurance company, in the form of a smart contract that enables passengers to be automatically reimbursed when their flight has been delayed. This developer would be qualified as a data processor if he or she intervenes in the processing of personal data, the insurance company being the data controller. The developer should therefore establish a contract with the participant, acting as data controller, specifying each party’s obligations and ensure that the contract reproduces the provisions of Article 28 of the GDPR. On the other hand, if several insurance companies decide to create a permissioned blockchain for their processing operations, the purpose of which is compliance with their KYC (“Know Your Customer”) obligations, they may decide that one of them is the data controller. In this case, the other insurance companies, which validate transactions as miners, are likely to be considered as data processors. ### Lawful basis The core requirement of EU data protection law since its inception has been that information technology should be **used only for purposes that benefit humanity**. In order to achieve this goal, **EU data protection law in general and GDPR in particular require that the purposes for every processing be identified and mandates that they must be legal**. In order to be legal, a purpose must fall within one of six categories of purposes or ‘lawful basis’ (see, GDPR Article 6). Therefore, participants in a blockchain are required to identify and document the **lawful basis** for the processing of personal data. From the six existing lawful basis for processing the four that are most relevant to blockchain are contractual necessity, legitimate interest, public interest and legal obligation. In practice, blockchains will rarely be able to rely exclusively on**‘contractual necessity’** as a lawful basis. This is due the the fact that the use of contractual necessity is only available where the processing is necessary to **fulfil contractual obligations between the controller and the data subject or because the data subject asked the controller to do something required before entering into a contract.** However, contractual necessity may be a viable option form performing some of the processing required for blockchain based smart contracts solutions. Where the processing is carried out on the basis of [**contractual necessity**](https://www.thedelatorrereview.com/what-is-contractual-necessity-under-the-gdpr/): - The specific data being processed should be limited to what is necessary to comply with a contract or enter into a contract. **‘Necessary’** does not mean that processing must be essential for the purposes of performing a contract or taking relevant pre-contractual steps. However, it must be a targeted and proportionate way of achieving that purpose. - The actual existence of an enforceable contract under the law is not required provided that the processing relates to a first step (e.g. provide a quote) and the processing is required for that purpose. Therefore, this lawful base does not apply where the controller takes pre-contractual steps on its own initiative or at the request of a third party. --- > **Where the processing takes place on the basis of contractual necessity, data subjects do not have a** [**right to object**](https://www.thedelatorrereview.com/what-is-the-right-to-object-under-the-gdpr/) **to the processing.** --- [**Legitimate interest**](https://www.thedelatorrereview.com/what-are-legitimate-interests-under-the-gdpr/) is the most flexible lawful base under GDPR but is not always appropriate. A **wide range of interests may be legitimate interests** including the controller´s own interests or the interests of third parties. The processing must be **‘necessary’** to accomplish the legitimate interest, meaning that the processing must be a targeted and proportionate way of achieving a purpose and that controllers cannot rely on legitimate interests if there is another reasonable and less intrusive way to achieve the same result. Controllers must balance their interests against the data subject’s interests. In particular, if data subject’s would not reasonably expect the processing, or it would cause them unwarranted harm, their interests are likely to override the interest of the controller. To rely on legitimate interests controllers must perform a balancing test. There’s **no foolproof formula** for the outcome of the balancing test but the legal requirements to use legitimate interest as a lawful basis can be broken down into **three-parts**: **(1) Purpose test:** are the participants pursuing a legitimate interest? To identify the legitimate interest participants in blockchain should consider what the blockchain is trying to achieve including the potential benefits to the public and the relative importance of those benefits. **(2) Necessity test:** is the processing necessary for that purpose? In order to assess the necessity participants in blockchain should consider if the blockchain actually helps advance the interest identified through the purposes test and if there are other less invasive ways to advance the same interest. **(3) Balancing test:** does the data subject’s interests override the legitimate interest? Blockchain participants must consider the impact of the processing and whether this overrides the interest identified. It can be helpful to consider the nature of the participant’s relationship to the data subjects whose data is processed, the nature of the data itself, the expectations of the data subject, and the potential impact to the data subjects. Processing children’s data should be weighed heavily in the balancing test. --- > **When the processing is done under legitimate interest, data subjects do not have the** [**right to data portability**](https://www.thedelatorrereview.com/what-is-the-right-to-data-portability-under-the-gdpr/)**.** --- here the processing is done on the basis of[**public interest**](https://www.thedelatorrereview.com/what-is-public-task-under-the-gdpr/) no balancing test is required. However, public interest is only available where participants need to process the personal data ‘in the exercise of official authority’ (this covers public functions and powers that are set out in law); or to perform a specific task in the public interest that is set out in law. This lawful base can only be used for blockchain solutions deployed by EU or Member State public authorities or by participants who are performing an underlying task, function or power that has a clear basis in EU or Member State law (see, GDPR article 6.3). --- > **Where the processing is on the basis of public interest, the individual has no** [**right to erasure**](https://www.thedelatorrereview.com/what-is-the-right-to-erasure-or-right-to-be-forgotten-under-the-gdpr/)**, or right to** [**data portability**](https://www.thedelatorrereview.com/what-is-the-right-to-data-portability-under-the-gdpr/)**.** --- Processing on the basis of [**legal obligation**](https://www.thedelatorrereview.com/what-is-legal-obligation-under-the-gdpr/)is only possible where controllers are required to process the personal data to comply with EU or Member State law (see, Article 6 (3) of GDPR)**.** Recital 41 of GDPR confirms that this does not have to be an explicit statutory obligation as long as the application of the law is foreseeable to those individuals subject to it, including clear common law obligations. This lawful basis is available where the overall purpose of a blockchain is to comply with a legal obligation that has sufficiently clear basis in either EU law or Member State common law or statute. Blockchain participants **should be able to identify the obligation** in question, either by reference to the specific legal provision or by pointing to an appropriate source of advice or guidance that sets it out clearly (e.g. a government website or industry guidance that explains generally applicable legal obligations). --- > **Where the processing is on the basis of legal obligation, the individual has no** [**right to erasure**](https://www.thedelatorrereview.com/what-is-the-right-to-erasure-or-right-to-be-forgotten-under-the-gdpr/)**,** [**right to data portability**](https://www.thedelatorrereview.com/what-is-the-right-to-data-portability-under-the-gdpr/)**, or** [**right to object**](https://www.thedelatorrereview.com/what-is-the-right-to-object-under-the-gdpr/)**.** --- Finally, because controllers that process[**special categories of data**](https://www.thedelatorrereview.com/what-are-special-categories-of-data-under-the-gdpr/)must identify a separate lawful base that applies to those categories of data (see Articles 9 and 10 of GDPR), it is advisable for blockchain technology to avoid processing special categories of data. This can make the use of blockchain in the healthcare sector particularly challenging. ### Data subject rights The GDPR was designed to **give control back to individuals**. It strengthened individuals’ rights against those who process their data and, in addition, created new rights. Besides minimizing risks to individuals, as mentioned above, the **format chosen to register the data on a blockchain can also facilitate the exercise of individual rights**. Some rights are entirely compatible with a blockchain. For example, the right to be informed can be complied with by requiring the data controller to provide concise information that is easily accessible and formulated in clear terms before the data subject submits information. The same applies to the right of access or the right to portability. Other rights present special challenges in the context of blockchain. In particular implementing the **right to erasure, the right to object, and the right rectify** can be challenging but there are technical solutions for the exercise of those rights that can move closer towards a compliance with the GDPR. Similar to risk minimization, the choice of a proper cryptological method to store the data allows the data subject to move closer to an effective exercise of his or her rights: erasure of data stored outside of the blockchain and of elements enabling their verification, which allow s for access to the proof recorded on the blockchain to be cut off, making and makes the data difficult and even impossible to retrieve. It is **technically impossible to grant the request for erasure** made by a data subject **when data is registered on a blockchain**. However, when the data recorded on the blockchain is a commitment, a hash generated by a keyed- hash function or a ciphertext obtained through “state of the art” algorithms and keys, the data controller can make the data practically inaccessible and therefore achieve the effects of data erasure. The [CNIL initial assessment ](https://www.cnil.fr/en/blockchain-and-gdpr-solutions-responsible-use-blockchain-context-personal-data?ref=thedelatorrereview.com)on compatibility of blockchain and GDPR (issued November 6, 2018 and available at) gives two examples of this: - The **mathematical properties of some commitment schemes** can ensure that upon erasure of the elements enabling it to be verified, it will be no longer be possible to prove or verify which information has been committed. When a commitment scheme is perfectly hidden, deleting the witness (i.e. the element that allows to verify that a given value is committed in a given commit) and the value committed is sufficient to render the commitment anonymous in such a way that it can no longer be considered personal data. The commitment itself would therefore no longer represent any risk in terms of confidentiality. The information would also need to be deleted in other systems where it has been stored for processing. - **Deletion of the keyed hash functions secret key** would have similar effects. Proving or verifying which information has been hashed would no longer be possible. In practice, the hash would no longer pose a confidentiality risk. Once again, the information would also need to be deleted in other systems where it has been stored for processing. Excluding the specific case of some commitment schemes, **these solutions do not, strictly speaking, result in an erasure** of the data insofar as the data would still exist in the blockchain. However, the schemes allow data subjects to get closer to an effective exercise of the right of erasure. With regards to the [**right of rectification**](https://www.thedelatorrereview.com/what-is-the-right-to-rectification-under-the-gdpr/), the impossibility to modify the data in a block must cause the data controller to enter the updated data in a new block. Indeed, a subsequent transaction can cancel an initial transaction even though the first transaction will still appear in the chain. The same solutions as those applied following a request for deletion of personal data could be applied to erroneous data when such data requires deletion. A careful consideration in advance regarding the **right to restriction**(introduced by Article 18 of the GDPR) and to **human intervention** in the context of entirely automated decision-making (Article 22 Paragraph 3) is required. For example, it could be possible to **restrict the use of data** in smart contracts simply by including this possibility in advance in the program. --- > **It is technically impossible to grant the request for rectification or for erasure made by a data subject when cleartext or hashed data is recorded on a blockchain. It is therefore strongly recommended not to register personal data in cleartext on a blockchain.** --- [**Automated decision**](https://www.thedelatorrereview.com/what-is-the-right-to-an-explanation-under-the-gdpr/) arising from a smart contract is necessary for its performance, given that it enables the fulfilment of the very essence of the contract (i.e., the reason for which the parties concluded the contract). The data subject has a right to obtain human intervention, to express his or her point of view and to contest the decision after the smart contract has been performed. This basically requires the data controller in a smart contract solution to **provide the possibility of human intervention** (allowing the data subject to contest the decision even if the contract has already been performed, and regardless of what is registered on the blockchain). ### Controller and processor obligations: Complying with the **formal obligations of GDPR in term of** [**record keeping**](https://www.thedelatorrereview.com/gdpr-records-of-processing-activities-ropas-explained-a-practical-guide-to-article-30/) **and implementation of specific** [**contractual provisions**](https://medium.com/golden-data/what-must-a-contract-between-a-controller-and-a-processor-include-under-gdpr-12593fa826d5?ref=thedelatorrereview.com) **is a daunting task,** specially in the case of public blockchains where everyone can take part of the validation process. For example, controllers and processors are required to formalize relations through a written contract that must contain certain provisions (see, Article 28 of GDPR). On the other hand, joint controllers (see, Article 26 of GDPR) must determine their respective responsibilities for compliance with GDPR by means of ‘an arrangement’ between them (see Article 26 of GDPR). Both controllers and processors are required to keep records of processing activities (see Article 30 of GDPR). In addition, controllers and processors need to consider their obligations to appoint a [data protection officer](https://www.thedelatorrereview.com/the-gdpr-data-protection-officer-dpo-explained-when-you-need-one-and-what-they-do/), conduct data [protection impact assessments](https://www.thedelatorrereview.com/the-gdprs-dpia-requirement-identifying-assessing-and-mitigating-high-risk-processing/), and implement [data protection by design](https://www.thedelatorrereview.com/data-protection-by-design-and-by-default-under-the-gdpr-what-article-25-requires/). ### Cross-border transfers **Transfers outside of the European Economic Area** (EEA) (a.k.a. ‘restricted transfers’ or ‘cross-border transfers’) can be **particularly problematic**, **especially in the case of public blockchains.** As a reminder, all transactions on the blockchain involve: • a request to validate the transaction (and therefore potentially personal data) being sent to all miners of the chain; • an update to the blockchain by adding a new block on the chain for all participants. However, whether they are miners or not, participants can be located in countries outside of the EU. This therefore raises the question of compliance with obligations for transfers outside of the EU. While **appropriate safeguards** for a transfer outside the EU may be used in a permissioned blockchain, such as standard contractual clauses, binding corporate rules, codes of conduct or even certification mechanisms, these safeguards are **harder to implement in a public blockchain** given that the data controller has no real control over the location of miners. ### Security Regarding the [security requirements](https://www.thedelatorrereview.com/gdpr-data-security-explained-a-practical-guide-to-technical-and-organizational-measures/), the different properties of a blockchain (transparency, decentralisation, tamper-proof and disintermediation) mainly rely on two factors: the **number of participants and miners**, and a set of **cryptological mechanisms.** For **permissioned blockchains**, depending on the potential divergence or convergence of participating actors’ interests, carrying out an evaluation of the **minimal number of miners to prevent a coalition** that could control over 50% of networking power over the chain is recommendable. To illustrate this point, recent cases show that a single entity or individual with greater than 50% of networking computer power can “rewrite the \[blockchain\] transaction history”. (See, article for Technology Review [‘Once hailed as unshakable blockchains are now getting hacked](https://www.technologyreview.com/s/612974/once-hailed-as-unhackable-blockchains-are-now-getting-hacked/?ref=thedelatorrereview.com)”) . A **majority of blockchain “hacks”, however occur at the exchange level**. Industry standard security practices can mitigate those threats. Therefore, it is important to set out technical and organizational security procedures to limit the impact of potential algorithm and security failures on transactions and exchanges, including an emergency plan enabling algorithms to be changed when a vulnerability is identified. An organization that implements a public blockchain should be particularly vigilant to newly identified threats in the context of smart-contracts, since source code is often publicly visible on the blockchain. **Governance of changes to the software** used to create transactions and to mine **should be documented**, **and** technical and organizational **procedures should be set out** to ensure an alignment between planned permissions and practical application. **If** the blockchain is **not public**, the measures implemented to ensure**confidentiality should be considered**. Controllers carrying out processing through transactions on a blockchain should ensure the **security of secret keys used**, for example by ensuring that they are stored on secure media. **Overall the security of blockchain technology is robust.**Organizations can maintain the integrity of a blockchain system by ensuring that the system is well executed from launch, proactively identify algorithm bugs, prevent single entity or organizations from amassing a majority of the network power control, and be aware of newly identified vulnerabilities. These processes, when carefully considered, documented and implemented, both ensure security and contribute toward a blockchain controller’s compliance with the GDPR’s legal obligations. --- ### NOTE: This article was prepared for the Practicing Law Institute (PLI) 20th Annual Conference on Privacy and Data Security Law held in San Francisco May 6 and 7, 2019\. It was published to the [Course Handbook](https://download.pli.edu/WebContent/chbs/251422/251422%5FTwentieth%5FInst%5FPrivacy%5FData%5FSec%5F2019%5FeCHB.pdf?ref=thedelatorrereview.com) (see page 985) --- ## Additional Resources ### Regulatory Guidance and Industry Policy These resources provide additional perspectives on **blockchain technology, its interaction with data protection law, and its potential applications**. They include regulatory guidance on applying the GDPR to blockchain, a broader policy overview of blockchain technology, and an examination of how blockchain may transform industries such as insurance. - **CNIL, Initial Assessment on Blockchain (2018)** — An early analysis from the French data protection authority examining blockchain technology through the lens of the GDPR and identifying practical approaches to data protection compliance. - **Information Technology and Innovation Foundation,** [***A Policymaker’s Guide to Blockchain***](https://itif.org/publications/2019/04/30/policymakers-guide-blockchain/?ref=thedelatorrereview.com) — An overview of blockchain technology designed for policymakers, including its potential applications and policy considerations. - **Information Technology and Innovation Foundation, Blockchain “Policymaker’s Guide”** — Additional ITIF material examining blockchain technology and considerations for policymakers. - [***How Blockchain Will Revolutionize Insurance* (2019)**](https://s0.2mdn.net/dfp/435364/4720753611/1555515454961/index.html?ref=thedelatorrereview.com) — A discussion of how blockchain technology may affect and transform the insurance industry. ### **Related Resources from The de la Torre Review** For readers interested in exploring the concepts discussed in this testimony in greater depth: - [**EU Data Protection Law and the General Data Protection Regulation (GDPR)**](https://www.thedelatorrereview.com/gpdr/) — A comprehensive guide to European data protection law and the GDPR, including its historical foundations, scope, core concepts, principles, lawful bases, individual rights, and principal compliance obligations. - [**Convention 108 Explained: The International Treaty That Shaped Modern Data Protection**](https://www.thedelatorrereview.com/convention-108-explained-the-international-treaty-that-shaped-modern-data-protection/) — Explains the origins and development of Convention 108, the Council of Europe’s landmark data protection treaty, and its modernization through Convention 108+. - [**When Everything Is “Personal”: GDPR vs. CCPA**](https://www.thedelatorrereview.com/when-everything-is-personal-gdpr-vs-ccpa/) — Compares the GDPR’s concept of “personal data” with the CCPA/CPRA’s definition of “personal information,” including the treatment of public, pseudonymous, hashed, deidentified, and household data. - [**What Is Data Protection Law?**](https://www.thedelatorrereview.com/what-is-data-protection-law/) — Explains why European data protection law is distinct from traditional privacy law and how it developed as a legal framework governing the processing of personal data. - [**What Is the Charter of Fundamental Rights?** ](https://www.thedelatorrereview.com/what-is-the-charter-of-fundamental-rights-of-the-european-union/)— Introduces the EU Charter of Fundamental Rights and explains the separate protections for privacy under Article 7 and the protection of personal data under Article 8. - [**Constitutional Data Protection Law**](https://www.thedelatorrereview.com/constitutional-data-protection-law/) — Examines the development of data protection as a fundamental and constitutional right in Europe, including its relationship to the separate right to privacy. - [**What Was the Article 29 Working Party?** ](https://www.thedelatorrereview.com/what-was-the-article-29-working-party/)— Explains the role of the Article 29 Working Party (WP29), which developed influential interpretations of European data protection law before being replaced by the European Data Protection Board under the GDPR. - [**Territorial Scope of the GDPR** ](https://www.thedelatorrereview.com/territorial-scope-of-gdpr/)— Explains when the GDPR applies to organizations inside and outside the European Union, including its extraterritorial application to certain organizations offering goods or services to, or monitoring, individuals in the EU. - [**Material Scope of the GDPR**](https://www.thedelatorrereview.com/material-scope-of-the-gdpr/) — Examines the types of personal-data processing governed by the GDPR and the activities that fall outside its material scope. - [**What Is a Controller?** ](https://www.thedelatorrereview.com/what-is-a-controller/)— Explains the GDPR concept of a controller: the person or organization that determines the purposes and means of processing personal data. - [**What Is a Processor?** ](https://www.thedelatorrereview.com/what-is-a-processor/)— Explains the role of processors that handle personal data on behalf of controllers and the GDPR obligations associated with that role. - [**What Is “Personal Data” Under EU Data Protection Law?** ](https://www.thedelatorrereview.com/what-is-personal-data-under-eu-data-protection-law/)— Examines the GDPR’s deliberately broad definition of personal data and the concept of information “relating to” an identified or identifiable natural person. - [**What Are “Special Categories of Data” Under the GDPR?**](https://www.thedelatorrereview.com/what-are-special-categories-of-data-under-the-gdpr/) — Explains the categories of personal data receiving enhanced protection under Article 9 and the additional conditions that must be satisfied before such data may be processed. - [**What Does “Lawfulness, Fairness and Transparency” Mean Under the GDPR?**](https://www.thedelatorrereview.com/what-does-lawfulness-fairness-and-transparency-mean-under-the-gdpr/) — Examines the first Article 5 principle and the requirements that personal-data processing be lawful, fair, and transparent. - [**What Does “Purpose Limitation” Mean Under the GDPR?**](https://www.thedelatorrereview.com/what-does-purpose-limitation-mean-under-the-gdpr/) — Explains the requirement to collect personal data for specified, explicit, and legitimate purposes and the restrictions on subsequent incompatible uses. - [**What Is “Data Minimization” Under the GDPR?**](https://www.thedelatorrereview.com/what-is-data-minimization-under-the-gdpr/) — Explains why organizations should limit personal data to what is adequate, relevant, and necessary for the purposes for which it is processed. - [**What Does “Accountability” Mean Under the GDPR?**](https://www.thedelatorrereview.com/what-does-accountability-mean-under-the-gdpr/) — Examines the GDPR principle requiring controllers not merely to comply with data protection requirements but also to be able to demonstrate that compliance. The GDPR overview identifies accountability as one of its seven core principles. - [**What Is “Consent” Under the GDPR?**](https://www.thedelatorrereview.com/what-is-consent-under-the-gdpr/) — Explains consent as one of the GDPR’s six lawful bases for processing and the requirements that must be satisfied for consent to be valid. - [**What Are “Legitimate Interests” Under the GDPR?**](https://www.thedelatorrereview.com/what-are-legitimate-interests-under-the-gdpr/) — Examines when controllers may rely on legitimate interests as a lawful basis and the balancing required between those interests and individuals’ rights and freedoms. - [**What Is the “Right of Access” Under the GDPR?**](https://www.thedelatorrereview.com/what-is-the-right-of-access-under-the-gdpr/) — Explains the right of individuals to determine whether their personal data is being processed and to obtain a copy of their data and information about that processing, including applicable limitations and response requirements. - [**What is the "Right to Erasure" (or "Right to be Forgotten") under the GDPR?**](https://www.thedelatorrereview.com/what-is-the-right-to-erasure-or-right-to-be-forgotten-under-the-gdpr/) — Explains when individuals may require deletion of their personal data and the important exceptions that limit the right. - [**What Is the “Right to Object” Under the GDPR?** ](https://www.thedelatorrereview.com/what-is-the-right-to-object-under-the-gdpr/)— Examines when individuals may object to processing based on legitimate interests or public task and the absolute right to object to processing for direct marketing. - [**Controller-to-Processor Transfers: What Article 28 GDPR Requires**](https://www.thedelatorrereview.com/controller-to-processor-transfers-what-article-28-gdpr-requires/) — Explains the GDPR requirements governing relationships between controllers and processors, including the contractual safeguards required by Article 28. - [**GDPR Records of Processing Activities (ROPAs) Explained: A Practical Guide to Article 30**](https://www.thedelatorrereview.com/gdpr-records-of-processing-activities-ropas-explained-a-practical-guide-to-article-30/) — Explains controller and processor recordkeeping obligations under Article 30 and how a ROPA can serve as a broader privacy-governance and accountability tool. - [**Data Protection by Design and by Default Under the GDPR: What Article 25 Requires**](https://www.thedelatorrereview.com/data-protection-by-design-and-by-default-under-the-gdpr-what-article-25-requires/) — Explains the obligation to integrate data protection safeguards into products, services, systems, and business processes from the outset and to apply privacy-protective defaults. - [**The GDPR’s DPIA Requirement: Identifying, Assessing, and Mitigating High-Risk Processing**](https://www.thedelatorrereview.com/data-protection-by-design-and-by-default-under-the-gdpr-what-article-25-requires/) — Explains when a Data Protection Impact Assessment is required, how organizations assess and mitigate risks to individuals, and when prior consultation with a supervisory authority may be necessary. - [**The GDPR Data Protection Officer (DPO) Explained: When You Need One and What They Do**](https://www.thedelatorrereview.com/the-gdpr-data-protection-officer-dpo-explained-when-you-need-one-and-what-they-do/) — Examines when a DPO must be appointed, the DPO’s responsibilities, and the independence and organizational protections associated with the role. - [**GDPR Data Security Explained: A Practical Guide to Technical and Organizational Measures**](https://www.thedelatorrereview.com/gdpr-data-security-explained-a-practical-guide-to-technical-and-organizational-measures/) — Reviews the GDPR’s risk-based security requirements and the obligation to implement appropriate technical and organizational measures to protect personal data. - [**GDPR Data Breaches Explained: Security Incidents, Risk Assessment and Notification Requirements**](https://www.thedelatorrereview.com/gdpr-data-breaches-explained-security-incidents-risk-assessment-and-notification-requirements/) — Explains the GDPR’s personal-data-breach framework, including the 72-hour supervisory-authority notification rule, notification of affected individuals in high-risk cases, and breach record-keeping requirements. - [**When Can Personal Data Leave the EU? A Practical Guide to GDPR International Transfers**](https://www.thedelatorrereview.com/whencanpersonaldataleavetheeu/) — Explains the GDPR rules governing transfers of personal data outside the EU, including adequacy decisions, appropriate safeguards, and derogations. - [**GDPR Codes of Conduct: How They Work and Why They Matter**](https://www.thedelatorrereview.com/gdpr-codes-of-conduct-how-they-work-and-why-they-matter/) — Explains how industry and sector-specific codes of conduct can translate GDPR requirements into practical standards and help organizations demonstrate compliance. - [**GDPR Certifications: Demonstrating Data Protection Compliance**](https://www.thedelatorrereview.com/gdpr-certifications-demonstrating-data-protection-compliance/) — Explains the GDPR certification framework and how approved certification mechanisms can be used to demonstrate compliance with specified data protection requirements. ![](https://storage.ghost.io/c/54/ef/54efeb65-4f2f-479e-b4bb-a9ee526feeaa/content/images/2026/08/Screenshot-2026-07-04-at-4.45.19---PM-17.jpeg)