Corporate and consumer users are increasingly embracing hosted information technology solutions. Business models and terminologies vary and include service, rental and advertising-financed offerings, described as Software as a Service (SaaS), hosted solution, cloud computing and with other labels. In line with current nomenclature, this article will use “cloud computing” collectively for all hosted solutions that allow users to obtain additional functionality, storage or processing capacity without having to buy additional devices or software copies. Instead, users access enhanced software, computing power and data storage space on remote servers via existing computers and Internet browsers. This typically means less upfront investment to users and opportunities for leverage, specialization and economies of scale for providers.

While users increasingly embrace cloud computing, data privacy advocates, regulators and lawyers not so much. Critics increasingly raise concerns due to perceived risks for privacy and security of personal data.  To them, cloud computing means primarily that users transfer data to faraway systems they do not understand, own or control. As is often the case with respect to legally and technologically complex topics, oversimplifications, overgeneralizations, buzz words and slogans are quickly established and (ab)used to pursue various policy and competitive agendas, including keeping jobs in-country, protecting local industries and shielding established business models from disruptive alternatives.

In this article, I am taking aim at a dozen myths that tend to cloud the decision-making process regarding data privacy compliance challenges related to hosted solutions. In conclusion, it is a myth that cloud computing is somehow bad or risky for privacy or that it raises insurmountable compliance hurdles. It is a fact that data is far more secure and protected in some clouds than on traditional systems and devices and that compliance requirements are often very manageable—if approached reasonably from the vendor and customer side. For illustration purposes, a global human resources system (HRIS) shall serve as an example of a common application that a multinational enterprise can patch together from decentralized legacy systems, host centrally itself or hire a cloud computing vendor to host; e.g., Workday.

Myth 1: Cloud computing presents fundamentally new and unique challenges for data privacy and security compliance

Fact is that consumers and companies have been entrusting specialized service providers with personal data for a long time, including telecommunications companies, payment processors, accountants and various outsourcing service providers; e.g., payroll, call centers and IT support. For nearly two decades, we have made the Internet an integral part of our information society and economy—and the Internet is founded on the principle of decentralized transfer of data across geographies, devices and connections. Even the very services and models that are currently hyped as “cloud computing” have been promoted for 15 years or so by an up-and-coming industry that initially referred to itself as “application service providers.” Transferring data to service providers and remotely hosted solutions certainly creates challenges—but they are neither new nor unique.

Myth 2: Cloud computing involves more data sharing, and that is inherently bad for privacy

Fact is that transferring data to data processing agents—who process data only on behalf and in the interest of the customer—is very different from transferring data to data controllers, who use data in their own interest and possibly impair the data subject’s privacy. In fact, transferring data to processing agents is so different from transferring to data controllers that German data protection laws define “transfer of personal data” specifically to exclude sharing with data processing agents.

Data sharing with data processing agents is not inherently bad or good for privacy—it is neutral. Companies always need people and data sharing. Companies are a legal fiction. When companies use and process personal data, they have to act through human people, and such human people can be statutory employees, individual independent contractors or employees or contractors of corporate contractors. In either one of these scenarios, it is important that the individual person who processes the data acts on behalf and in the interest of the data controller. And it is important that the data controller in turn complies with applicable data protection laws. It is less relevant for privacy compliance purposes how the data controller company engages and compensates the person who conducts the processing—as employee or independent contractor. It is important that the person follows the law and applicable instructions.

For most companies, the switch from internally maintained human resources databases to an external cloud-based HRIS solution does not result in more sharing or transmission to additional geographies. Most data these days is transferred across geographical borders because it is needed in various locations. Traditionally, data has been shared over the Internet, via myriad devices, connections and persons with access. Switching from paper files, spreadsheets and e-mailing across legacy systems with varying degrees of data protection to a centralized cloud computing solution with access controls will not add to the prevalence of data sharing. Usually, it just means more orderly, organized and secure sharing.

Myth 3: Cloud computing is bad for data security

Fact is that employee malice and negligence; e.g., lost laptop, smart phone, etc., causes many data security breaches, and hacks by cybercriminals are also on the rise.  Whether personal data is safer on a system secured by the data controller in house or an external vendor depends on security measures deployed by each particular organization.  Moving data to the cloud can be a bad thing for data security if the vendor is weak on security and careless. It can be a good thing if the vendor brings better technologies to the table and helps the data controller manage access, data retention and data integrity. And it can be neutral if the vendor’s cloud system is more secure but the way the customer uses the system keeps exposing the data; e.g., because the customer does not configure security to properly restrict data to the appropriate users, the customer uses unsecured connections or the customer downloads data from the cloud to unsecured local devices.

Returning to the example of a global HRIS, each multinational employer needs to ask itself whether its own IT capabilities and security policies are superior to the measures deployed by a specialized vendor that can leverage economies of scale and is motivated by the risk of reputational harm to keep data of its customers secure. If the vendor has better security measures, systems and processes, then cloud computing should be good for data security. If the employer instructs its worldwide employees to stop using spreadsheets on local devices and paper printouts, and instead limits access to data in the HRIS on a need-to-know basis and subject to differentiated controls, then ultimately the risk of unauthorized access, inadvertent disclosures and outdated or inaccurate data should diminish.

Myth 4: Cloud computing causes additional issues under privacy law because data is transmitted internationally

Fact is that most companies are already transmitting data internationally because they use the Internet—for example, to e-mail spreadsheets to various office locations— or because they have subsidiaries, customers, suppliers or channel partners in other jurisdictions. In most cases, data transfers occur because data is needed in different jurisdictions not because of where the data is stored. With respect to employee data in a global HRIS, companies need to cause personal data to be transferred across borders to populate the system—whether they host it themselves or engage a cloud computing service provider.

Myth 5: Data in the U.S. is endangered by the USA PATRIOT Act

Fact is that the United States enacted the Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act (USA PATRIOT Act) in October 2001, following the September 11 terrorist attacks, to help fight terrorism and money laundering activities and to provide certain additional investigative powers to U.S. law enforcement officials. But:

  • These powers are not relevant for most types of data in cloud computing arrangements;

  • The government is much more likely to obtain the data directly from the data controllers; i.e., users of cloud computing services;

  • If the data controller is not based in the United States and has no strong nexus to the United States, chances are the U.S. government is not interested in the data regardless of whether the data is hosted in the United States;

  • If the U.S. government is interested, it can usually obtain access to the data through foreign governments through judicial assistance and cooperation treaties, regardless of where the data is hosted;

  • Similar powers exist in most other countries and data is typically much more at risk of being accessed by governments at the place where the data controller is based, and

  • The USA PATRIOT Act issue is raised to support unrelated agendas, such as protecting local companies or unionized jobs from global competition.


The information that the U.S. government seeks to fight terrorism and money laundering is not what most companies store or process in the cloud. Returning to our global HRIS example, it seems quite unlikely that the U.S. government would be interested in the kind of data that resides in a HRIS system. Even if the U.S. government were interested, it would more likely turn to the employer first to obtain the data, because the employer is more closely connected to the data subjects and may have additional information, and the government would not know initially what cloud services the employer uses. If the employer is located in another country, the U.S. government can typically exercise pressure through some kind of nexus—even Swiss and other foreign banks, for example, had to turn over banking details to the U.S. government due to pressure on their market presence and activities in the United States.

Also, the U.S. government can obtain information through cooperation with foreign governments. The U.S. has entered into mutual legal assistance treaties with over 50 countries, including Canada, Mexico, Australia, Hong Kong and a majority of the EU Member States, as well as a mutual legal assistance agreement with the EU. The cooperation under mutual legal assistance arrangements can include substantial sharing of electronic information between law enforcement authorities in the two countries. Similarly, the G8 nations (Germany, France, the United Kingdom, Italy, Japan, the U.S., Canada and Russia) recently reaffirmed their commitment to enhance the exchange of information and judicial cooperation with respect to individuals involved in acts of terrorism. Accordingly, in most cases, even if information is stored outside of the U.S., it is still possible for U.S. law enforcement authorities to obtain such information through existing treaties or agreements with the jurisdiction in which the information is stored.

In some cases, the additional hurdles established by jurisdictional complications will make a difference, but this difference works both ways. For example, a U.S. bankruptcy court recently refused to hand over e-mails to and from a German resident to the German government.  In this case, the German resident’s privacy was better protected due to the fact that his e-mails were stored in the United States. The German government would have easily gotten access to his e-mail if he had used a German Internet service provider. Most countries around the world allow law enforcement access to private information to a similar extent as in the United States, and many countries have updated their privacy laws to provide for minimum data retention requirements—European telecommunications laws go beyond what the U.S. requires—and otherwise lowered privacy protection standards.

In one of the first cases that raised concerns regarding the USA PATRIOT Act in the context of international outsourcing, a trade union in Canada, the British Columbia Government Service and Employee’s Union, sued the British Columbia Ministry of Health Services. The union tried to prevent the British Columbia government from contracting out the administration of the province’s public health insurance program to a U.S.-based service provider. The union argued that the proposed outsourcing would contravene British Columbia’s public-sector privacy law (FOIPPA) by making the personal health information of British Columbians accessible to U.S. authorities pursuant to the provisions of the USA PATRIOT Act. The court dismissed the case, and the trade union initiative has since been cited as an example of privacy concerns being raised as an excuse for other agendas, such as local job or industry protectionism.

Myth 6: Record keeping laws require data to stay local

Fact is that some tax, bookkeeping and corporate laws in some jurisdictions historically required certain records to stay in country, but such requirements apply only to certain kinds of records and they do not prohibit the transfer of data into the cloud so long as originals or backup copies are also kept local. If and to the extent such laws were to apply to employment records, which is not typically the case in most major jurisdictions, the global employer and HRIS user could still upload copies of the records in to the global HRIS—whether self-hosted or hosted by a cloud computing service provider.

Myth 7: U.S.-EU Safe Harbor doesn’t apply to service provider arrangements

Fact is that the Safe Harbor Principles expressly state that data processors may participate and achieve adequacy through certification, and that the EU Commission ordered European Economic Area (EEA) Member States to consider companies ‘adequate’ if they certify under the U.S.-EU Safe Harbor program, whether they act as data controllers or processors. The U.S.-EU Safe Harbor program has been heavily criticized over the years, and the head of a data protection authority in one German state has even called for a rescission of the program.  However, attention-grabbing calls by local politicians do not seem much more relevant and noteworthy as the occasional buzz around plans by Bavaria to cede from Germany or Texas to cede from the United States. Until the European Union or the United States cancels the Safe Harbor arrangement, all data protection authorities in the 30 EEA Member States are legally obligated to accept that Safe Harbor-certified cloud computing service providers in the United States are as “adequate” as EEA-based service providers.

Of course, data controllers need to verify that each particular service provider can be trusted with personal data, but this requirement applies equally if such provider is based in the United States and Safe Harbor-certified or not certified and based in a Member State of the EEA. When comparing the relative strengths and weaknesses of data protection technologies and laws across geographies, it is worth recalling that the EEA does not only consist of France and Germany, which historically pride themselves of relatively high data protection law and technology standards, but also 28 other countries, some of which have joined the EEA only recently and do not have much of an information technology industry or history of data protection laws.

As a data protection law practitioner and scholar in both Germany and California, I am troubled by calls for an end to cloud computing and data transfers to the United States by German politicians, singling out highly respected global technology leaders headquartered in California with unsubstantiated attacks, while accepting, without any additional scrutiny, the free flow of data in the EEA. Why should a multinational employer assume that its global HRIS is more secure in Bulgaria and Romania—the youngest EEA Member States—compared to California? Nothing from a data protection law, industry and policy perspective supports such double standards. Unsubstantiated attacks do not help advance the discussion but risk provoking concerns regarding local protectionism and national arrogance.

Myth 8: Contractual clauses are unnecessary if the service provider is Safe Harbor-certified

Fact is that the Safe Harbor certification only qualifies a service provider outside the EEA as adequate as a service provider within the EEA is presumed to be. But, European laws require particular contractual clauses for data transfers to any service provider—whether the provider is in the EEA or outside.

A company has to take on three hurdles before it may transfer European personal data internationally—into the cloud or otherwise.  First, the collection and use has to be permitted, based on consent, contractual duties, statute, etc. Second, the transfer has to be justified, and third, the recipient has to achieve adequacy if it is not based in the EEA or a country that has been declared adequate by the EU Commission.  By certifying under the U.S.-EU Safe Harbor, a U.S.-based service provider helps its customers over the third hurdle—adequacy—but the Safe Harbor certification does not justify the transfer as such. Whether a recipient is in the U.S. or in the EEA, the customer has to justify any transfer. In the context of data transfers to other data controllers; i.e., recipients that want to use the data in their own interest, data controllers typically have to obtain consent from the data subject or rely on statutory data transfer obligations. But, when a company transmits data to a service provider, it does not have to obtain consent so long as it retains control over the data via an adequate contractual arrangement. This is where the need for certain particular contractual clauses comes into play.

One option is to sign the Standard Contractual Clauses promulgated by the EU Commission for data transfers to data processors. These are not absolutely required if the service provider is certified under the U.S.-EU Safe Harbor program, because the Safe Harbor certification already provides adequacy. But, the alternative would be to implement agreements that satisfy the national law requirements for agreements with service providers. The templates promulgated, blessed or prescribed by the various data protection authorities in the 30 EEA Member States vary quite a bit, and it is less clear how binding such clauses are and whether they will be accepted without questions and scrutiny in data protection authority approval processes. Consequently, any customer or service provider opting for “self-made” or “national government templates” should be prepared for time- and cost-consuming legal analysis, lengthy negotiations and ultimately a multitude of agreements. By comparison, the European Commission’s SCC may appear more attractive, because all EEA Member States are supposed to accept this form as assuring “adequacy,” it is in both parties’ best interest not to negotiate or modify the SCC—to preserve the preemptive blessing of the  commission regarding adequacy—and one form agreement can be used for the entire EEA.

Myth 9: Data privacy and security law compliance is the provider’s responsibility

Fact is that data privacy and security laws primarily hold the data controller responsible for compliance; i.e., the customer in a service provider relationship. The customer has to ensure that the data made available to the service provider has been legally collected, data subjects have consented or received notice, filings have been made, etc. The service provider has typically only two duties under data privacy laws: The processor has to follow its customer’s instructions and keep the data secure against unauthorized access. The second duty—data security—is also and foremost on the data controller. Therefore, it is important for customer and vendor to reach a reasonable agreement about what level of security is appropriate for particular types of data and who should be doing what. For example, if a customer hires a service provider to store archival statistical data, music files or strongly encrypted information in the cloud, it may not be necessary for the vendor to invest heavily in security features because unauthorized disclosure of such data would not typically harm the data subjects. On the other hand, backup copies of credit card transaction information should be very carefully guarded because such information is actively pursued by hackers to steal identities and commit fraud. Data in an HRIS can also include highly sensitive information; e.g., U.S. Social Security numbers—a primary target for identity thieves and hackers, even though most of the data typically stored in HRIS is of little or no interest to hackers.

If the service provider offers a specialized application for certain types of data that are typically sensitive and worth protecting, the service provider should take the initiative and either implement certain security measures itself, for example, encryption, or recommend that its customers do. Customers should also take the initiative to identify the various compliance obligations that apply to a particular type of data processing activity and then consider which of these obligations can or should efficiently be handled by service providers and which are better discharged by the data controller itself. In the end, the various compliance obligations on the data controller depend on where the data controller is located, and if the data processor is based in another jurisdiction, the data controller will need to educate and instruct the data processor about the compliance requirements that need to be satisfied.

Myth 10: Cloud service providers cannot cede control to their customers

Fact is that many organizations find it difficult to stay in control over modern IT systems, whether they hire service providers to provide IT infrastructure or whether they host, operate and maintain systems themselves. Even with respect to self-operated systems, most companies usually have to work with support service providers who have to be granted access to the systems and data to analyze performance problems, troubleshoot errors and provide support and maintenance. Most companies find it prohibitively expensive to customize systems—whether self-hosted or hosted by a service provider—beyond the configuration options provided by the vendor as part of the standard offering. Consequently, there are significant limits to the degree of control that users can and want to exercise over their systems, whether self-hosted or hosted by a provider.

Yet, from a legal perspective, it is imperative that the service provider remains in the role of a data processor and the customer in the role of the data controller. If the service provider obtains or retains too much discretion about aspects or details of the processing, the service provider could become a co-controller, which is not acceptable for either party. The service provider would suddenly assume all kinds of compliance obligations, including to issue notices to data subjects, assure data integrity, grant access and correction requests, submit filings to data protection authorities, ensure compliance with data retention and deletion requirements, etc. A cloud computing service provider cannot discharge these data controller obligations because it does not know the data subjects or what data is uploaded into its systems. And, if the service provider did in fact qualify as data controller, then the customer would typically violate statutory prohibitions and privacy policy promises regarding data sharing. Therefore, both provider and customer have to work toward an arrangement that keeps the provider limited to the role of a data processor.

In the context of self-hosted systems, it tends to be easier to prove that the provider retains little or no control over the system after delivery. In the cloud computing scenario, on the other hand, the data resides on servers on location that the provider controls. But, it is important to note that “control” from a data protection law perspective refers to “control” of the data—not “control” of the premises where data resides. Landlords, for example, are not viewed as data controllers merely because they own a building where data is stored and have access and repossession rights under contract and statutory law regarding the building and tenant property.

The focus of control regarding cloud computing is to ensure that the customer decides what data to upload, download, access, transfer, delete and otherwise process. This is the case with respect to most cloud computing offerings because the service providers tend to offer a platform or software functionality as a service, without any interest, knowledge or influence regarding data types and processing purposes. For example, with respect to a hosted HRIS, the service provider does not have any interest to view or use the data that the customer uploads and processes, but the customer may need to provide to access data in order to provide support for technical issues. If the parties contractually and technologically assure that the vendor’s personnel only access data on the system to provide the service and prevent support issues, then the customer is nearly as much in control as the customer can be with respect to self-hosted systems.

Nearly, because with respect to self-hosted systems, the customer can monitor and safeguard physical safety and access limits—albeit that in practice, many companies outsource premises security in any event to security service providers. To keep the customer in control, the cloud computing service provider has to provide key information about storage locations, processing practices and subcontractors. Some service providers withhold such information based on trade secret protection objectives and this can create friction with respect to the objective to keep the customer in control for purposes of data protection law compliance.

To resolve such conflicts and keep the service provider in the “processor” role, vendors could disclose to their customers key aspects of their data processing practices, equipment locations and significant subcontractors with access to the customer’s personal data. Also, any contractual clauses to safeguard control and data protection need to be passed on to the subcontractors. In connection with cost-efficiently designed, standardized cloud computing solutions, it can be very difficult and expensive for providers to accommodate customization requests by individual customers. But, a customer can also remain in control over data processing if the customer retains a right to receive prior notice regarding all relevant details of the data processing and changes thereto, so that the customer can withdraw data or change the use of a cloud solution in case changes are not acceptable for certain kinds of data. Or, the customer could agree or instruct the provider to update service and technology from time to time, as the provider deems appropriate, on the condition that the provider will not lessen the security and privacy measures set forth in the agreement. Whether customers and providers also agree on contract termination rights and early termination fees is a commercial point and not prescribed from a data protection compliance perspective.

Myth 11: Vendor has and should accept unlimited liability for data security breaches

Fact is that service providers may not always be able to limit their liability vis-à-vis the data subjects in scenarios where they contract with corporate customers and not the data subjects themselves. If hackers gain unlawful access to employee information residing in a global HRIS, the service provider may be liable directly vis-à-vis the employees under negligence theories—if and to the extent economic harm resulting from data access is covered by tort liability under a particular jurisdiction’s laws.

But, data protection laws do not prescribe the allocation of commercial liabilities between the parties. Sophisticated companies usually slice and dice exposure in various ways in indemnification, limitation of liability and warranty clauses. It is quite common to differentiate in risk allocation clauses based on whether customer and/or service provider contributed primarily to a breach or resulting harm; whether the service provider was in compliance with its contractual obligations, its information security policies and applicable law, and whether a risk materialized that could have affected any other company, including the customer.

Also, cloud service providers are increasingly mindful that they can be held liable for violations of laws by their customers or their customers’ customers, for example in the context of uploaded viruses, illegally copied files and pornographic materials. Such risks are then shifted contractually from the provider to the customer.

Myth 12: Customer needs to have the right to access the provider’s data centers and systems for audit purposes

Fact is that customers need to reserve a right to audit the cloud service provider’s compliance measures.  But, it is also a fact that the service provider may not let customers into its data centers or systems because that would impair the security of other customers’ data. Also, individual audits would be unnecessarily disruptive and costly. As a compromise, cloud service providers can arrange for routine, comprehensive audits of their systems by a generally accepted audit firm and make the results available to all customers. If customers demand additional topics on the audit list, providers can expand the scope of the next scheduled audit, if the customers are willing to pay for the additional effort and the controls are within the scope of the service.

Beyond generally applicable compliance and audit requirements, there can occasionally be additional needs with respect to particular types of data processing arrangements or industries. For example, European laws implementing the Markets in Financial Instruments Directive (2004/39/EC, MiFID) require that regulated entities perform due diligence on their vendors "when relying on a third party for the performance of operational functions which are critical for the performance of regulated activities, listed activities or ancillary services." But, in the context of such special regulatory requirements, it is important to differentiate what types of data and processing services are within and outside scope. If a regulated financial services firm chooses to use a hosted solution for human resources data relating to its own employees, this can hardly be considered a “critical operational function” under financial services regulations. If the same firm were to outsource core functions such as calculations of its funds values, the additional audit requirements may come into play.