The European Commission’s recently proposed regulation
This article explores to what extent the proposed regulation would impact the use of cloud computing in the European Union.
The Current Situation.
The new regulation forms part of the European Commission’s overall strategy for the so-called “digital economy,” which it unveiled in its 2010 paper, A Digital Agenda for Europe.
To further this aim, the proposed regulation has three objectives: to create legal certainty; to simplify the regulatory environment; and to provide clear rules for international data transfers.
Two recent examples in the context of cloud computing provide a timely illustration of the types of problems faced by users of cloud computing that could be resolved by the new regulation.
First, in February 2011, the Danish Data Protection Agency rejected Odense Municipality’s application to use the cloud service “Google Apps” to store data in relation to its public schools (10 PVLR 260, 2/14/11). Odense Municipality stated that data would be transferred initially to Google Ireland Limited. Google subsequently informed the agency that it holds all data in numerous data centers worldwide, including in the United States and Europe. Thus, data would be shared between Denmark and Ireland and then between Ireland and potentially every other country in which Google operates data centers (be it the United States, within the European Economic Area, or others).
The agency’s view was that any Google data centers in the United States would be covered by the EU-U.S. Safe Harbor Framework (Safe Harbor), and, therefore, Odense Municipality was permitted to store data there as well as in Ireland.
However, the agency decided it had to assume that data would be transferred not only to Ireland and the United States, but also to all the other countries in which Google maintains data centers, including those neither in the European Economic Area nor the United States (and covered by Safe Harbor). It therefore deemed that Odense Municipality would not comply with current legislation because it was not proposing to enter into a contract based on the European Commission’s standard contractual clauses with Google’s individual data centers.
A second recent example of current strictures comes from the attitude taken by the Dutch government. In September 2011, it took a hard line against U.S. cloud providers: Government departments were severely restricted in using such providers to process government information technology data. The Dutch government’s reasoning was that the USA PATRIOT Act requires U.S. companies to provide data to the U.S. authorities if requested under the act.
While the Commission undoubtedly wants to promote the establishment and operation of cloud servers within the European Economic Area, many substantial data centers are located elsewhere. This poses a challenge to the Commission: balancing the Digital Agenda and opening the digital economy to EU businesses with the need to have in place adequate safeguards for data transferred outside the European Union.
The legal issues for EU undertakings (whether public sector or private enterprises) wishing to entrust their data to cloud providers are well known and center around two main issues: 1) whether it is appropriate for the cloud customer to entrust security of the personal data to a cloud provider; and 2) whether it can do so when the data might be stored outside the European Union.
The question explored here is whether the proposed new regulation will make these compliance issues easier to navigate.
In addition, the regulation throws up other issues likely to be relevant to cloud computing: an increased enforcement regime (in particular, fines) and data breach notification.
‘Controllers’ v. ‘Processors': Roles, Responsibilities.
The EU Data Protection Directive (the Directive) draws a distinction between a “controller” and a “processor” that pervades all other provisions. Largely, a controller under the Directive has much by way of responsibility, while (at least, in most jurisdictions) the processor has no regulatory responsibility (and has only to comply with the contractual obligations with the controller).
The definitions of “controller” and “processor” remain largely the same under the proposed new regime.
As a departure from the current position that processors have no direct regulatory responsibility, under the new regulation a processor would also have responsibility for security (see Article 30). Moreover, regulators would be able to enforce the provisions of the regulation (and it seems not only those that are expressly stated to be an obligation of the processor, but also more generally (see Articles 52(1)(a) and 53)).
In particular, Article 27 would prevent the processor from processing data except on instruction from the controller or under applicable EU law; Article 28 would require the processor to adequately document its processing; and Article 29 would require the processor to cooperate with any relevant supervisory authority.
At present, many cloud providers would argue that they would be considered to be processors (and thus avoid those obligations placed only on controllers). Nonetheless, following the EU Article 29 Data Protection Working Party’s opinion on the Society for Worldwide Interbank Financial Telecommunication (SWIFT) case
Despite this expansion of regulatory oversight of processors, many cloud providers would still hope that, under the new regime, they would be considered to be processors (and thus avoid even wider regulatory obligations).
Security and Appointing Processors.
Article 30 of the regulation would require both the controller and the processor (in other words, both the cloud customer and the cloud provider) to ensure that there were appropriate security measures in place. Of course, a contract would need to be put in place (Article 26) and this article is substantially the same as the provisions in relation to appointing processors in Article 17 of the Directive, although it is somewhat expanded. Some of these expanded provisions may indeed make it more difficult than the current Directive to use cloud services. For example, the processor could not “enlist another processor” and could be appointed only with the permission of the customers (Article 26(2(d))). This would prevent a software as a service (SaaS) provider, say, from using an infrastructure as a service (IaaS) provider’s services without the customer’s permission. Clearly, cloud providers will include general language to allow sub-contracting at will—but would that be enough in regulators’ eyes to fulfil this requirement?
As is well known, there must be a written contract in place and that contract must oblige the processor to act only on instructions from the customer and require the provider to comply with obligations equivalent to those of Article 17. We return to this below, but note here that due diligence into security would be required.
The regulation proposes the same obligation as appears in the Directive to ensure the controller undertakes appropriate due diligence in relation to the processor.
The Minimum
The regulation would not change the difficulty currently experienced by the customer having to accept a “standard” security offering from most cloud providers. At a minimum, a contract with a cloud provider would deal with security in the most general of terms, such as, “the provider will use reasonable efforts to keep data secure.” More sophisticated customers will (certainly in a traditional outsourcing) wish to set out some level of detail about what in fact will be provided and will have to learn to trust a cloud provider. The economics of the cloud depend on it being a standard offering, perhaps in a multi-tenanted architecture. As such, the provider is not able cost-effectively to tailor its security mechanisms for specific customers.
Other than the dramatic changes in the enforcement regime to be introduced, which may make customers more wary—certainly in the light of the inevitable resistance of U.S. providers being asked to give indemnities for the substantial fines which may be due—nothing in the regulation seems to affect this problem.
Ongoing Monitoring: Contractual Rights to Audit?
A further requirement of the current regime is the obligation in Article 17(2) imposed upon the controller that it must “ensure compliance with the [security] measures” by the processor. This is often interpreted to require the contractual ability to physically inspect the provider’s facilities, and so stated is hard to fulfil in the context of cloud services. If that is the case, then of course nothing has changed and the cloud has not been liberated. If that is what is required, then in a full “cloud” procurement involving data being located in multi-tenanted virtual servers in unspecified locations (perhaps simultaneously and ever-changing) or simultaneously in multiple locations, it would remain nigh on impossible to acquire cloud services when personal data were involved. However, a better view (to which I subscribe) is perhaps that the obligation does not go that far, and that this aspect of the security obligation might be complied with by other controls, such as a requirement for full monitoring and reporting by the provider itself or to undergo full security certification by an accredited organization.
Location of Data and Cross-Border Data Flows.
Much of the adverse commentary relating to the ability of EU customers to use cloud services is based on an assessment that the United States (where many cloud providers are located) does not provide an “adequate” level of protection for personal data as required by Article 25 of the Directive.
Some cloud vendors have recognized this restriction and are willing to give the assurance that data will remain in a particular country (perhaps for additional fees). Some of the major IaaS providers, for example, will tell their EU business customers for at least some of their products that data will reside only in EU server farms.
Other providers, salesforce.com, for example, openly state that their data will not remain in the European Union. If this is the case, then one of the various mechanisms to legitimize that transfer permitted by Article 25 may well need to be put in place.
Position Under the Directive
The following options are currently available:
- Keeping data within the European Union or in a country deemed automatically adequate (by means of a Commission decision under Article 25(6) of the Directive). This of course excludes the United States.
- Safe Harbor: A U.S. cloud provider could be on the Safe Harbor list (salesforce.com and Google Inc. are).
- Standard clauses: Standard clauses are another solution which generally work well from a customer’s point of view, but cloud providers do not like them, as they would have to accept additional liability under the terms.
- “Self-assessment”: This is available in the United Kingdom and certain other countries but not generally throughout the European Union. A customer could “self-assess,” that is, reach its own view that the personal data once transferred are adequately protected. In many cloud situations, when 1) the data are not particularly sensitive, 2) a sensible security diligence has been undertaken, 3) proper contractual language is in place dealing with security, and 4) the cloud provider is a reputable company of substance, it will not be unreasonable for the customer to satisfy itself that there is adequate protection. Many (certainly, U.K.-based) cloud customers will have relied on this.
- For completeness, it is worth noting that there are other methods for legitimizing transfer, although they are unlikely to be helpful for most cloud solutions. Binding Corporate Rules facilitate transfers throughout groups. They may be of use in relation to so-called “private clouds” but not otherwise. Consent to the transfer from all relevant data subjects and also where the transfer is necessary to perform a contract with the data subject are also potentially available.
Position Under the Proposed Regulation
The regulation promises harmonization in particular by being directly applicable. Accordingly, there would be more consistency between various national regulators as to how these rules were applied. However, a downside for those in some countries (such as the United Kingdom) is the lack of flexibility which has been shown to date.
The following options would be available under the regulation:
- Again, keeping data within the European Union or in a country deemed automatically adequate. The regulation proposes greater guidance as to how the Commission determines the adequacy of a particular country (Article 41 of the regulation). Countries deemed adequate under the present regime would not lose that status (Article 41(8)).
- Safe Harbor would also be adopted under Article 25(6) and so would also continue into the new regime by virtue of Article 41(8).
- Standard clauses would remain an option. There is no express saving provision providing that those model clauses approved under the old regime could continue to be used, but nonetheless, that outcome can be expected.
- Binding Corporate Rules, consent, and necessity for a contract all would remain (see Articles 43 and 44).
- Some form of the “self-assessment” method set out above is expressly discussed, but in a manner that is unlikely to be helpful to cloud adoption. Article 44(1)(h) is worth setting out in full:
the transfer is necessary for the purposes of the legitimate interests pursued by the controller or the processor, which cannot be qualified as frequent or massive, and where the controller or processor has assessed all the circumstances surrounding the data transfer operation or the set of data transfer operations and based on this assessment adduced appropriate safeguards with respect to the protection of personal data, where necessary.
Unlike the approach taken in the United Kingdom (or elsewhere) under the “self-assessment” regime, however, the emphasis here seems to be on an ad hoc transfer (not “frequent or massive”) as opposed to the continuing outsourcing of data management to a cloud provider. There are also proposed requirements to document the assessment and to inform the regulator of the fact of a transfer. This is unlikely to be at all useful to a potential cloud customer.
Accordingly, not much is proposed in the provisions around data transfer to facilitate cloud uptake in the European Union. Indeed, the main substantive and relevant change is the proposed removal of the ability of a cloud customer to take its own view on the protection of the data. Many data controllers will see this as an opportunity missed.
Data Breach Notification.
Article 31 of the new regulation proposes a general data breach notification requirement.
However, where the cloud service provider was in fact also a data controller, the obligation to inform the supervisory authority would seem to lie jointly with both parties. Given the relatively complex information requirements prescribed by Article 31(3), there would be the theoretical potential for both parties to inform the supervisory authority independently, with the possibility of conflicting information. It therefore seems that the cloud service contract should specify who would be informing the relevant regulators.
The notification to the supervisory body must contain certain information, including the nature of the breach, recommendations for mitigating the breach, the consequences of the breach, and measures the controller proposes to take to address the breach. The controller must document any breaches (the facts, effects and remedial action taken) sufficiently so that the supervisory authority may verify the controller’s compliance with Article 31.
Lastly, as part of the extraterritorial expansion of the proposed regulation (grabbing the targeted processing of personal data of EU citizens, even by non-EU entities—see Article 3), the obligation to inform the controller would seem to apply also to non-EU-based cloud providers. Thus a U.S. cloud provider would be obliged by the regulation to inform the customer of a breach. (It is a general criticism of this extraterritorial reach that it may be impossible to enforce against non-EU entities, and that criticism applies equally here.)
Enforcement.
Under Article 79 of the regulation, the relevant supervisory bodies in each EU member state would be given the powers to enforce breaches of the regulation against controllers and processors. It is important to note that the sanctions in this article would not be fixed: They are to be “effective, proportionate, and persuasive,” on a case-by-case basis. The supervisory body would have to take into account the nature, gravity and duration of the breach, etc.
In any cloud context, perhaps the biggest issue here is the fact that a failure to comply with the security provisions (Article 30) could lead to a fine of up to 2 percent of the annual worldwide gross income of the entity in breach. The same also would apply if the customer did not report a data breach in contravention of Article 31. Notwithstanding that providers (as processors) may also be liable, given they are directly subject to these articles, a cloud customer of course relies on the provider’s security assurances, and on being informed of a data breach, and may be subject to a fine as a result of the provider’s failure.
Clearly, bigger customers with negotiating power may well be able to extract appropriate indemnities from a cloud provider in relation to any fine resulting from such failures. However, most customers would be forced to contract on the provider’s standard form of contracts. One aspect of cloud computing which is often cited as being different from other technology deals is the take-it-or-leave-it aspect of the technical solution. In keeping with the commercial and technical advantages of the solution being easy to set up, easy to scale, and easy to control changes, it is also equally easy to contract: A customer simply accepts the provider’s terms without question. Customers acquiring a very standard cloud offering would have no scope for negotiating terms.
Where contracts are not negotiated, as a recent study makes clear,
It remains to be seen whether this increased exposure for a breach (in circumstances where financial liability could not be passed on to a cloud provider (clearly, brand damage will never be passed on)) makes customers more hesitant about trusting their data to the cloud.
Conclusion.
It is difficult to see how the regulation would assist the uptake of cloud services within the European Union. The regulatory difficulty that exists under the present Directive would remain (cross-border data flow issues, restrictions on the appointments of sub-processors, and so on), as would certain conceptual difficulties (whether a provider was a processor or a controller).
Moreover, in some respects the position arguably would be more of a hindrance. For example, there would be an increased regulatory burden upon providers (who are at present not subject to substantive provisions directly): They would be responsible for security, and regulators would be able to enforce the regulation directly against the processor. There also would be the potential for substantial fines.
In short, the regulation would solve neither of the two problems currently experienced by EU customers and the service providers seeking to sell to them. In the long term, it may encourage EU customers to use EU service providers, but given the predominance of the United States in this sector, it would do little in the short term to “liberate the cloud.” In this respect, it could be seen as a missed opportunity.
Of course, there is some way to go before the regulation hits the statute book, and business is already commencing an intensive lobbying process.
Learn more about Bloomberg Law or Log In to keep reading:
Learn About Bloomberg Law
AI-powered legal analytics, workflow tools and premium legal & business news.
Already a subscriber?
Log in to keep reading or access research tools.