Cloud providers are required by law and the contract with the corporate customer to exercise due diligences, for example in the context of carrying out data processing (cf. Section3.2.1). Therefore, they have to take technical and organisational measures to implement adequate safeguards and ensure an adequate level of protection(cf. Section 3.1.2). There exist mul- tiple IT security standards and best practices, providing methods for implementing effective safeguards. For instance, the ISO/IEC 27000-series provides guidelines on implementing in- formation security management (i.e, ISO/IEC 27002 [113] and ISO/IEC 27003 [110] in conj. with ISO/IEC 27001 [112]). The ISO/IEC 27000-series has also been adopted in the German ‘IT-Grundschutz’ [30] which provides a comprehensive catalogue of best practices [31].
This section will discuss the legal requirements for safeguards at the cloud provider and identify recommendations and best practices on their implementation in IT security standards. A particular focus is on requirements for technical measures in clouds.
3.3.1 Confidentiality
Frequently, processed data are considered confidential. For personal data, this is the case in general since the data secret applies (Art. 16, Data Protection Directive and §5BDSG). Fur- ther, professional secrets may apply to personal data (§203StGB; see also Section3.2.4). In addition, the secrecy of personal data may apply in a specific context, e.g., the protection of
1IT outsourcing and cloud computing are highly relevant for nursing services due to demands on revenue-cost- optimisation and automated data processing [100]. There already exist cloud offerings specialised for nursing services, e.g., Mobile Pflege Cloud by theDeutsches Medizinrechenzentrum (DMRZ) (http://www.dmrz.
de/mobile-rechtssichere-pflegedokumentation-nach-gesetzlichen-vorgaben.html (last visited:
30.06.2015).
personal data in German social law (§35SGBI and §78SGBX) and the secrecy of telecommu- nications in German (§88TKGand §206StGB). For business data, outsourcing contracts may state non-disclosure agreements. In particular, the trade secret in Germany (§§17, 18UWG) and German tax secrecy1(§30AO) may apply for business data.
To ensure confidentiality, technical and organisational measures have to be implemented by the data processing parties. This is particularly in the context of data protection the case (Art. 17 para. 1 in conj. with recital 46 Data Protection Directive and, in Germany, §9BDSG). For example, in Germany data protection law, technical and organisational measures addressing confidentiality are defined specifically. Corresponding to the appendix to §9 cl. 1 BDSG, control measures have to be implemented for physical access, data access, data usage, and data transfer to ensure that personal data are not disclosed to unauthorised persons. In particular, data encryption is considered an adequate control measure (cl. 3 of appendix to §9 cl. 1BDSG). This implies that the cloud provider generally has to implement these control measures when processing personal data in the cloud.2 Another example of requirements for technical and organisational measures addressing confidentiality can be found in the context of processing tax data. In German tax law, access control measures have to be implemented to protect tax data from unauthorised access (recital 103GoBD). On the other hand, if tax data are encrypted it has to be ensured that there is access in decrypted form (recital 134GoBD; see also Section3.3.3). Regularly, service contracts containSLAsfor confidentiality particularly in the form ofNDAs. These have to be implemented by the cloud provider as well.
In conclusion, data confidentiality and secrecy also have to be ensured in the cloud. This may require implementing access and transfer control including data encryption. However, these measures must not restrict access by (or transfer to) competent authorities.
3.3.2 Authenticity and integrity
Another frequent requirement for data processing is data integrity. To fulfil the service contract, cloud providers have to ensure the correctness of the data processing. Usually,SLAsensuring data integrity (e.g., protection against manipulation and ensured data quality) are included in the service contract. Closely related to integrity is authenticity, which particularly addresses securely identified data sources, recipients and users. Additionally, authenticity is a basic re- quirement for ensuring access, usage, and transmission control and, therefore, for ensuring the confidentiality and secrecy of data (cf. Section3.3.1). Further, data integrity can be of im- portance in the context of inspections – e.g., inspection of the processor by the controller (cf. Section3.2.2) – if it is necessary to prove the correctness of documentation.
Data integrity is explicitly addressed by European data protection law (Art. 6 para. 1 lit. d Data Protection Directive), and German data protection law summarises both authenticity and integrity within the requirement on input control (cl. 2 no. 5 of appendix to §9 cl. 1
BDSG). Further, data integrity is of particular importance for processing tax data. For example
1Mentioned in Common Position (EC) No 24/2002 (annex “statement of the council’s reasons” VIII. 5.).
2This also applies in the context of carrying out data processing. Here, the corporate customer is responsible for their implementation, and the cloud provider is required to implement them by the contract with the corporate customer (cf. Section3.2.1).
in German tax law, tax data must not modified (§146 para. 4AO) and its immutability has to be ensured explicitly (recital 110GoBD).
This implies that in the cloud, too, data integrity has to be protected. The cloud provider may be required (for example, bySLAsin the service contracts) to implement measures that support data integrity. If implementing access, usage or transfer control, the cloud provider has to implement authenticity measures to securely identify involved data sources and persons. This is particularly important when subcontractors are involved (cf. Section3.3.4). Further, authenticity is a prerequisite for implementing multi-tenancy (cf.3.3.5).
3.3.3 Availability
The availability of data and services within the cloud is essential. Without availability the cloud provider cannot fulfil the service contract, and the corporate customers can neither ac- cess their data nor use the contracted services. Moreover, availability is an important require- ment addressed in multiple legal norms. In German data protection law, availability control is an explicitly required measure that has to be implemented (cl. 2 no. 7 of appendix to §9 cl. 1BDSG). Further, German tax regulations require the availability of tax data and related software and hardware1for inspection/investigation by the responsible tax office (recital 118 no. 2 and recital 130GoBD). Furthermore, there are multiple obligations to store data for a specific period of time, for example, German tax data have to be stored for at least six years (§147 para. 3AO). Additionally, data availability may be ended by deletion obligations, for example, accounting data in German telecommunications services must not be stored longer than six month (§97 para. 3TKG). If deletion periods are shorter then retention periods than there is a conflict which is solved in the context of German data protection law by replacing deletion with the blocking of the data (§20 para. 3 and §35 para. 3 BDSGand §84 para. 3
SGBX, respectively). An overview of retention and deletion periods of German legal norms investigated in this thesis can be found in Section3.5.1(see also table tab:selectionPeriods).
Usually, the responsibility for data availability is with the corporate customers since they are controllers (for processing personal data; cf. Section3.2.1) or directly considered respon- sible by applicable legal norms (e.g., tax law requires taxpayers to ensure data availability for tax inspections). However, the cloud provider may also be responsible, for example, upon becoming the controller in the context of transmitting personal data to third countries (cf. Sec- tion3.2.3). Additionally, the outsourcing contract may containSLAson data and service avail- ability which is usually the case since this is an important criterion of service quality. Therefore, the cloud provider has to implement measures to ensure the availability of data and services.
3.3.4 Handling subcontractors
If cloud providers contract hardware providers to operate the hardware infrastructure of the cloud then the hardware providers are considered subcontractors. There may also be other sub- contractors involved by the cloud provider, i.e., service provider, software vendor, hardware
1Software and hardware access are relevant for direct and indirect access by the inspectors (cf. recital 174 and 175 GoBD).
vendor and other cloud provider (cf. Section2.2.1). The lawfulness of involving subcontrac- tors is generally clarified in the contract between cloud provider and corporate customer. This is particularly the case for carrying out data processing (cf. 3.2.1). In this context, the sub- contracts have to correspond to the contracts with the corporate customers and the authority of the corporate customers has to be considered properly (in particular with respect to inspec- tion) [102, part 4 recital 91]. This includes professional secrets, which have to be explicitly addressed in the subcontracts (cf. Section3.2.4).
This implies that the cloud provider has to involve subcontractors carefully. Safeguards also have to be implemented at the subcontractor level, and if the subcontractor are located in third countries anadequate level of protectiongenerally has to be ensured (Art. 25 para. 1 Data Protection Directive). This is particularly true for cross-boarder transmissions in the context of carrying out data processing (cf. 3.2.3). Also, the cloud provider has to ensure that the inspection of subcontractors is possible with respect to fulfilment of orders and implementation of adequate safeguards (also cf. Section3.2.2). Further, restrictions on transmission may limit the legitimate recipients among available subcontractors, for example, in the case of cross- boarder transmissions in the context of carrying out data processing (cf. 3.2.3). In particular, transmission control might be necessary when involving subcontractors.
3.3.5 Multi-tenancy and rule of separation
Within the cloud, software and data of different corporate customers are processed on the same hardware infrastructure and, due to virtualisation, frequently on the same hardware. Multi- tenancy means that the software and data of a single corporate customer are accessible and modified only by the corporate customer him- or herself. In particular, the software and data of each corporate customer are isolated from the software and data of all other corporate cus- tomers. While multi-tenancy is a technical principle, it is also introduced by law, i.e., in general by transmission and access restrictions. Further, for processing personal data the rule of sepa- ration applies (cl. 2 no. 8 of appendix to §9 cl. 1BDSG). The latter includes the segregation of duties, which is not necessarily addressed by multi-tenancy. Segregation of duties ensures that separate duties and particularly contradicting duties are executed by different persons (or parties). Generally, segregation of duties is implemented by organisational controls, but can also be enforced technically, for example, by access control on data, software and hardware. In the context of cloud computing, examples of segregation of duties are separating backup and data processing (for safety reasons) and distributing the hosting of corporate customers among different hardware providers (to support multi-tenancy and transmission control).
3.3.6 Other obligations
Alongside the safeguards mentioned above, there are also organisational obligations addressing process and risk management. Particularly in the financial sector, additional regulations exist that require the implementation of proper risk management (cf. Section3.4.1).
Moreover, German data protection law requires the commission of a data protection officer (§11 para. 4 no. 2 in conj. with §4fBDSG) if there are more than nine employees involved in the processing of personal data, which is usually but not necessary the case for cloud providers
(automation allows the operation of clouds with a small staff). With the upcomingGDPR, the requirements for when a data protection officer has to be commissioned have changed. The threshold is increased to 250 employees (Art. 35 para. 1 lit. bGDPR). Further, commissioning is necessary if nature, scope and/or purposes “requires regular and systematic monitoring of data subjects” (Art. 35 para. 1 lit. bGDPR). Both is unlikely to apply to cloud providers which are involved in IT outsourcing. Therefore, it is likely that these cloud providers do not have to commission a data protection officer after the newGDPRhas entered into force.
For automated data processing within the Cloud, there exist in data protection law noti- fication obligations (Art. 18 Data Protection Directive) which in Germany apply for all data processing parties (§4d para. 1BDSG). The notification obligation does not apply if a data protection officer is commissioned (Art. 18 para. 2 cl. 2 second part Data Protective Directive and, in Germany, §4d para. 2BDSG). or if the data subject has given his or her consent to the data processing (§4d para. 3BDSG).
Further, prior checking of data processing systems may apply (Art. 20, Data Protection Directive and, in Germany, §4d para. 5BDSG). In Germany, this is particularly the case for processing special categories of data and for purposes of evaluating the data subject with re- spect to personality including skills, performance and behaviour (§4d para. 5 cl. 2BDSG). Exceptions are legal obligations to process the data, consent of the data subject, and the neces- sity to process the data in order to establish the execution or cessation of contractual obligation. In these cases, the prior checking may be omitted.
There also exist several retention, deletion and documentation obligations which are in- vestigated in more detail in Section3.5.1. In particular, the results of the inspection of the processor by the controller in the context of carrying out data processing (cf. Section3.2.2) have to be documented (§11 para. 2 cl. 5BDSG). Also, data processing of financial and tax data are subject of documentation (cf. Section3.4.1and Section3.4.2). Documentation is also helpful in supporting the controller to satisfy the rights of private clients and employees of the corporate customer, for instance, the right of access (Art. 12 Data Protection Directive), the right to rectify(Art. 12 lit. b Data Protection Directive), and the right to object (Art. 14 Data Protection Directive).
If there are cross-border transmissions to third countries by the cloud provider then the cloud provider is obliged to satisfy these rights, too, because of becoming controller for these transmissions (cf. Cross-border Transmission).
All obligations mentioned above are organisational but have implications for the technical implementation of clouds. The cloud infrastructure have to support (or at least not hinder) the implementation of the mentioned organisational obligations. This includes particularly the documentation of the cloud infrastructure and operation for the purpose of inspection by the data protection officer, prior checking, and satisfying retention and documentation obligations.