Legal Implications of Cloud Computing -- Part Three (Relationships in the Cloud)
While there is much debate on the IT side as to whether Cloud computing is revolutionary, evolutionary or “more of the same” with a snazzy marketing label, in the legal context, Cloud computing does have a potential significant impact on legal risk. Part three of our ongoing Cloud legal series explores the relationships in the Cloud, and the potential legal implications and impacts suggested by them (if you would like, for context, you can read Part One [the Basics and Framing the Issues] and Part Two [Privacy and the Cloud] of the series.
In the legal world, some take the position that Cloud is no different than “outsourcing”. Unfortunately, making that comparison reveals a misunderstanding of the Cloud and its implications. It is sort of like saying that running is no different than running shoes. Like “running,” outsourcing is a general term describing an activity. In this case the activity involves organizations offloading certain business processes to third parties. Cloud computing (like “running shoes”) is a “new” method for leveraging existing technologies (and technological improvements that have occurred in the past 20 years) that can be used by outsourcers to provide their services more effectively and cheaply (as running shoes represents a technology that can be used to achieve the activity of running more efficiently). In other words, one can outsource utilizing a Cloud architecture provided by a third party, or by using a more traditional dedicated third party hosted technology solution. Both are different technologies or methods for achieving the same activity: outsourcing of business processes.
For lawyers analyzing outsourcing to the Cloud the question is whether the technology, operational aspects and various relationships of a given Cloud transaction create new legal issues or exacerbate known legal problems. To illuminate this question, this post explores the relationships that exist between organizations outsourcing in the Cloud (“Cloud Users”) and those providing services in the Cloud. Coincidentally (or maybe not so much) understanding these relationships is crucial for attorneys that need to address legal compliance risk and draft contracts to protect clients entering into the Cloud.
Dark Opaque Storm Clouds or White Fluffy Transparent Clouds?
When it comes to relationships is the Cloud more like a dark storm cloud that one cannot peer into, or is it more like a fluffy, light and transparent cloud that allows one to see what is happening within? Unfortunately, the current forecast in some areas is for dark Clouds that make it difficult for Cloud Users to understand exactly with whom they are dealing and who is storing and processing their data. Transparency may be elusive and the very nature of the Cloud computing architecture may be the cause of this. In other words, even if an attorney wants to discover who is actually processing their data, the nature of the Cloud may make it very difficult for Cloud providers to provide definitive information on that point. This is in stark contrast to most traditional outsourcing relationships involving a single vendor and dedicated computing resources or software.
Moreover, even if all the Cloud players are known, it may be difficult for Cloud Users to manage and shift responsibility to a party that it has no direct relationship with, and no direct contractual legal rights or remedies.
In a traditional dedicated outsourcing model (e.g. web or data hosting, ASP model, etc.) organizations often deal with a single service provider that provides computing resources. That service provider typically would own or control the computing resources that support the outsourcing transaction. Oftentimes those computing resources would be dedicated solely to a particular client. To clarify and solidify this one-to-one relationship the outsourcing contract might have a clause prohibiting the use of sub-contractors to provide the services. In terms of legal risk, the organization utilizing the service provider would be able to conduct its due diligence (e.g. privacy compliance, “reasonable security,” etc.) on a single entity. Moreover, the organization would be able to negotiate a contract shifting risk between it and the service provider knowing that the service provider in essence directly “controlled” the risk by virtue of its control of the computing environment. Even in cases where a service provider uses a sub-contractor, in the typical case, the organization could fairly easily discover the identity of that party and perform its due diligence. More rare are instances of generic unidentified sub-contractors, or sub-contractors utilizing sub-sub-contractors.
Relationships in the Cloud: Who is processing my data?
It can be very different in the Cloud (click here to view one version of the Cloud landscape). This is not to say that Cloud relationships are not/cannot involve one-to-one relationships like traditional outsourcing. They can. At the base of the Cloud stack, it would not be unusual for IaSS providers to have direct relationships with some of their end-clients. For example, if an organization contracts directly with Amazon Web Services, a Cloud Platform (Infrastructure as a service – IaaS), to allow the organization to build its computing resources in Amazon’s Cloud, it would have a degree of confidence that it was dealing with the party that directly controlled and was responsible for maintaining the Cloud Platform. However, there are service-oriented organizations (integrators) that will actually help to build computing resources on a particular Cloud Platform. In that case a client would not necessarily have a direct relationship with the Cloud Platform, and yet would be subject to the limitations and problems of the Cloud Platform.
The problem is more prevalent as one moves up the Cloud stack. Companies that offer software as a service (SaaS) may have built their application within a particular Cloud Platform (examples can be found here, here, here, here and here). The Cloud User again would typically be dealing solely with the SaaS provider despite the fact that the Cloud User’s data is actually being stored and processed (in part or whole) by the Cloud Platform (at the PaaS or IaaS layer). In fact, it is possible that a particular Saas may actually serve its application on multiple Cloud Platforms. Those Cloud Platforms again are one step removed from the Cloud User and each may pose different legal risks. For example one Cloud Platform may have servers across the globe thereby potentially exposing a Cloud User to multiple privacy laws in various jurisdictions, while another may be purely domestic (thereby limiting the jurisdictions to which it the Cloud User may be exposed). In fact, there may be significant economic incentives for SaaS providers to switch between Cloud Platforms that are more efficient or less expensive (thereby improving the SaaS profit margin).
To make the situation more complex, it is also possible for a particular SaaS to use more than one Cloud Platform for an individual Cloud User client. In these cases, data processing might alternate between multiple Cloud Platforms (either because it provides for better efficiencies or perhaps a particular Cloud Platform provides the SaaS with a better price/profit margin). Again, in the legal context this can be problematic. If a SaaS decides to move processing to a Cloud Platform with weak security for example, it could significantly increase the liability risk of a Cloud User if the platform suffers a security breach. It would be very difficult to perform adequate “due diligence” where data is constantly shifting between multiple Cloud Platforms.
Cloud Service Aggregators
Unfortunately, this may be just the tip of the iceberg. In the foregoing example the Cloud User was at least dealing with a single Cloud SaaS provider on the front end. This would not be the case when dealing with Cloud service aggregators. Aggregators essentially bundle (and possibly integrate) multiple SaaS services into a “single” service (examples of aggregation models are here and here). For example, one could envision an aggregator bundling multiple Cloud SaaS offerings for use by travel agents (you can search for examples of SaaS providers serving industry verticals here). The bundle might include a customer relationship management application, a booking and reservations application, a credit card processing application, a billing platform, an international time zone translator application and an electronic signature/e-commerce application. To the Cloud User this bundle would appear to be a single seamless consolidated application.
The reality is that each of the applications may be operated or created by separate SaaS providers. It is also possible that each of these SaaS providers might serve their application on a different Cloud Platform. There may be variations in each application in terms of reliability and security. Moreover, as discussed above each SaaS provider might be using multiple Cloud Platform’s and that use may not remain static (e.g. it’s a moving target). While aggregation models appear to be just gaining traction they could become more prominent going forward, and legal and security/privacy impacts of these models need to be carefully scrutinized.
The Legal Conundrum
The scenario described above poses significant legal challenges for Cloud Users’ transactional and compliance counsel (as well as security and privacy professionals). Due diligence and contracting are potentially much more difficult when the Cloud is involved.
In some cases the Cloud User may be two or three levels removed from the organizations actually processing and storing the Cloud User’s data. For example, without a direct relationship with the lowest level Cloud Providers, organizations will not be able to directly analyze compliance issues around privacy and security compliance and reasonableness. As such Cloud Users will have to somehow confirm that the direct party they are dealing with engaged in proper due diligence. It almost becomes a meta analysis: due diligence might involve a Cloud User analyzing whether a Cloud Provider’s due diligence process itself was adequate. This would likely include receiving any reports or other types of analysis performed by the higher and lower level Cloud Providers. As discussed below it should also include a review of the contracts the higher layer Cloud Provider has with the level below it.
Of course it more than two levels are involved or there are multiple service providers or Cloud Platforms involved on a particular level, one must have confidence that each of the players also performed adequate due diligence on the providers it utilizes, and so on. So in essence, the Cloud User would be seeking to somehow validate that the Cloud Provider performed adequate due diligence of the due diligence process of the Cloud providers in the level immediately below it. In essence, the Cloud User would want to see a “Chain of Due Diligence.” This requires that the providers on each level of the chain think ahead and anticipate the needs of the Cloud provider or Cloud User in the layer immediately above it.
Another example to illustrate the point involves incident response contract terms. What happens when the Cloud transaction involves multiple layers and the lower layer suffers a data security breach exposing the PII of the Cloud User’s data? What happens when the Cloud User needs to implement a litigation hold to preserve data where the data resides in the lowest layer of the Cloud?
In a typical direct outsourcing relationship, the outsourcer and its client would build processes in to address these issues and the contract would provide for particular rights and remedies. While similar contractual rights and obligations may be built into a Cloud transaction, it is not clear how useful they would be when multiple layers are involved. For example, if a SaaS built on a Cloud Platform has itself failed to obtain certain rights and abilities to forensically analyze and preserve data processed in the Cloud Platform, the Cloud User may not be able to adequately build defenses in a security breach context or implement an effective litigation hold (regardless of what the contract between the SaaS and Cloud User provides).
A final example: data retention and destruction policies. What if the SaaS provider is working on a Cloud Platform that creates residual copies of data that the Cloud User has a legal obligation to delete? What if the SaaS provider works with a Cloud Platform that does not have the technology or capability to properly wipe data? Even if the Cloud Platform has these capabilities, what if the SaaS provider has not negotiated for the right to obtain these services? Again, to make this work it is incumbent on the SaaS provider to anticipate the end Cloud User’s needs and to only work with Cloud Platforms (or other Cloud providers) that have the capability (and willingness) to meet those needs.
Conclusion
We are very much at the start of the Cloud computing phenomenon, and luckily we have an opportunity to proactive identify and attack these issues now. However, it appears that Cloud is gaining significant momentum and time is running short to address these matters. While the ultimate “solutions” will take time to develop, legal counsel (and the legal community as a whole) should begin developing strategies and approaches for handling Cloud transactions.
A key factor (and crucial first step) in addressing Cloud legal risk for a particular transaction is understanding the relationships of the Cloud. Legal counsel (with a huge assist from IT and security) should consider taking steps to achieve this understanding and limit risk, including without limitation:
- Insist on and acheive transparency. Don’t allow the Cloud to be a black-box storm cloud. Identify the Cloud players involved in a transaction, identify where they process the Cloud User’s data, map the data flow between Cloud players and determine whether the Cloud players are static or dynamic (e.g. can/will the Cloud players change in the middle of the contract). Do this early so the organization does not need to play catch-up.
- Develop due diligence strategies and procedures, and follow and document them. Primary Cloud relationships should be directly scrutinized. Moreover, the due diligence processes of Cloud providers relying on lower layer Cloud providers should be analyzed to determine if they are adequate. Any validations (e.g compliance with standards such as ISO 270001 or SAS 70s II) or relevant reports from the various players should be obtained. The capabilities, limitations and processes of lower layer Cloud providers should be explored to ensure that they can satisfy the Cloud User’s legal obligations and do not pose additional, unanticipated legal risk or obligations.
- Confirm that Cloud providers have contractual rights to do what you need them to do. Contractually requiring an Cloud aggregator or SaaS provider to retain data, or obtaining the right to audit the security protecting the Cloud User’s data, is meaningless if the aggregator or SaaS itself does not have such rights with respect to lower layer Cloud providers. Cloud Users do not want to find this out when they have a need to exercise their contract rights (e.g. when a regulatory action, privacy breach of lawsuit happens). As such, it is important to analyze the contracts a higher level Cloud provider has with the Cloud providers it relies on to make sure the necessary rights flow through the contract chain.
- Think Way Ahead – Contractual Requirements Should be Part of the Request for Proposal Phase. Obviously performing a proper due diligence can be very time consuming, especially when multiple layers of Cloud providers are involved. It is much more difficult to achieve due diligence when the Cloud transaction has moved forward significantly (e.g. the competitors have been told they are no longer being considered and negotiations on key terms, like price, have occurred). The time to address these issues is in the RFP process. Organizations should plan ahead and identify the criteria necessary for the company and have Cloud providers confirm that they meet the criteria in their response to a RFP. At this point in time, I recommend that RFPs actually identify legal contract terms (e.g. indemnification, exceptions to limits of liability and consequential damage disclaimers) that Cloud vendors must agree to in order to get the business. Not only does this save time, but it also creates a competitive incentive for Cloud providers to take on more risk (so that they can win the business).
Legal Implications of Cloud Computing -- Part One (the Basics and Framing the Issues)
I had the pleasure of hearing an excellent presentation by Tanya Forsheit on the legal issues arising out of cloud computing during the ABA Information Security Committee's recent meeting (at the end of July) in Chicago. The presentation resulted in a spirited debate between several attorneys in the crowd. The conversation spilled over into happy hour and became even more interesting. The end result: my previous misunderstanding of cloud computing as "just outsourcing" was corrected, and now I have a better appreciation of what "the cloud" is and the legal issues cloud computing raises.
Bottom line: this is not your father's outsourcing relationship, and trying to protect clients with contracts may be very difficult or impossible unless the cloud computing community begins to build standards and processes to create trust. This post is not for my tech/security friends, it is for the attorneys out there, especially the general counsel and transactional attorneys who draft terms for tech contracts (e.g. outsourcing contracts, ASP contracts, software licenses, etc.). So tech friends, please cut me some slack as I completely mangle proper terminology in order to try to explain this in plain English (and of course if I get something wrong, shoot me a comment or email so I can correct -- we attorneys need you on this one).
One final note to the attorneys out there: there is going to be incredible financial pressure on organizations to take advantage of the pricing and efficiency of cloud computing and if attorneys fail to understand the issues ahead of time there is a serious risk of getting "bulldozed" into cloud computing arrangements without time or resources to address some serious legal issues that are implicated.
(P.S. Special thanks to Tanya Forsheit, John Tomaszewski, Karen Worstell and Peter McLaughlin for the insight and debate).
What is Cloud Computing?
How about a picture to start off:
The National Institute of Standards and Technology (NIST) has provided a definition of cloud computing that is helpful, but not really in plain English. Moreover, it does not really help to illuminate the legal aspects of cloud computing. So here is my attempt.
From a user's perspective, when utilizing cloud computing, rather than data processing and storage occurring on an individual's laptop or desktop computer (or a company's internal network), it happens on computing platforms run by third parties (such as Google, Yahoo, Amazon, etc). Services that may be available through those cloud platforms include data storage (e.g., infrastructure as a service (IaaS)), application development/deployment (platform as a service (PaaS) and software hosting (e.g., software as a service (SaaS)). So rather than store data on an organization's own computer network, if purchasing IaaS, the data is stored on servers "in the cloud" and available on demand by the organization. Rather than installing and maintaining data/software on a network or desktop computer, the data/application is hosted on computers in the cloud and available on demand.
This can result in cost savings because companies using cloud services need not purchase their own infrastructure or software, need not hire people to maintain it, and need not regularly upgrade when necessary. In addition, cloud computing is highly and cheaply scalable. So rather than maintaining an over-capacity of computing power (e.g. extra servers only used for the holiday e-commerce rush) companies can maintain variable capacity levels to suit their immediate needs using the cloud. Moreover, utilizing the cloud will allow companies to take advantage of the best and latest technology since they will not have to disassemble and rebuild their entire IT infrastructure in order to upgrade. For more information on some of the technical aspects of cloud computing, please check out this white paper put out by Sun Microsystems.
That is all nice, and fairly understandable, but what IS the cloud? Right. Some analogies are in order. Think of airlines and how they sell seats. Sometimes seats are still available for a flight as the departure date gets closer and closer. From the airline's point of view it is better to sell those seats for a lower price then to let the plane take off with empty seats. As long as can sell the seat for a price that exceeds the cost of taking a passenger. Bring this same rationale to the e-commerce context. Amazon.com has huge server farms that can handle millions of transactions. During the 3 month holiday period its servers and processing abilities may be taxed to their limits because of high online sales volumes. Then of course, February rolls around and all those servers that hummed during the holiday season suddenly lay dormant. Yet Amazon still needs to maintain them so it can be ready for the next holiday rush. What to do? Rather than let that processing capacity go unused, why not sell it to third parties? Allow an application service provider to host its application on Amazon's computers for a price. Allow an organization to store and process data on Amazon's servers. In fact, since any additional funds received (above maintenance costs) are "gravy" perhaps Amazon could charge a lower price than other companies that provide capacity. This rationale can serve as a building block for companies to get into cloud computing.
The second rationale/building block is economies of scale. Going beyond the Amazon rationale of attempting to sell excess capacity that it had to have anyway, savvy IT companies began to realize that they could sell processing capacity as a business. In fact, computing processing prices have continued to drop more or less as predicted by Gordon Bell's corollary to Moore's Law. Beyond that, companies like Google have begun to realize that if they build massive server farms they can bring down their per unit of price for processing power even further. Moreover, with highly evolved technologies they realized they could create additional processing efficiencies and bring down the per unit price of processing even further. Based on these economies of scale, cloud platforms realized they could provide processing capabilities much cheaper than companies that did it all "in house."
Terrific, so how is this any different than a typical outsourcing relationship? Why is this a Cloud? One of the key differences between a traditional outsourcing relationship and cloud computing is where the data resides or is processed. For example, in the traditional outsourcing situation, a company looking to offload some of its data storage would create a dedicated data center and then sell the storage capacity to its clients. The data center might be in another country, but for the most part the client knew where its data was going and where it would be stored and processed.
Enter the cloud. In a cloud environment, geography can lose all meaning. Cloud platforms may not be able to tell "where" data is at any given point in time. Data may be dispersed across and stored in multiple data centers all over the world. In fact, use of a cloud platform can result in multiple copies of data being stored in different locations. This is true even for a "private cloud" that is essentially run by a single entity. What this also means is that data in the cloud is often transferred across multiple borders, which (as discussed below) can have significant legal implications.
It gets more complicated when you begin talking about the "public cloud" or "hybrid cloud" and interactions between cloud providers. In some public cloud set ups, the players in the cloud are essentially trading processing and storage capacity. So if Google has excess capacity at a given point and time, and Amazon or Amazon's clients need more capacity than Amazon can provide, it can buy some capacity from Google. Some refer to this as "surge computing." The analogy here is electricity companies and providers. In warmer climates during peak electricity demand times, the local power company may not be able to generate enough electricity to meet increased demand, and will have to purchase it from other companies who are not at full capacity. Under the cloud arrangement, data is like electricity, essentially fungible and able to be moved instantaneously to available servers and computation resources. In fact, cloud computing providers will begin charging for the cloud the same way electricity is charged: based on units of use (in this case computing cycles). So in the cloud, while the data may have started out on an Amazon server in the European Union, when handed off to Google it may be processed in the United States, China or some other country where Google has servers (in fact countries like China and India are very keen to get into this business since they think they can provide these services for even cheaper). Moreover, the parts of the data may be copied and sent for processing to other participants in the cloud. To the Amazon user all of this movement of data and processing across multiple borders involving multiple entities and even multiple copies of data is invisible. The Amazon user simply gets back the answer it expected when it began the processing transaction.
What are the legal issues?
Transborder Data Flow Triggering Legal Obligations in Multiple Jurisdictions. This sharing and transfer of data within the cloud, the inability for anybody to easily say where the data is or has been, is the key problem that creates legal issues. An obvious problem is transborder data flow. For example under the EU Data Protection Directive, unless they take certain steps, organizations are prohibited from transferring personal information to countries that do not provide the same level of protection with respect to personal information of EU residents (the United States is one such country). A company that does its processing in the cloud may be violating EU law if data goes to servers outside of the EU to prohibited countries. Unfortunately, contracts may not be too helpful because cloud providers will not be in any position to make any contractual promises to their clients because in many cases they cannot say which countries data will be transferred to or from. So how can companies seeking the efficiency and cost savings of the cloud utilize it if, by its very nature, it leads to potential legal compliance nightmares?
"Reasonable Security" Under the Law. Then there is the issue of "reasonable security" in the cloud computing context, and potential liability arising out of security breaches in the cloud. Generally speaking if a company outsources the handling of personal information to another company they may have some responsibility to make sure the outsourcer has some level of reasonable security to protect personal and confidential information. What happens when the could is utilized? Service providers using the cloud platform essentially rely on the security of each of the cloud participants receiving personal information. That could be name brand companies like Google who are likely to have some level of adequate security, but it could also be lesser players trying to engage in business as cheaply as possible and not implementing rigorous controls. The bottom line again is that the organization seeking to do business in the cloud has no way to even perform a due diligence of "the cloud" to ensure that adequate security is in place. Moreover, cloud companies and service providers that contract directly with such companies are not likely to make any contractual promises around security since they ultimately don't control it (or even know how good or bad it is within the cloud). Ultimately, the legal question is, what liability does a company face when there has been a security breach in the cloud that has resulted in the theft or harm of valuable or protected data?
Electronic evidence/e-discovery. Utilizing the cloud can be problematic in the litigation context. First off, when litigation ensues and a litigation hold is initiated, the organization will have to deal with a third party cloud provider in order to get at the information relevant to the litigation. It may not be easy for that provider to actually preserve the data that is needed for several reasons. For example, an organization may be using a third party software provider that itself utilizes the a cloud platform. The data subject to the litigation hold therefore may actually reside in the cloud and may not be readily accessible/preserved by the software provider. This could complicate gathering electronic evidence and responding to e-Discovery requests. Moreover, it could lead to spoliation of evidence. In addition, considering that multiple copies of data may be created, stored, recompiled, dispersed, reassembled and reused, the idea of what constitutes a "record" or a "document" for evidentiary purposes may be difficult to grapple with in the cloud.
What can lawyers do to address these issues?
Ultimately this is the big question. Can the law wrap its head around cloud computing (when frankly, the cloud computing industry itself is having difficulty defining key components of the business)? The first area to explore are contractual arrangements. Lawyers have been involved in outsourcing transactions for sometime, and have been able to address issues of relative risk between the parties. However, contracting may be much more difficult in the cloud environment because the players may not be in a position to make certain promises, and additional duties/obligations may destroy the cheap pricing model for cloud computing. In part two of this series, we dive more deeply into the legal issues around cloud computing and the necessary involvement of lawyers in this context with respect to contractual arrangements.
