Source: https://eskommtdaraufan.com/
Timestamp: 2019-04-25 18:27:03+00:00

Document:
For the first time, Bitcoin received a lot of attention was in connection with Silk Road, which was basically an eBay for illegal goods. Bitcoin was used as the primary payment method supposedly because of its anonymity. To this day, many believe that Bitcoin transactions or other Blockchain transactions are anonymous and, therefore, assume the Blockchain technology would guarantee data protection. Wikileaks introduced Bitcoin as a secure and anonymous way to donate.
In 2017. Bitcoin became more popular and with it, the underlying technology of the so-called Blockchain. Blockchain technology cannot only be applied to financial transactions, but it has also been adapted for many other cases, although most projects admittedly are still in the prototype stage. A Blockchain is now used for identity management, for sharing health data, IP – Management, notary services, to name just a few. In many cases, there’s personal data involved. However, most legal scholars and regulators still focus on financial regulations; the question of personal information arises only in the context of Anti-Money-Laundering (AML) or Know-Your-Customer (KYC). A Blockchain contains the entire transaction history, and every user can gain access to it on a distributed ledger without special permission. Since many Blockchain applications contain personal data, it’s important not to forget data protection.
Because of the random alphanumeric addresses, many people assume that a transaction is still anonymous and no personal data is processed, despite the fact that a Blockchain is public. However, the data protection law has a high bar when in it comes to anonymisation, hence it is necessary to take a closer look to determine if a Blockchain can adequately protect personal data.
This paper focuses on an EU (European Union) perspective and on the new EU General Data Protection Regulation (GDPR); under other data protection regulations, the Blockchain could be viewed differently. For readers who are unfamiliar with Blockchain technology, a brief explanation is given before the legal analysis.
First, a review is necessary regarding the question of anonymity. Second, the Blockchain is examined in regard to data protection principles. The paper concludes with some ideas on how data protection could be improved in a Blockchain.
As there are already more than 1,320 different coins or “Blockchains” listed on coinmarketcap, it is impossible to assess all in one paper. The data protection assessment in this paper is, therefore, based on the fundamental principles of a Blockchain and Bitcoin.
A Blockchain is a distributed ledger technology or a decentralised database which keeps continuous records of every transaction. It enables users to transact digitally without the use of an intermediary or a central entity because the distributed ledger solves the double-spending problem. You can picture the ledger as big book in which every new transaction is recorded, but instead of just having one accountant, the book is controlled by many. When and only when the majority of the accountants (nodes) agree is another page with new transactions (block) added to the book. Every page is immutably stapled together with all the other pages (cryptographic hash function). As a result, the transaction can’t be changed. Additionally, every interested party (peer-to-peer) can get a complete copy of the book, and current copies of the book are distributed all over the internet. The immutability of the ledger makes it easy to confirm the rightful owner of some data / digital asset (e.g., cryptocurrency), and a double-spending attempt would be recognised by the accountants, halted and not validated. Creating a double-spending situation would only be possible by rewriting all the transactions.
To prevent the theft of digital assets, the owner has a public and a private key. The Blockchain is asymmetrically encrypted and requires private and public keys to effect transactions. From a public key, a public address can be derived to be used to make a transaction. A sender only needs to know the receiver’s address but not his real name. It is also possible to generate multiple public addresses, which would make it possible to use a new address for every transaction.
Furthermore, there are “Permissionless Blockchain’s,” “Permissioned Blockchain’s,” and “Private Blockchain’s.” Bitcoin, for instance, is a Permissionless Blockchain, which means everyone can participate; it’s entirely open source and accessible. A Permissioned Blockchain provides a hybrid between the ‘low-trust’ provided by a Public Blockchain and the ‘single highly-trusted entity’ model of a Private Blockchain. Popularly called a Consortium Blockchain [Permissioned Blockchain], it is one where instead of allowing any person with an internet connection to participate in the verification of the transaction process or allowing a single company to have full control, a few selected nodes are predetermined. For example — imagine a consortium of 10 companies, each of which operates a device connected to the Blockchain network. If company ‘2’ only trades and shares its invoices with ‘3’, ‘4’ and ‘5’, there is no need for the other companies to be given permission to read the shared data.
A “Permissioned Blockchain” and Private Blockchains are controlled by a controller. The focus of this paper is on Permissionless Blockchains, where there is no noticeable controller.
As previously mentioned, because of the interchangeable addresses, many see a Blockchain transaction as anonymous, which would mean no personal data is processed. However, the GDPR has a very high threshold to perceive data as anonymised. It needs to be kept in mind that the requirements are not written in stone. Some nations have different ideas about anonymity. For instance, the United States gauges anonymisation slightly different than the EU regulations. The GDPR first determines if the data stored on a Blockchain is perceived as anonymous data or as personal under the definition of Article 4 (1) GDPR. Since generic addresses are used, there’s no direct identification.
According to Article 4 (1) GDPR, if the data relates to an identifiable natural person, it is still considered personal data. An identifiable natural person is one who can be identified, directly or indirectly, by reference to an identifier, such as a name, an identification number, location data, an online identifier, or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural, or social identity of that natural person.
To determine whether a natural person is identifiable, all the means reasonably likely to be used should be considered, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification taking into consideration the available technology and technological developments at the time of the processing.
Subsequently, some methods will be described on how to identify a data subject on a Blockchain indirectly.
The public address could already constitute personal data if a third party can link it to a data subject. The use by the EU legislature of the word “indirectly” suggests that, to treat information as personal data, it is not necessary that that information alone allows the data subject to be identified. Furthermore, recital 26 of Directive 95/46 states that, to determine whether a person is identifiable, account should be taken of all the means likely reasonably to be used either by the controller or by any other person to identify the said person. Third-party services – especially exchanges, wallet-services, and online shops – would have the means to identify the person behind an address and create a profile of a data subject by following the transactions on the ledger network. In that regard, a public address is similar to a dynamic IP address and, therefore, could be seen as personal data.
Kaminsky found a way to map a public address to an IP address directly. Since the CJEU qualifies IP – Addresses as personal data, the anonymity is broken as well.
A more complicated method is the analysis of the ledger, which Reid and Harrigan describe. There are several ways in which the user network can be used to deduce information about Bitcoin users. Global network properties can be used, such as degree distribution, to identify outliers. Local network properties can be used to examine the context in which a user operates by observing the user with which he or she interacts either directly or indirectly. The dynamic nature of the user network also enables flow and temporal analyses to be performed.
These are only a few methods to identify a user. The costs and the amount of time required vary for all these methods but are nonetheless reasonably likely to be used.
The opportunity to change a public address for every transaction certainly makes it harder to determine a data subject but not impossible. Besides, not every user is aware of this possibility, and if the address is generated on a third-party service, the address is still known to the service. Even if the user creates the address by himself for every transaction, identification through data-mining is always possible.
As a result, user data is not anonymous, and the GDPR does apply. Therefore, the data should be seen as pseudonymous data. Then again Article 4 (5) GDPR requires the necessary additional information to be kept separately, which is only the case of the user-generated addresses. However, if you take into account that the public ledger could be enough to identify a person, one could even argue the data is not a pseudonym as this information is not kept separate. In my opinion, the use of hashed public addresses should be enough to recognise a Blockchain as pseudonymous data. Ultimately the principles of data protection apply in either case. Thus, the application of pseudonymisation of personal data can reduce the risks to the data subjects concerned and help controllers and processors to meet their data-protection obligations. Applying the principles of data protection will justifiably be more flexible than if information on directly identifiable natural persons were processed, but pseudonymisation is not intended to preclude any other measures of data protection.
Permissioned Blockchain’s, on the other hand, are controlled by one or multiple central authorities (e.g., Banks providing a payment system for their customers). The access is controlled by a central authority; therefore, the data is pseudonymous, and the GDPR is applicable. From a data protection perspective, the central authority is the controller, and multiple authorities are joint controllers. The controller is responsible for compliance with data protection laws.
As a consequence, the GDPR applies to a Blockchain if personal data of data subjects who are in the Union is processed or the controller is established in the EU. It depends on the specific business model. However, even if personal information only entails reference ID numbers, such identifiers are typically unique to a specific person and, therefore, considered personal data.
The processing is lawful if the user has given consent, and depending on the business model, processing could also be necessary, or the controller could have legitimate interests to process data. However, the safest way is to obtain consent, which is problematic on Permissionless Blockchain’s as it is unclear who the controller is, therefore, to whom a user gives consent. “Consent” of the data subject means any freely given, specific, informed, and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her.
Unilateral affirmative consent could be a way to get consent, even without an explicit controller.
[..] In the case of Bitcoin and other financial transactions, consent can be assumed for data processing under Art. 6 (1) GDPR, since the recipient is a participant in the network thereby has a financial advantage from the transaction, nonetheless, this assessment cannot be generalised for cases where additional personal data or data from non-participants of the network is transmitted.
An affirmative consent would only include the transaction but no further processing. Furthermore, a controller could justify data processing as necessary for the performance of a contract. A transaction within a Blockchain needs confirmation and written on a block in the ledger; therefore, it is necessary to process data. Otherwise, the Blockchain system would not work. A fallback argument for a potential controller is the necessity to process data for compliance with a legal obligation or the performance of a task carried out in the public interest. For example, compliance with the respective financial regulation is compulsory in the Blockchain space.
As a result, if the data subject is aware of the Blockchain transaction, consent for a simple transaction can be assumed. For more complex Blockchains where more data is processed, a case-by-case evaluation is necessary.
For a Permissionless Blockchain, fairness should not be problematic as the system is an open source which means an interested party can check the functionality before using a specific Blockchain. It would be problematic in Permissioned Blockchain as a controller could change or manipulate the Blockchain. A similar problem could potentially occur in Permissionless Blockchains if the majority of the Miners decide to make changes, though, in both cases, a data subject could just stop using the Blockchain.
It can be assumed that the Blockchain is transparent as it is inherent that an interested party can access or copy the ledger and comprehend historic transactions. It is expected that direct participants of a Blockchain are aware of the data processing. However, to inform the data subjects in compliance with Article 12 GDPR could pose a problem.
A purpose must be specified, explicit, and legitimate. For the most part, the purpose of a Blockchain is specified in the code. The code defines how and what can be put on a Blockchain, for example, smart contracts. Additionally, users have some control over what kind of data they put on a Blockchain and for which purposes it is used.
The core purpose of a Blockchain is to transact securely and to store a transaction on an immutable database. Only if the digital asset/information is stored on the Blockchain, can it be subjected to a transaction at a later date without the fear of a manipulation by a bad actor. Hence, the long-time storage of the data is a given purpose. As long as a user is aware that the transaction happens on a Blockchain the two purposes (secure transaction and immutable storage) could be seen as specified, explicit, and legitimate. However, due to the public availability of the database, data subjects are particularly exposed to the risk of further processing by third parties.
Further analysis of pseudonymised data is possible within the same controller if the controller has taken technical and organisational measures and if additional information for attributing the personal data to a specific data subject is kept separately. General analysis for governance or to improve a Blockchain should be allowed even for third parties; otherwise, in a decentralised network with no real controller, further essential analysis would not be possible. For example, services like Blockchain.info further trust in the Blockchain. Another analysis is problematic, although challenging, to control on a public ledger. If a third-party service is doing further analysis, it has to be disclosed, and it needs consent of its users.
Only personal data that is necessary to achieve the purpose should be processed. The main purpose is to facilitate a secure transaction. As every participant transacts with a pseudonym, one tool for data minimisation is already part of the system. However, a Blockchain allows adding additional information to each transaction, which will then become part of the immutable ledger. If a Blockchain automatically includes some personal information in a transaction (e.g., number plate of a car), it could be problematic in regard to data minimisation. Whenever possible, this should be considered by the creators of a Blockchain and disclosed transparently. As well, the originator of a transaction can often add more personal data and, in that case, the originator is responsible for amending it lawfully.
The peer-to-peer network allows everyone to make a copy of the data. Therefore, data is stored in multiple places without the possibility of a data subject to object. The storage of the same data in multiple places is in line with data minimisation, as pointed out by Marnau, the principle of data minisimation refers to the minisimation of the information and data points, to reduce the danger of profiling, and not to keep redundant information.
Personal data needs to be accurate and up-to-date. The peer-to-peer concept with an immutable ledger is beneficial to keep accurate data. However, it only shows all the transactions, but it can’t guarantee that the additional data was correct in the first place or that it was updated. The block building and block hashing make it virtually impossible to change an entry retrospectively. The immutable ledger and potentially infinite storage of the data are what makes a Blockchain so attractive, but is problematic regarding data protection. It is not feasible to erase or update personal data on the Blockchain. Hence, the Blockchain counteracts the principle rights of accuracy and storage limitation. The only way to change the ledger retrospectively is if the majority of the participants agree to rewrite all the following blocks which is highly impractical. A controller also could not comply with the right to be forgotten or rectify an entry. The same problems appear in Permissioned Blockchains where the controller is known. Therefore, this is an even bigger problem for Permissioned Blockchains and their controller.
Without going into further detail, one proposed solution by Marnau would be a redactable Blockchain. With this method, it is possible to delete a block which, at the same time, opens up a Blockchain for manipulation. This is not a practical solution, as an essential property of the Blockchain would be lost. At the current state of the technology, it must be accepted that the fact that a Blockchain cannot adequately protect personal data regarding adequacy and data limitation.
A Permissionless Blockchain is, by design, without any central authority, which poses a problem as the GDPR does not recognise data processing without a controller. The EU data protection relies on a central authority who is responsible for compliance. Without a central authority, the GDPR framework loses its effectiveness as the individual’s rights are based on the presence of a controller. Unfortunately, the Blockchain, as a peer-to-peer network, operates directly within this gap of the GDPR framework. The discussion is still controversial, and some legal scholars seem desperate to find a controller. The first possibility that comes to mind is the Miner. However, a Miner can’t control the Blockchain alone and only with a majority can Miners jointly determine the purposes and means of processing. Even a concept of joint control responsibilities would remain opaque and fail to meet the standards of Article 26(1) GDPR, which require transparent and clear allocation of responsibilities. In practice, a single Miner doesn’t have the means to comply with a request. Fasching identifies the developers as controllers. Developers don’t process data themselves. Therefore, they can’t be a controller under the GDPR. However, the developers could be obliged to use a Privacy by Design approach in the development stage. A third option is to consider all the users as controllers, but it needs to be kept in mind that as soon as a user puts a transaction on the Blockchain, the user’s control is lost. It might be correct as a theoretical approach, but in practice, it does not yield a benefit for the data subject.
As a consequence, it is impossible to determine a controller within a Permissionless Blockchain. This is undoubtedly a significant drawback of the Blockchain regarding data protection. I wouldn’t go as far as Isler and call a Blockchain a legal black hole in terms of data protection, however, complete data protection compliance on a Permissionless Blockchain without a controller is not achievable.
The GDPR and Blockchain have an ambivalent relationship. At first glance, a Blockchain looks privacy-friendly. Though, on second look, the core technology prohibits a full GDPR compliance. Undoubtedly, the Blockchain has some valuable properties, for instance, pseudonymisation, peer-to-peer transactions, and the integrity of a Blockchain. Then again, the complete decentralisation, openness, and immutability also create problems as potentially everyone can access the data of a ledger, and this leaves the pseudonymisation open for a de-anonymisation attack. The lack of a central control leaves data subjects and supervisory authorities without a way to enforce their rights.
Without destroying the advantage of a Blockchain, a full data protection compliance will not be possible. This is why a user needs to be made aware if a Blockchain is used. It can be assumed that the early adopters were aware of this. However, if the Blockchain becomes like TCP/IP, the average user will no longer be aware of it, and the service provider must inform their users in a transparent way. Furthermore, a Permissioned (or private) Blockchain is preferable if it involves a lot of personal data.
Contrary to the first cryptocurrency, Bitcoin, most new Blockchain projects start with the release of a whitepaper and a TGE. It’s now common practice to do a compliance assessment and obtain approval from Financial Market Supervisory Authority. The developers should take care of data protection compliance in a similar way by applying a Privacy by Design approach and, if necessary, conduct a data protection impact assessment and consult with the Supervisory Authority. In the development stage, the code can be changed much easier. It would make more sense to a Supervisory Authority to get involved at this stage rather than after the deployment of the Blockchain.
If the identification of the data subject is not one of the purposes of the processing, it is necessary to use technical measures to prevent identification. This could mean to implement more privacy enhancement technologies. For instance, a Blockchain could add “noise” to each transaction to make data-mining through a ledger much more complicated. A Blockchain could make use of “on chain and off chain storage,” or “Zero-Knowledge-Proof” could be implemented. However, some techniques could lead to a conflict with AML, KYC or other laws, which also needs to be considered.
As a result, a Permissionless Blockchain can’t be entirely in compliance with the GDPR; nevertheless, there are some ways to enhance the protection of personal data without losing the advantages of a Blockchain.
 Matthias Berberich and Malgorzata Steiner, Blockchain Technology and the GDPR – How to Reconcile Privacy and Distributed Ledgers, 2 Eur. Data Prot. L. Rev. pp. 422 – 426 (2016), p. 422.
 What Are Addresses on Blockchains? Blockchain Address 101, available at https://blockgeeks.com/guides/Blockchain-address-101/ (accessed 1. December 2017).
https://blog.darwinlabs.io/types-of-Blockchain-public-private-and-permissioned-5b14fbfe38d4 (accessed 1. December 2017).
 see Chris Achatz and Susan Hubbard, US VS. Eu Guidelines for De-identification, Anonymization and Pseudonymization, in: Journal of Internet Law; New York Vol. 20, Iss. 11, (May 2017): 1, pp. 7-10.
 Case C‑582/14, Breyer v Germany (CJEU, 19. October 2016) ECLI:EU:C:2016:779, para. 41 seq.
 cf. Fergal Reid and Martin Harrigan, Chapter 1 – An Analysis of Anonymity in the Bitcoin System, in: arXiv:1107.4524, p. 15.
 Dan Kaminksy, available at https://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011 (accessed 1. December 2017).
 Case C-70/10, Scarlet Extended SA v Société belge des auteurs, compositeurs et éditeurs SCRL (CJEU, 24. November 2011), ECLI:EU:C:2011:771 and Case C‑582/14, Breyer v Germany (CJEU, 19. October 2016) ECLI:EU:C:2016:779.
 Fergal Reid and Martin Harrigan, Chapter 1 – An Analysis of Anonymity in the Bitcoin System, in: arXiv:1107.4524, p. 15.
 More detailed information on different methods can be found in: Fergal Reid and Martin Harrigan, Chapter 1 – An Analysis of Anonymity in the Bitcoin System, in: arXiv:1107.4524; Sarah Azoouvim, Mustafa Al-Bassam and Sarah Meiklejohn, Who Am I? Secure Identity Registration on Distributed Ledgers, in: J. Garcia-Alfaro et. al. (Eds.): DPM/CBT 2017, LNCS 10436, pp. 373 – 389, 2017; Jonas David Nick, Data-Driven De-Anonymization in Bitcoin, Master Thesis ETH, 9. August 2015.
 The MtGox case is practical example for this: see Breaking open the MtGox case, part 1, available at http://blog.wizsec.jp/2017/07/breaking-open-mtgox-1.html (accessed 1. December 2017).
 Article 29 Data Protection Working Party, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 18.
 Matthias Berberich and Malgorzata Steiner, Blockchain Technology and the GDPR – How to Reconcile Privacy and Distributed Ledgers, 2 Eur. Data Prot. L. Rev. pp. 422 – 426 (2016), p. 423.
 cf. Ninja Marnau, Die Blockchain im Spannungsfeld der Grundsätze der Datenschutzgrundverordnung, in: INFORMATIK 2017 – Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, 2017, pp. 1025 – 1036, p. 1033.
 cf. Rainer Böhme and Paulina Pesch, Technische Grundlagen und datenschutzrechtliche Fragen der Blockchain-Technologie, in: Datenschutz und Datensicherheit, 8/2017, pp. 473 – 481, p.479.
 Ninja Marnau, Die Blockchain im Spannungsfeld der Grundsätze der Datenschutzgrundverordnung, in: INFORMATIK 2017 – Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, 2017, p. 1025 – 1036, pp. 1028.
 Article 29 Data Protection Working Party (WP29) Opinion 03/2013 on purpose limitation, 2. April 2013, p. 11.
 Ninja Marnau, Die Blockchain im Spannungsfeld der Grundsätze der Datenschutzgrundverordnung, in: INFORMATIK 2017 – Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, 2017, pp. 1025 – 1036, p. 1028.
 Ninja Marnau, Die Blockchain im Spannungsfeld der Grundsätze der Datenschutzgrundverordnung, in: INFORMATIK 2017 – Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, 2017, pp. 1025 – 1036, p. 1029.
 Ninja Marnau, Die Blockchain im Spannungsfeld der Grundsätze der Datenschutzgrundverordnung, in: INFORMATIK 2017 – Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, 2017, pp. 1025 – 1036, p. 1030.
 cf. Matthias Berberich and Malgorzata Steiner, Blockchain Technology and the GDPR – How to Reconcile Privacy and Distributed Ledgers, 2 Eur. Data Prot. L. Rev. pp. 422 – 426 (2016), p.424.
 Matthias Berberich; Malgorzata Steiner, Blockchain Technology and the GDPR – How to Reconcile Privacy and Distributed Ledgers, 2 Eur. Data Prot. L. Rev. 422 – 426 (2016), p.424.
 Jacek Czarnecki, Blockains and Personal Data Protection Regulations Explained, available at https://www.coindesk.com/Blockchains-personal-data-protection-regulations-explained/ (accessed 05. December 2017); similar Rainer Böhme and Paulina Pesch, Technische Grundlagen und datenschutzrechtliche Fragen der Blockchain-Technologie, in: Datenschutz und Datensicherheit, 8/2017, p. 473 – 481, p.479; Matthias Berberich; Malgorzata Steiner, Blockchain Technology and the GDPR – How to Reconcile Privacy and Distributed Ledgers, 2 Eur. Data Prot. L. Rev. 422 – 426 (2016), p.424; Michael Isler, Datenschutz auf der Blockchain, in: Jusletter 4. Dezember 2017, p. 13.: Marnau, Die Blockchain im Spannungsfeld der Grundsätze der Datenschutzgrundverordnung, in: INFORMATIK 2017 – Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, 2017, p. 1025 – 1036, p. 1033.
 Dóra Petrányi / Marton Domokos, Hungary: Data Protection Aspects of Blockchain, 17. August 2017, available at http://www.cms-lawnow.com/ealerts/2017/08/hungary-data-protection-aspects-of-Blockchain (accessed 05. December 17); Hungarian National Authority for Data Protection and Freedom of Information, A Nemzeti Adatvédelmi és Információszabadság Hatóság állásfoglalása a blokklánc („blockchain”) technológia adatvédelmi összefüggéseivel kapcsolatban, available at http://naih.hu/files/Adatved_allasfoglalas_naih-2017-3495-2-V.pdf (original guideline, accessed 05.12.17); a similar view has Carmen Tang, EU Regime: When Blockchain meets GDPR, in: Asian Legal Business, 1. November 2017, available at http://www.legalbusinessonline.com/news/sponsored-eu-regime-when-Blockchain-meets-gdpr/75053 (accessed 05. December 17).
 cf. Luca Bolognini and Camilla Bistolfi, Pseudonymization and impacts of Big (personal/anonymous) Data processing in the transition from the Directive 95/46/EC to the new EU General Data Protection Regulation, in: Computer Law & Security Review 33 (2017), 171 – 181, p. 175.
 Nagib Aouini, Privacy-preserving techniques using zero knowledge proof in public Ethereum, available at https://www.slideshare.net/nagib2001/privacypreserving-techniques-using-zero-knowledge-proof-in-public-ethereum?trk=v-feed (accessed 15. December 2017).
In den letzten Monaten ist ein eigentlicher Hype um Bitcoin und seine etwas weniger bekannten Crypto-Währungs-Kollegen ausgebrochen. Viele sehen hier bereits die nächste Blase am Entstehen, andere setzen die dahinterliegende Blockchain – Technologie bereits mit der Erfindung des Internets gleich.
Crypto-Währungen basieren alle auf einem dezentralen Verschlüsselungsverfahren und einer dezentralen Erfassung der Transaktionen, dies ermöglicht Peer to Peer (P2P) Transaktionen ohne, dass eine zentrale Clearingstelle benötigen wird. Crypto-Währungen bauen auf der sogenannten Blockchain – Technologie auf. Die Blockchain schafft eine dezentrale Buchhaltung aller Transaktionen und verhindert dadurch eine Manipulation einer einzelnen Transaktion. Die Blockchain birgt noch einige andere Vorteile und kann auf verschiedene Arten eingesetzt werden. Mittlerweile wird die Technologie – neben reinen Währungsapplikation – für diverse andere Anwendungen genutzt.
Obwohl es viele Gemeinsamkeiten in den D-A-CH Ländern gibt – insbesondere die Sprache, unterscheidet sich das Recht dennoch maßgeblich, so auch das Arbeitsrecht.
Dieser Beitrag soll Ihnen liebe Leserinnen und Leser den kleinen aber feinen Unterschied im Arbeitsrecht in der D-CH Region aufzeigen – genauer geht es hier: um die Form einer arbeitsrechtlichen Kündigung.
In Deutschland wird auf die Schriftform abgestellt. Was Schriftform bedeutet ergibt sich aus Paragraph 126 des Bürgerlichen Gesetzbuches, d.h. die Kündigung muss in verkörperter Form schriftlich erfolgen und zusätzlich auch eigenhändig durch Namensunterschrift vom Kündigenden unterzeichnet sein. Eine Kündigung eines Arbeitsverhältnisses via E-Mail, Fax oder Messenger-Diensten (WhatsApp, I-Message etc.) erfüllt die Schriftform nicht und die elektronische Form wird auch explizit ausgenommen.
Beispiel: Will ein Arbeitgeber oder Arbeitnehmer sein Arbeitsverhältnis in Deutschland durch eine Kündigung lösen, so muss er anderen Vertragspartei ein Schriftstück zustellen, woraus sich der Wille der Kündigung ergibt und dieses auch eigenhändig unterschreiben.
Soweit der Arbeitgeber nicht persönlich eine Kündigung eines Arbeitnehmers unterschreiben kann muss, soweit eine Kündigung nicht durch einen Personalchef erfolgt – welches originär hierzu beschäftigt ist und dies auch im Betrieb bekannt ist – immer eine entsprechende Vollmachtsurkunde im Original dem Kündigungsschreiben beigelegt werden. Ansonsten kann der Kündigungsempfänger die Kündigung zurückweisen, wegen fehlender Vollmacht. Soweit eine Kündigung von einer Frist abhängig ist (z.B. Probezeitkündigung, außerordentliche Kündigung) kann dies zu weitreichenden Problemen führen, wenn eine weitere Kündigung – diesmal formgerecht – nicht ohne weiteres später ausgesprochen werden darf.
Das Schweizer Arbeitsrecht ist nicht so streng und lässt sogar eine mündliche Kündigung zu. Die Kündigung ist somit nicht an eine besondere Form gebunden, es sei denn, es wurde im Arbeitsvertrag die schriftliche Kündigung vereinbart. Kommt es aufgrund einer Kündigung zu einem Rechtsstreit, gilt es die Kündigung – falls diese bestritten wird – zu beweisen. Bei einer mündlichen Kündigung kann dies schwierig werden, da bei einer Kündigung meist keine Zeugen anwesend sind. Es steht am Schluss somit Aussage gegen Aussage. Im schlechtesten Fall kann die Kündigung nicht nachgewiesen werden und das Arbeitsverhältnis würde fortbestehen. Es ist daher zu empfehlen, dass die Kündigung in irgend einer Form festgehalten wird, um im Streitfall den Nachweis des Kündigungszeitpunkts erbringen zu können. Anders als in Deutschland, ist ein physisches Schriftstück aber nicht zwingend notwendig. Eine Kündigung eines Arbeitsverhältnisses via E-Mail, Fax oder Messenger-Diensten (Whats-App, I-Message etc.) kann ebenfalls als Beweismittel dienen. Die Nachricht sollte entsprechend gesichert werden, falls ein Chatverlauf ebenfalls vom Gekündigten gelöscht werden könnte, sollte zur Sicherheit noch ein Screenshot gemacht werden und die Kündigung nochmals auf eine andere Art bestätigt werden. Außerdem muss sichergestellt werden, dass der Gekündigte von der Kündigung Kenntnis erhalten konnte, d.h. es sollte nach Möglichkeit ein Messenger-Dienst genutzt werden, bei dem man weiß, dass der Gekündigte diesen nutzt. Einige Messenger zeigen sogar an, wenn eine Nachricht gelesen wurde (sofern nicht ausgeschaltet), was den Nachweis der Kenntnis sogar erleichtern kann. Natürlich muss die Nachricht von einer Person stammen, welche überhaupt dazu berechtigt ist, eine Kündigung auszusprechen. Problematisch wäre es, wenn die Nachricht über das Nutzerkonto des Assistenten oder Assistentin versendet würde.
In der Nachricht muss nicht zwingend kein Kündigungsgrund mitgeteilt werden. Es reicht aus, wenn man lediglich die Auflösung des Arbeitsverhältnisses mitteilt.
Die Kündigung muss aber schriftlich begründet werden, wenn dies von einer Partei verlangt wird (Art. 335 OR). Dies gilt sowohl für die ordentliche wie auch für die außerordentliche (fristlose) Kündigung (vgl. Art. 337 OR).
Wichtig: Aus Beweisgründen wird in der Schweiz daher ebenfalls überwiegend schriftlich gekündigt oder zumindest die mündliche Kündigung nachträglich schriftlich bestätigt und festgehalten.
Beispiel: Will ein Arbeitgeber oder Arbeitnehmer sein Arbeitsverhältnis durch eine Kündigung auflösen, würde eine WhatsApp Nachricht mit einer simplen Mitteilung der Kündigung ausreichen.
Soweit Sie in einem anderen Land Arbeitnehmer beschäftigen oder als Arbeitnehmer tätig sind lohnt es sich rechtzeitig einen fachkundigen Rat einzuholen, denn selbst in der D/CH Region ist das Arbeitsrecht, – wie dieser Artikel zeigt – insbesondere – sind die Form einer Kündigung und Fristerfordernisse sehr unterschiedlich.
Yves Gogniat ist Rechtsanwalt in der Schweiz mit Interessenschwerpunkt IT-, Datenschutz und Arbeitsrecht. Er ist ebenso als Fachautor und Referent tätig mehr Informationen unter www.golaw.ch .
Der Auftragsverarbeiter muss in der Lage sein den Auftraggeber zu unterstützen, wenn eine betroffene Person seine Rechte gemäss Kapitel III der DSGVO geltend macht. Es ist nicht immer eindeutig wie weit diese Rechte gehen, als Auftragsverarbeiter tut man gut daran sich vorgängig Gedanken dazu zur Unterstützung zu machen. Die Datenbank sollte so strukturiert sein, dass einem Auskunftsbegehren ohne übermässigen Aufwand nachgekommen werden kann. Ebenfalls sollten Rechte, wie das Recht auf Vergessen oder Datenportabilität berücksichtig werden. Privacy by Design ist ein guter Ansatz, um Probleme bereits im Voraus zu erkennen und zu lösen. Zusätzlich sollte vertraglich geregelt werden, inwieweit eine solche Unterstützung kostenlos erbracht wird.
Der Auftragsverarbeiter muss in Zukunft ebenfalls ein Verzeichnis über die durchgeführten Datenverarbeitungen führen (vgl. Art. 30 DSGVO). Für Unternehmen mit weniger als 250 Mitarbeitern besteht hier eine Ausnahme. Auf die Erstellung kann verzichtet werden, wenn die Risiken der Verarbeitung nicht so hoch sind. Die Verarbeitung darf nur gelegentlich erfolgen und es dürfen keine sensitiven Daten gemäss Art. 9 Abs. 1 oder Art. 10 DSGVO (bspw. Gesundheitsdaten) verarbeitet werden. Viele Auftragsverarbeiter werden für ihre Kunden regelmässige Verarbeitungen vornehmen, weshalb sie nicht von dieser Regelung profitieren können.
Im Rahmen der Vertragsverhandlungen sollte der Auftragsumfang sowieso bereits möglichst genau definiert werden, durch kleine Ergänzungen in diesem Prozess sollten die zusätzlichen Angaben relativ einfach erfasst werden können. Das Festhalten der verantwortlichen Personen und der durchgeführten Datenverarbeitungen stärkt wiederum die Definition des Auftragumfangs und muss daher nicht nur als administrativer Mehraufwand gesehen werden.
Das Verzeichnis kann elektronisch geführt werden, d.h. ein einfaches Excel File reicht grundsätzlich bereits aus.
Muss der Auftraggeber als Verantwortlicher vorgängig eine Datenschutz-Folgenabschätzung nach Massgabe von Art. 35 DSGVO durchführen, ist der Auftragsverarbeiter dazu verpflichtet diesen zu unterstützten. Oft wäre ein Auftraggeber wohl auch kaum in der Lage eine selbständige Einschätzung vorzunehmen, da die er Verarbeitung ja gerade an den Auftragsverarbeiter ausgelagert hat.
Auditklauseln in Bezug auf den Datenschutz und die Datensicherheit finden sich bereits heute in vielen Verträgen. Das Schweizer Datenschutzgesetz verlangt bspw. bereits heute, dass ein Auftraggeber sich vergewissert, dass ein Auftragsverarbeiter die Datensicherheit gewährleistet. Dies wird oft mit einer Auditklausel gelöst, ob dann effektiv einmal von diesem Recht gebraucht gemacht wird, ist eine andere Frage.
Gemäss Art. 28 lit. h DSGVO sind dem Auftraggeber alle erforderlichen Informationen zum Nachweis der Einhaltung der in diesem Artikel niedergelegten Pflichten zur Verfügung zu stellen und Überprüfungen — einschliesslich Inspektionen –, die vom Auftraggeber oder einem anderen von diesem beauftragten Prüfer durchgeführt werden, zu ermöglichen. Es macht daher Sinn diese Kontrollrechte vertraglich zu regeln, um zu verhindern, dass ein Auftraggeber eine Kontrolle gestützt auf die DGSVO einseitig nach seinen Vorstellungen durchsetzt. Eine Auditklausel kann vertraglich auf verschiedene Arten ausgestaltet werden. Oft wird ein Auftraggeber eine Kontrolle – aufgrund von fehlenden Know-How – nicht selber durchführen wollen, weshalb man sich vorgängig auf eine Auditfirma einigen oder zumindest die Auswahlkriterien festlegen sollte (bspw. Audit durch eine Big4 oder ein ISO – Auditor). Um eine Flut von Audits zu verhindern, werden grössere Auftragsverarbeiter, die standardisierte Leistungen anbieten, kaum ein individuelles Auditrecht akzeptieren. Eine mögliche Kompromisslösung ist, dass der Auftragsverarbeiter in regelmässigen Abständen selbst ein Audit durchführen lässt und den Auftraggebern auf Anfrage Einsicht in den Bericht gewährt. Zusätzlich lässt sich bspw. durch eine 27001 Zertifizierung das Vertrauen in die Sicherheit erhöhen. Bei individuellen Lösungen wird ein solches Vorgehen jedoch nicht immer ausreichen.
Ebenfalls sollte die Kostenfrage geregelt werden. Bei Einzelaudit wird meist der Auftraggeber die Kosten tragen müssen. Teilweise findet sich eine Regelung, dass der Auftragsverarbeiter die Kosten übernehmen muss, sobald grössere Unstimmigkeiten entdeckt werden. Der Auftragsverarbeiter sollte sich nur bei groben Verstössen zu einer Kostentragung verpflichten, da ein Auditor immer noch Verbesserungspotential finden wird.
Zusätzlich ist der zeitliche Intervall zu regeln, bspw. einmal jährlich. Ausserdem sollte vereinbart werden, dass ein Audit ausreichend früh angekündigt werden muss, damit sich der Auftragsverarbeiter vorbereiten kann.
Bis anhin mussten Datenpannen in den meisten europäischen Ländern nicht gemeldet werden. Das verantwortliche Unternehmen ist neu dazu verpflichtet eine Datenpanne zu melden und allenfalls seine Kunden darüber zu informieren. Der Auftragsverarbeiter muss eine solche Datenpanne ebenfalls umgehend an den Auftraggeber melden (Art. 33 Abs. 2 DSGVO). Es müssen daher entsprechende Prozesse geschaffen, um eine Datenpanne zu erkennen und möglichst schnell mit allen relevanten Informationen an den Auftraggeber melden zu können.
Dies kann relativ einfach vertraglich geregelt werden. Der Auftragsverarbeiter muss die entsprechenden Prozesse schaffen, sofern diese nicht bereits formal geregelt sind. Die technische Umsetzung kann sich dagegen schwieriger gestallten, da oft ein externes Rechenzentrum genutzt wird oder die Daten auf verschiedenen Servern verteilt sind, können die Speichermedien nicht physisch zerstört werden. Es muss daher auf technische Hilfsmittel zurückgegriffen werden, bspw. die Daten durch Überschreiben unkenntlich machen. Leider kann mit keiner Lösung eine hundertprozentige Löschung garantiert werden, ein Best Effort muss hier ausreichen. Bei ganz sensitiven Daten könnte die Systeminfrastruktur so aufgebaut werden, dass bei Beendigung die Speichermedien physisch vernichtet werden können.
Die Datenübertragung in ein Drittland ist weiterhin möglich. Die bereits bekannten Anforderungen gelten weiterhin, es muss entweder ein ausreichender Datenschutz bestehen (sicheres Drittland) oder ein solcher durch eine Vereinbarung sichergestellt werden (vgl. Art. 44 DSVGO ff.). Eine solche Regelung kann in einem individuellen Vertrag oder einem EU-Standardvertrag vereinbart werden. Eine BCR oder auch das Privacy – Shield – Abkommen stellen zudem Alternativen dar.
Sofern der Auftragsverarbeiter Datenbearbeitungen für den Auftraggeber vornimmt, welche zur Benennung eins Datenschutzbeauftragten verpflichten (Art. 37 DSGVO), muss er in Zukunft zusätzlich einen eigenen Datenschutzbeauftragten benennen.
Weitere Informationen zum Datenschutzbeauftragten können in meinem früheren Beitrag nachgelesen werden.
Gemäss Art. 27 DSGVO muss auch der Auftragsverarbeiter einen Vertreter in der EU bestimmen, wenn er Daten er Personendaten aus der EU bearbeitet und er nicht bereits eine Niederlassung in einem Mitgliedsland hat.
Nicht nur der Auftraggeber als Verantwortlicher sondern ebenso der Auftragsverarbeiter hat mit der Aufsichtsbehörde zu kooperieren und die zur Erfüllung notwendigen Auskünfte und Unterlagen bereitzustellen (vgl. Art. 31 DSGVO). Bereits heute findet sich in den meisten Verträgen oder NDA’s eine entsprechende Regelung, dass solche Auskünfte von der Geheimhaltung ausgenommen sind. In Zukunft kann eine Aufsichtsbehörde direkt Massnahmen gegen den Auftragsverarbeiter ergreifen und nicht nur gegen den Verantwortlichen.
In bestimmten Fällen kann eine Aufsichtsbehörde direkt Verwarnungen oder sogar Bussen gegen den Auftragsverarbeiter aussprechen. Eine Busse kann im Extremfall bis zu € 20 Mio. bzw. 4% des Jahresumsatzes betragen. Ein Auftragsverarbeiter sollte daher dokumentieren, dass er die Weisungen des Auftraggebers eingehalten hat und falls er Mängel festgestellt hat, diese dem Auftraggeber mitgeteilt hat. Dies kann zumindest das Risiko verringern.
Mit der neuen Datenschutz-Grundverordnung (DSGVO) wird der Datenschutz in der EU vereinheitlicht. Gleichzeitig wird der Schutz der Privatsphäre von in der EU wohnhaften Personen gestärkt, in Zukunft ist es egal, ob deren Personendaten innerhalb oder ausserhalb der EU verarbeitet werden, in beiden Fällen ist das EU – Recht anwendbar. Dies gilt selbst, wenn das bearbeitende Unternehmen keine Niederlassung in der EU hat. Sobald die Verarbeitung dazu dient, Personen in der EU gegen Entgelt oder unentgeltlich Waren oder Dienstleistungen anzubieten findet die DSGVO Anwendung.
Diese strengeren Vorschriften gelten nicht nur für die Auftraggeber (Verantwortliche / Controller) sondern ebenfalls für IT-Dienstleister (Auftragsverarbeiter / Processor), welche Personaldaten im Auftrag eines Unternehmens verarbeiten. Ein Schweizer IT-Dienstleister wird deshalb v von der neuen Gesetzgebung betroffenen sein, wenn er Kunden hat, welche im EU-Raum tätig sind.
Bis anhin lag die Verantwortung für den Datenschutz beim Auftraggeber als Verantwortlichen. Der Dienstleister konnte nur subsidiär und im Innenverhältnis bspw. aus vertraglichen Verpflichtungen haftbar gemacht werden. Neu kann der Auftragsverarbeiter bereits aus Gesetz zur Verantwortung gezogen werden, die DSGVO nimmt ihn viel stärker in die Pflicht.
„Ein Auftragsverarbeiter ist eine natürliche oder juristische Person, Behörde, Einrichtung oder andere Stelle, die personenbezogene Daten im Auftrag des Verantwortlichen verarbeitet (Art. 4 Ziff. 8 DSGVO).“ Der Begriff ist weit gefasst, sobald für den Auftraggeber Personendaten verarbeitet werden, gilt ein Dienstleister als Auftragsverarbeiter oder in der englischen Variante als Processor. Neben dem klassischen Outsourcing, kann auch ein SaaS-Anbieter, ein Rechenzentrum oder gar ein Software-Entwickler darunterfallen.
Die Verarbeitung durch einen Auftragsverarbeiter erfolgt auf der Grundlage eines Vertrags oder eines anderen Rechtsinstruments nach dem Unionsrecht oder dem Recht der Mitgliedstaaten (Art. 28 Abs. 3 DSGVO). Eine vertragliche Regelung ist nicht zwingend notwendig, wird aber weiterhin die einfachste und sicherste Lösung sein. Es müssen der Gegenstand und die Dauer der Verarbeitung, die Art und der Zweck der Verarbeitung, die Art der personenbezogenen Daten, die Kategorien betroffener Personen und die Pflichten und Rechte des Verantwortlichen definiert werden. Nachfolgend werden einzelne Punkte genauer erläutert (vgl. auch Art. 28 Abs. 3 DSGVO).
Je nach Art der Dienstleistung kann die Regelung des Datenschutzes in den Hauptvertrag integriert werden, alternativ wird ein zusätzlicher Vertrag erstellt. Die Kommission aber auch die nationalen Aufsichtsbehörden können Standardvertragsklauseln erlassen, welche direkt verwendet werden können.
Handelt es sich um eine standardisierte Dienstleistung – bspw. eine SaaS – Lösung – ist es für den Auftragsverarbeiter sinnvoll die neuen Regelungen bereits in seine Standardverträge einzuarbeiten.
Des Weiteren sollten interne Datenschutzrichtlinien, Sicherheitsvorschriften, IT-Reglemente, etc. erstellt oder auf die neuen Vorschriften anpasst werden. Dadurch kann eine möglichst hohe Standardisierung der Prozesse erreicht werden, und die Dokumente können als Bestandteile in einen Datenbearbeitungsvertrag eingearbeitet werden. Ansonsten besteht die Gefahr, dass ein Auftraggeber auf seinen eigenen Regelungen besteht, individuelle Regelungen können für den Auftragsverarbeiter jedoch schnell zu Mehraufwand bei der Umsetzung und der Kontrolle führen.
Der Vertrag oder das andere Rechtsinstrument ist schriftlich abzufassen, was auch in einem elektronischen Format erfolgen kann (Art. 28 Abs. 9 DSGVO).
Insbesondere müssen die Sicherheitsanforderungen gemäss Art. 32 DSGVO erfüllt sein. Ebenfalls muss ein Auftragsverarebeiter in der Lage sein, den Auftraggeber bei der Erfüllung seiner Pflichten nach Art. 32 – 36 DSGVO zu unterstützen. Es sollte deshalb beschrieben werden, wo die Daten gespeichert werden und wie der Zugang gesichert wird. Auf der technischen Seite müssen Massnahmen wie bspw. eine Firewall oder ein ausreichender Virenschutz vorhanden sein. Es sollten auch Massnahmen gegen eine unbefugte oder zufällige Vernichtung, einen zufälligen Verlust oder technische Fehler getroffen werden. Eine Regelung für ein ausreichendes Backup ist sinnvoll, sofern der Auftraggeber dies nicht selbst übernimmt. Um ein unbefugtes Ändern, Kopieren oder Bearbeiten zu verhindern, sind unbedingt Zugriff, Zugangsrechte und Kontrollmittel zu treffen. Um nicht mit jedem einzelnen Auftraggeber über diese Massnahmen diskutieren zu müssen, sollten die technischen und organisatorischen Massnahmen in einer allgemeinen Richtlinie festgehalten werden. Wenn überhaupt, sind dann nur noch punktuelle Anpassungen für einzelne Auftraggeber notwendig.
Der Beweis für das Vorhandensein von ausreichenden technischen und organisatorischen Massnahmen kann über die Einhaltung genehmigter Verhaltensregeln gemäß Ar. 40 DSGVO oder eines genehmigten Zertifizierungsverfahrens gemäss Art. 42 DSGVO erbracht werden. Dies stellt zwar nur ein Faktor in der Beurteilung dar, wird aber wohl von vielen Auftraggebern als genügender Nachweis akzeptiert werden. Eine ISO – 27001 Zertifizierung kann ebenfalls ein Faktor darstellen, wobei darauf geachtet werden muss, dass auch alle wesentlichen Punkte nach der DSGVO erfüllt sind.
Der Auftraggeber hat grundsätzlich ein Weisungsrecht, wobei grosse IT-Dienstleister wohl kaum für jeden Auftraggeber eine Sonderreglung schaffen werden. Bei standardisierten Diensten ist vielmehr davonauszugehen, dass die Art und Weise der Datenverarbeitung ebenfalls standardisiert ist. Dies führt dann zu einer take it or leave it Situation für den Auftraggeber. Ein Auftraggeber sollte natürlich trotzdem prüfen, ob die Verarbeitung konform verläuft und allenfalls muss er einen anderen Dienst wählen. Lässt eine standardisierte Applikation zusätzliche Bearbeitungen zu, welche nicht durch den ursprünglichen Zweck gedeckt sind, sollte geprüft werden, ob der Bearbeitungszweck im eigenen Unternehmen entsprechend angepasst werden kann bzw. eine Einwilligung eingeholt werden kann, damit die Dienstleistung ohne Verletzung des Datenschutzes genutzt werden kann.
Der Auftragsverarbeiter muss neu gewährleisten, dass sich die zur Verarbeitung der personenbezogenen Daten befugten Personen zur Vertraulichkeit verpflichtet haben oder einer angemessenen gesetzlichen Verschwiegenheitspflicht unterliegen. Diese Verpflichtung reicht bis zum einzelnen Mitarbeiter hinunter. Die bestehenden Regelungen in Bezug auf die Mitarbeiter müssen überprüft werden oder neu geschaffen werden. Die Mitarbeiter sollten in Zukunft explizit zur Einhaltung des Datenschutzes verpflichtet werden und nicht nur zur Einhaltung der IT-Reglemente.
Der Auftragsverarbeiter darf keinen weiteren Auftragsverarbeiter ohne vorherige gesonderte oder allgemeine schriftliche Genehmigung in Anspruch nehmen. Im Fall einer allgemeinen schriftlichen Genehmigung informiert der Auftragsverarbeiter den Auftraggeber immer über jede beabsichtigte Änderung in Bezug auf die Hinzuziehung oder die Ersetzung anderer Auftragsverarbeiter, wodurch der Auftraggeber die Möglichkeit erhält, gegen derartige Änderungen Einspruch zu erheben (vgl. Art. 28 Abs. 2 DSGVO).
In der Praxis wird sich wohl die allgemeine Genehmigung etablieren. Selbst diese Lösung bleibt umständlich, da der Austausch oder ein Beizug eines Subunternehmers mitgeteilt werden muss. Zu Beginn kann zumindest für die bestehenden Subunternehmer eine Genehmigung eingeholt werden bzw. können diese offengelegt werden (bspw. Rechenzentren, etc.). Es sollte zuerst jeweils geprüft werden, ob ein Subunternehmer überhaupt Zugriff auf Personendaten hat oder in Zukunft unbedingt benötigt. Freelance – Entwicklern könnte bspw. der Zugriff auf aktive Daten eingeschränkt oder verwehrt werden, um eine Meldung zu verhindern. Natürlich sollte jeder Subunternehmer weiterhin zur Geheimhaltung und Einhaltung des Datenschutzes verpflichtet werden.
Allen Subunternehmer müssen vertraglich die gleichen Datenschutzpflichten wie dem Auftragsverarbeiter auferlegt werden, sofern diese Zugriff auf Personendaten haben. Bei einem Verstoss eines Subunternehmers gegen die Datenschutzvorschriften bleibt der Auftragsverarbeiter gegenüber seinem Auftraggeber weiterhin haftbar. Eine entsprechende Kontrolle der Einhaltung ist daher empfehlenswert.
Es gibt verschiedene Gründe, weshalb Daten archiviert werden. Dazu zählen etwa gesetzliche Vorschriften (handelsrechtliche oder steuerrechtliche Pflichten), die Speicherung von Know-How, um Geschäftsvorfälle belegen zu können (z.B. in Haftung- oder Strafverfahren) oder weil die Daten zu einem späteren Zeitpunkt vielleicht noch einmal nützlich sein könnten. Unternehmen steht es offen, ob sie sich für eine traditionelle Archivierung (mit Papierbelegen) oder eine E-Archivierung entscheiden wollen. Momentan findet eine Entwicklung vom manuellen papiergetriebenen Prozessablauf hin zur elektronischen Lösung statt. Gemischte Archive werden dabei zur Regel. Dabei besteht einerseits die Gefahr, dass doppelt archiviert wird (Gefahr der Redundanz) und andererseits, dass die Archive nicht einheitlich und somit nicht auf dem aktuellsten Stand oder lückenhaft sind. Die Lösung besteht in einer detaillierten Verfahrensdokumentation, welche die organisatorische Struktur, den Prozess und die Verantwortlichkeiten umschreibt.
Von der elektronischen Archivierung ist die elektronische Aufbewahrung abzugrenzen. Damit eine elektronische Archivierung vorliegt, müssen die Informationen systematisch inventarisiert und vor unbefugten Zugriff geschützt sein (Art. 8 GeBüV). Die Zugriffe und Zutritte müssen aufgezeichnet werden, damit die Nachvollziehbarkeit stets gewährleistet ist. Die Geschäftsbücher müssen so geführt und aufbewahrt und die Buchungsbelege müssen so erfasst und aufbewahrt werden, dass sie nicht geändert werden können, ohne dass sich dies feststellen lässt (Integrität, Art. 3 GeBüV). Zur Aufbewahrung zulässige Informationsträger sind unveränderbare Informationsträger sowie unter bestimmten Voraussetzungen auch veränderbare Informationsträger (vgl. dazu Art. 9 GeBüV). Der Nachweis des Ursprungs und der Unveränderbarkeit muss erbracht werden. Bei elektronischen Daten ist dieser Nachweis insbesondere dann erbracht, wenn die elektronischen Daten digital signiert sind. Das revidierte ZertES hat hierbei durch die erweiterten Möglichkeiten (bspw. elektronisches Siegel) und der Vereinfachung der Handhabung für Unternehmen, neue Möglichkeiten geschaffen. Es kann jedoch auch auf eine Software – Lösung gesetzt werden, welche alle Änderungen aufzeichnet und loggt. Dadurch kann ebenfalls der Nachweis erbracht werden, dass ein Dokument nicht verändert wurde. Im Gegensatz zu bspw. einem signierten PDF, wird ein Export eines durch eine Software gesicherten Dokuments schwieriger, da der Nachweis auch ohne die Software erbracht werden muss. Es müssen in diesem Fall auch die Log-Files aus der Software exportiert werden, damit der Nachweis der Unveränderbarkeit weiterhin erbracht werden. Die beste Lösung muss daher jeweils auf das Unternehmen bezogen evaluiert werden.
Sind diese Voraussetzungen nicht erfüllt, handelt es sich bloss um eine elektronische Aufbewahrung. Aus Beweisgründen sollten Unternehmen die elektronische Archivierung der elektronischen Aufbewahrung vorziehen.
Neben den Buchführungs- und steuerrechtlichen Aufbewahrungspflichten müssen die elektronischen Dokumente im schlechtesten Fall als Beweismittel verwendet werden können. Dabei kann durch den Medienbruch ein Beweisproblem entstehen, bspw. wenn es auf die Unterschrift auf dem Dokument ankommt. So hat das Bundesgericht in einem aktuellen Urteil die Zulässigkeit eines grafologischen Gutachtens anhand einer digitalisierten Kopie verneint. Da das Original nach der Digitalisierung vernichtet wurde, konnte es nicht mehr als Beweis beigebracht werden. Um dieses Risiko zu vermeiden, sollten Belege, auf denen die Unterschrift oder andere Merkmale des Originaldokuments wesentlich sind, nicht vernichtet, sondern weiterhin im Original archiviert werden.

References: CJEU 
 Art. 6
 Art. 337
 Art. 30
 Art. 9
 Art. 10
 Art. 35
 Art. 28
 Art. 44
 Art. 27
 Art. 31
 Art. 28
 Art. 32
 Art. 32
 Art. 42
 Art. 28
 Art. 3
 Art. 9