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).