In this article, we analyze from a legal perspective how the topic of data protection, in particular the General Data Protection Regulation (GDPR), plays out specifically in the context of blockchain-based databases. In our legal assessment, we distinguish between 1) personal data and 2) machine data. In addition, aspects such as the different legal frameworks and levels of data protection in different countries are addressed. Also, the question of handling company and trade secrets will be discussed. In each scenario, special attention is drawn to the issue of liability. The article assumes the application of German laws.
This article is the fifth publication of the series “legal aspects of blockchain technology” by the Frankfurt School Blockchain Center (FSBC), Datarella, and CMS Hasche Sigle. This research is part of the KOSMoS project, a research project funded by the German Federal Ministry of Education and Research (BMBF) under the funding code 02P17D020. The Frankfurt School Blockchain Center gGmbH and Datarella GmbH are part of the “KOSMoS” consortium. Together with partners from the industry (Schwäbische Werkzeugmaschinen GmbH, Alfred H. Schütte GmbH & Co. KG, ASYS Automatisierungssysteme GmbH), academia (Universität Stuttgart, Hochschule Furtwangen), and software development (inovex GmbH, Ondics GmbH), they create a blockchain-based solution allowing manufacturing companies to establish a DLT-based framework for producing machines in order to a) execute dynamic leasing contracts, b) provide transparent maintenance documentation and c) ensure high-quality documentation of manufactured products.
With the General Data Protection Regulation (GDPR), the issue of data privacy has attracted attention in the public debate. On the one hand, every person and every company operating on the Internet provides and possibly discloses data. On the other hand, data is produced through, e.g., search behavior using search engines. Also, a vast amount of data is created and stored within companies. What does this relate to blockchain technology?
One way to describe a blockchain is to think of it as a decentralized database. Information can be stored on a blockchain in a decentralized way, and it can also be used to manage and automate business processes, e.g. through smart contracts. Therefore, the topic of data protection is closely related to the field of blockchain. There must be clarity on liability issues for all parties involved to ensure smooth, efficient and, above all, secure handling of data. In this article, we distinguish between personal data and machine data for this purpose. Scenarios and issues as when private data like trade secrets are obtained through automatic transmission on a blockchain shared by multiple actors will be addressed. The article also examines how the decentralized character of a blockchain, with nodes located in different countries with differing data protection laws, affects liability issues in the event of a potential damage claim.
Introduction to data protection law
With the GDPR, data protection law has been mostly standardized throughout Europe. The regulation only protects defined personal data (Art. 2 (1) GDPR): Personal data is information that relates to an identified or identifiable natural person (Art. 4 (1) №1 GDPR). In this context, it is sufficient if there is only a certain probability that a person can be identified.
Personal data includes, for example, the following information:
- Jane Sample lives in Any City.
- Description of persons: The boy with shoulder-length hair from Class 1b of school ABC in XYZ has a fountain pen.
- Text in exams:using text analysis, conclusions about a person can be derived.
- IP addresses for website providers:via the Internet Service Provider, a specific person can be identified with reasonable effort.
In contrast, no personal data are:
- 35 persons live in Any City (not referable to one person)
- Machine X is worth EUR 454,323 (not related to a person)
Data accrued by an industrial machine is typically not personal data. For instance, it is impossible to conclude from the information “machine was switched on from 8 am — 6 pm” which worker operated the machine and for how long. It would be a different case if information about the person operating the machine during a specific time was stored or if such information were otherwise obtainable. In this case, this data would be personal data. In the following, the term “machine data” refers to data that does not relate to natural persons and also does not allow personal identification from the data.
If there is personal data in the sense of the GDPR, a so-called “permission requirement” applies: it may only be stored, transferred, and used (processed) if this is permitted by data protection law (Art. 6 GDPR). The natural person concerned (“data subject”) has various rights, e.g., the right of information according to Art. 13, 14 GDPR and the right of deletion according to Art. 17 GDPR. Also, the company is subject to certain obligations under Art. 5 GDPR. For example, personal data may only be collected and stored to the extent necessary for processing (Art. 5 (1) c GDPR).
Assuming a blockchain is to store, for example, information on which a natural person has carried out maintenance on a machine, for this purpose, only pseudonyms should be used, such as hash values. The decoding of these pseudonyms from raw data is carried out outside the blockchain using a conventional database. Suppose an affected person requests the deletion of his or her data. In that case, it is sufficient for the data to be deleted from the conventional database because this means that the pseudonym in the blockchain loses its personal reference and becomes anonymous.
Location of the computer nodes
In most cases, the nodes of a blockchain network are widely dispersed around the world or at least rarely located in one country. This dispersion is a major factor behind the resilience and decentralized nature of blockchain technology. Legally, it is important to discuss, especially in terms of data protection, how data stored on a blockchain in different countries, each with different data protection laws, should be handled. As this could quickly lead to significant complexity, we assume that the nodes are mostly all physically located in EU territory.
In the EU, the location of computing nodes is irrelevant since personal data are equally protected throughout the area (cf. Art. 44 GDPR). However, personal data may not be transferred to third countries unless their protection is also guaranteed in these areas (Art. 44 GDPR). If, for example, data protection in the third country is equivalent to the GDPR, data may be stored there in the same way as in the EU. This is specified by the EU Commission in a specific list. Otherwise, according to Art. 46 GDPR, special contractual clauses, or organizational guarantees are required to protect personal data from unauthorized access. The most important case is the conclusion of the so-called EU standard contractual clauses  between the data exporting and data importing company in the third country. If these are concluded, the level of data protection in this third country is considered adequate, and personal data may be transferred and processed there.
In the U.S., a special rule applies according to which data may also be stored there if the storing company is certified according to the so-called EU-US Privacy Shield and thus offers sufficient assurance that the data are also protected in the U.S. If this is the case — as with Amazon, for example — no EU standard contractual clauses need to be concluded.
When storing personal data on a blockchain, the nodes are only supposed to be located and operated in countries that offer an adequate data protection level according to the GDPR. This particularly applies to all countries of the European Economic Area (EEA), but currently also to other third countries such as Andorra, Argentina, Canada (only commercial organizations), Faroe Islands, Guernsey, Israel, Isle of Man, Jersey, New Zealand, Switzerland, Uruguay, and Japan. Companies from all other countries must conclude so-called EU standard contractual clauses before operating a node.
From a legal perspective, there are far less restrictions regarding where computing nodes are located that process machine data instead of personal data. On the assumption, however, that machine data are protected within the EU, for example, by certain database rights, this protection no longer exists if the data are stored on computer nodes abroad, and the respective foreign legal system does not have a corresponding database right. While other jurisdictions may provide database protection comparable to that in Europe, this would have to be clarified on a case-by-case basis. Besides, the parties are, of course, free to agree on contractual confidentiality clauses which contribute to the protection of machine data.
Obtaining “prohibited” data by automatic transmission
On a blockchain, data is usually synchronized and stored fully automatically. Also, in the future, several companies will use one and the same blockchain for their database. Thus, scenarios may occur in which, for example, illegally obtained data is stored on a blockchain that is also used by a German company, and this data then ends up in the database of the German company. Such specific questions and scenarios need to be discussed and the corresponding legal situation considered.
As such, data is not protected. It can only be “prohibited” to the extent that law regulates it as impermissible to collect, transmit or use certain data.
The processing of personal data by a company without a legal basis is inadmissible. It may result in fines and other measures by data protection supervisory authorities (Art. 58, 83 GDPR) as well as lawsuits by affected persons, e.g., for damages (Art. 79, 82 GDPR).
Sole or shared responsibility. If a company is responsible for the processing of personal data depends on whether it decides on the purposes and means of the processing of personal data (Art. 4 №7 GDPR), i.e., on what grounds and how data is collected, transmitted and otherwise processed. There may also be more than one company responsible at the same time. In the case of such a so-called “shared responsibility”, several companies have an influence on the decision for what purpose and how data is processed (Art. 26 GDPR), such as in the case of Facebook and the respective operators of Facebook fan pages. The shared use of a blockchain can result in shared responsibility, but this depends on the individual case and the contractual constellation. Suppose several companies in a consortium jointly decide about the blockchain. In that case, there are strong indications that they bear joint responsibility and are thus also liable for all data protection violations, even if, for example, the storage of certain personal data on the blockchain violates the law. If a consortium member is held liable by a third party but is not responsible for an infringement, the consortium member can seek recourse from the responsible consortium member.
Practical note: For contracts between consortium members, it is important to delineate responsibilities precisely.
Commissioned processing. In a client/contractor relationship, i.e., when only the client decides on the purpose and means of processing personal data, but the contractor acts on his instructions, this is known as commissioned processing (Art. 28 GDPR). Thus, the contractor (processor) has no influence on the purpose for which and the manner in which personal data is processed and therefore cannot be held responsible for the lawful processing of personal data. An example for a processor is a company that merely hosts a node but does not decide who participates in the blockchain and what it is used for. Since the responsibility in such cases lies solely with the client, the contractor would have indemnification and possibly recourse claims against the client if third parties assert claims against him. Besides, he or she is only liable for the breach of certain obligations. In particular, a processor may only process personal data on the documented instructions of the person responsible (client) (Art. 28 (3) 2 lit. a DSGVO). He or she must indicate if, in his opinion, the processing is unlawful (Art. 28 (3) GDPR a.E.).
In the event of data protection violations, the person responsible (client) is the addressee of fines (Art. 58 (2) lit. i, 83 GDPR) and can be sued for damages and for failure to act (Art. 79, 82 GDPR). However, he or she is not liable if a processor breaches the agreement with him and determines the purposes and means of processing himself/herself (Art. 28 (10) GDPR). For example, the hosting company itself would be responsible and liable if it did not merely store and make available the blockchain node as agreed upon but instead evaluated the data for its own purposes and thus in breach of contract.
In the case of machine data, a risk may exist under certain circumstances. If this machine data originates from third-party databases and can possibly be classified as trade secrets, there is such a risk.
Database rights. Database rights may exist for machine data. If a consortium member adopts substantial parts from external databases without permission, it could infringe the database right of the producer of the original database (Section 87b (1) UrhG). A company is liable if it is a perpetrator, participant, and disturber within the meaning of § 97 (1) UrhG. However, this depends on the individual case. A disturber is someone who intentionally and adequately causally contributes to the infringement of the protected right. For example, if reasonable inspection obligations are violated, this is the case.
A violation of database rights may result in costs for a warning notice (Section 97a UrhG), which amount depends on the economic significance for the database producer. Claims for damages exist only if the infringing company itself has acted negligently or intentionally (Section 97 (2) 1 UrhG). Intent means knowledge and intention with regard to the violation of the data bank rights. Negligence means a breach of due care and diligence (Section 276 (1) BGB). If a company is liable as an interfering party, it will usually also act negligently. The reasonable license costs can be claimed as damages (§ 97 (2) 2 UrhG).
Trade secrets. Furthermore, machine data can include trade secrets. A trade secret is information which is kept secret by effective protective measures and which is not accessible without restrictions (§ 2 №1 GeschGehG). Trade secrets may only be obtained within the limits of §§ 3, 5 GeschGehG (e.g., through independent discovery). Any violation results in a claim for injunctive relief (Section 6 GeschGehG) and damages (Section 10 GeschGehG). These claims always exist only against the violator, i.e., the legal or natural person who obtains, uses, or discloses the trade secret (Sec. 2 №3 GeschGehG). A person who indirectly obtains a trade secret via a third party is only a legal violator if he or she knew or should have known about the violation of the law in accordance with § 4 (3) GeschGehG. Should have known corresponds to the negligence described above. However, there is no general obligation to check all information obtained.
Should data not be classified as trade secrets regardless of whether it is stored on a blockchain, it does not become trade secrets merely because it is stored in that way. As for the reverse case, where trade secrets are stored on a blockchain, it should be examined who has access to this data and how it is protected from access by third parties. In this context, it is also important to take into account that the data can never be deleted from the blockchain.
A company based in Germany is only exposed to claims by the owner of the secrets if it is aware that the transmitted data are trade secrets or that this fact should have been apparent. For instance, if the machine data clearly originates from the competitors’ factories and could not realistically have been obtained legally.
Practical note: A qualification as a trade secret also presupposes the implementation of appropriate protective measures. If the machine data are so important that they should be protected as trade secrets, the consortium members must therefore also take appropriate technical and, in particular, contractual measures to protect the data.
 ECJ, 20.12.2017, Nowak, ECLI:EU:C:2017:994.
 ECJ, 19.10.2016, Breyer, ECLI:EU:C:2016:779 recitals 31–49.
 List of certified companies available at: https://www.privacyshield.gov/list
 See approximately here: https://datenschutz.hessen.de/datenschutz/internationales/angemessenheitsbeschl%C3%BCsse.
 Further information can be found here: https://datenschutz.hessen.de/datenschutz/internationales/eu-standardvertragsklauseln.
 Wiebe, GRUR 2017, 338, 345.
 ECJ, 05.10.2018, Wirtschaftsakademie Schleswig-Holstein, ECLI:EU:C:2018:388.
 BGH, judgment v. 16. 5. 2013 — I ZR 216/11, Children’s High Chairs on the Internet II, GRUR 2013, 1229, 1231.
 BGH, judgment v. 16. 5. 2013 — I ZR 216/11, High Chairs for Children on the Internet II, GRUR 2013, 1229, 1231f.
 Köhler/Bornkamm/Feddersen/Alexander GeschGehG § 2 margin no. 115.
 BeckOK GeschGehG/Hiéramente GeschGehG § 4 Rn. 73.1.
 BeckOK GeschGehG/Hiéramente GeschGehG § 4 Rn. 73.1.
KOSMoS is a research project funded by the German Federal Ministry of Education and Research (BMBF) under the funding code 02P17D020. More information about the project can be found on the website.
If you like this article, we would be pleased if you would forward it to your colleagues or share it on social networks. More information about the Frankfurt School Blockchain Center on the Internet, on Twitter or on Facebook.
Dr. Markus Kaulartz used to be a software developer and is now a lawyer at CMS Hasche Sigle. He specializes in IT and data privacy laws and focuses on challenges arising from the increasing digitalization (FinTech, Blockchain, Smart Contracts, AI, SaaS, etc.). Since Markus’ clients are both innovative startups and tier one global players, he has gained much experience in advising on legal issues of future technologies and new business models, such as blockchain and artificial intelligence. Markus has particular tech expertise and insights that contribute to his legal advisory practice. His input is often sought where challenges arise at the interface of technology and law. Markus is co-editor of the legal handbook on smart contracts and the legal handbook on artificial intelligence and machine learning.
Jonas Gross is a project manager and research assistant at the Frankfurt School Blockchain Center (FSBC) and also works for the KOSMoS research project. His fields of interests are primarily crypto currencies. Besides, in the context of his Ph.D., he has been analyzing the impact of blockchain technology on the monetary policy of worldwide central banks. He mainly studies innovations as central bank digital currencies (CBDC) and central bank crypto currencies (CBCC). You can contact him via email (firstname.lastname@example.org), LinkedIn and via Twitter (@Jonas__Gross).
Constantin Lichti is a research assistant and project manager at the Frankfurt School Blockchain Center (FSBC), and also works for the KOSMoS research project. Furthermore, he is responsible for project proposals and grants as well as studies published at the FSBC. As a doctoral candidate his research interests include public blockchains and their individual adoption, as well as how the discourse on blockchain technology is reflected in (social) media. He graduated from the Technical University of Munich with a master’s degree in industrial engineering and management. You can contact him via email (email@example.com) and LinkedIn.
Prof. Dr. Philipp Sandner is head of the Frankfurt School Blockchain Center (FSBC) at the Frankfurt School of Finance & Management. In 2018, he was ranked as one of the “Top 30” economists by the Frankfurter Allgemeine Zeitung (FAZ), a major newspaper in Germany. Further, he belongs to the “Top 40 under 40” — a ranking by the German business magazine Capital. The expertise of Prof. Sandner, in particular, includes blockchain technology, crypto assets, distributed ledger technology (DLT), Euro-on-Ledger, initial coin offerings (ICOs), security tokens (STOs), digital transformation and entrepreneurship. You can contact him via website (philippsandner.de) mail (firstname.lastname@example.org), via LinkedIn (https://www.linkedin.com/in/philippsandner/), or follow him on Twitter (@philippsandner).
Stephan Raubach works in the business development department of a Lichtenstein-based blockchain incubator. In addition to his studies in business administration at the Frankfurt School of Finance & Management with a focus on digital business, he gained experience through his work at the Liechtenstein blockchain startup Amazing Blocks, especially in the field of tokenization. You can contact him via email (email@example.com) and LinkedIn.