Developing an Information Security and Privacy Schedule for Service Provider Transactions (Part Two)
In Part One of this blog series, we looked at the proactive nature of a data security and privacy schedule ("Schedule"), and considered the compliance function of a Schedule. Part Two of this series discusses security incident response contract terms that should be considered for a Schedule. In addition, we look at more traditional "risk of loss" contract terms and how data security and privacy risks impact those terms.
Security Incident Response Planning
As mentioned above, a Customer should think of a Service Provider’s security as an extension of its own internal security. This applies not only to the controls the Service Provider maintains, but also how a Service Provider responds to a security incident. The key here is to impose obligations on the Service Provider that provide the Customer with the most control possible in responding to, and mitigating the impact of, a security incident. In addition, in the event litigation or a regulatory action is a possibility, Customers should attempt to secure rights that allow them to collect and preserve evidence relevant to their defense (or in some cases a suit against the Service Provider).
On the front end, Customer should investigate the Service Provider’s security incident response procedures. In particular, the Customer should ask:
- Does the Service Provider have controls and policies in place to detect an incident?
- Once detected is there a chain of communication that escalates the incident to appropriate personnel?
- Are there procedures for ascertaining the risk and potential impact posed by a security incident?
- What processes exist to allow for the quick remediation of a security breach?
Moreover, since a forensic analysis or security assessment will often be necessary post-breach, the Customer should investigate what information is retained by Service Provider, and the Schedule should obligate the Service Provider to retain certain information that may be relevant to a breach (e.g. logs, error reports, planning documents, security policies, etc.)
Beyond that the Customer should consider how the Service Provider and Customer will interact in the event the Service Provider suffers a security breach impacting the Customer’s information, systems or ability to conduct business. The Schedule should require the Service Provider to identify an incident response coordinator to serve as the communication point for the Customer. Communication obligations can also include a point of contact within Customer’s organization, including in some instances a security breach emergency "hotline" phone number. The Schedule may include “deadlines” for providing notice of security breaches to the Customer (e.g. “immediately” or “within twenty-four hours” of discovery, etc.). The Schedule should include a general cooperation clause, and where appropriate specific incident response procedures between the Service Provider and Customer.
In addition, the Schedule should require the Service Provider to provide reports and information concerning the security incident, including information concerning what went wrong, what information or systems were impacted, and the remediation taken and planned by the Service Provider. The Schedule should also provide the Customer with the ability to conduct its own independent forensic analysis and security assessment after a breach. Since litigation or regulatory action is possible after a breach, the Schedule should include mechanisms for initiating a litigation hold and preserving information that may be relevant in a litigation context, as well as procedures for responding to information requests by regulators or litigants.
Risk of Loss
While most of the items discussed above are rather unique to the information security and privacy realm, risk of loss provisions are common to most contracts. These terms include warranty disclaimers, consequential damages disclaimers, limitation of liability clauses and indemnification clauses. Risk of loss terms should also address information security and privacy risk.
First, it is not unusual for a security incident to yield “consequential damages” in addition to “direct damages," including loss of profits, lost customers, attorney fees, breach notice costs and other similar costs. If the overall contract contains a consequential damages disclaimer, the Customer should endeavor to get an exception for consequential damages arising out of a security incident and/or breach of the Schedule.
Second, the Customer’s damages arising out of security incident can be enormous. They can include loss of profits, expenses to defend litigation (often multiple lawsuits for large breaches), regulatory defenses, damages, fines and penalties arising out of litigation, costs to provide notice to individuals whose personal information was breached, credit monitoring expenses, call center expenses and third party forensic analysis expenses. If a limitation of liability clause is in the contract, Customers should consider whether the liability cap would be sufficient to make them whole in the event of a security breach. If not, Customers should attempt to negotiate an exception to the limitation of liability (or perhaps a different limit of liability) for loss arising out of security incidents or breaches of the Schedule.
Last, enhanced indemnification/reimbursement language should be considered. As discussed throughout, it is not unusual for litigation or a regulatory action to arise out of a security incident. In the event the a breach of the Service Provider leads to litigation a regulatory action, the Schedule should include an indemnification or reimbursement clause that pays for the defense of these actions and indemnifies Customer for all damages, fines, penalties and other costs arising out of such actions.
In addition, the Schedule should also include a duty for the Service Provider to indemnify (or pay for) certain breach notice-related expenses. To date approximately 45 states have passed breach notice laws that require companies to provide notice to individuals whose person information may have been compromised. There are many expenses that arise out of the legal requirement to provide notice, including forensic expenses, attorney fees and mailing costs. In addition, some Customers may also want to provide affected individuals with a call center and credit monitoring. Many of these expenses have a “multiplier” component that can result in enormous damages. For example, one year of credit monitoring could cost anywhere from $10 to $360 per year per individual. If credit monitoring is provided to 1 million affected individuals a low-end estimate of the cost would be about $10 million. Therefore, the Customer should attempt to include language in the Schedule that requires the Service Provider to pay for or indemnify the Customer for these costs as well. If possible, all such indemnification costs should be outside the limit of liability.
Finally, organizations should consider another method for transferring risk of loss: insurance. “Cyber” insurance is available that can cover many of the types of loss that arise out a security or privacy breach, including loss of income, remediation expenses, data restoration, attorney fees, damages, fines and penalties, forensic expenses, breach notice expenses, credit monitoring expenses and call center expenses. The Schedule should require the Service Provider to carry both errors and omissions and “cyber” risk coverage with appropriate limits of liability. The Customer should attempt to mandate that it be named as an additional insured under the Service Provider’s policy (this option, however, may not be available as it will depend on whether the insurer is willing to provide “additional insured” coverage). In addition, Customers should consider purchasing their own cyber policy to provide direct coverage. Many carriers will provide coverage to the Customer for security and privacy breaches arising from a Service Provider security incident.
Conclusion
An information security and privacy schedule that sets forth Service Provider security and privacy obligations, and Customer rights with respect to the same, is an increasingly important and necessary part of an information technology, outsourcing or cloud computing transaction. Lawyers charged with developing such terms should be aware that Schedules serve several simultaneous purposes that are specific to the compliance and liability risk associated with data security and privacy. As a final point, the Schedule is a classic example of where “hybrid” knowledge of the law and security is required. A large part of the Schedule involves “translating” legal compliance and risk issues in a manner that can be understood by security and privacy professionals (and vice versa). As such lawyers should work closely with their client’s information security and privacy teams to develop security assessment processes, draft the terms of a Schedule, and negotiate Schedule terms with Service Providers.
Developing an Information Security and Privacy Schedule for Service Provider Transactions
It is a very interesting time for information security and privacy lawyers. Information technology and the processing, storage and transmitting of sensitive and personal information is ubiquitous. At the same time (and likely as a result of this ubiquity) the legal risk and regulatory compliance environment poses increased threats and potential for significant liability. Finally, whether through cloud computing providers or traditional outsourcing of information technology functions (e.g. ASP, hosting and storage), to stay competitive and efficient, companies of all shapes and sizes are outsourcing their information technology functions to third party service providers. It is likely that adoption of these practices will increase at an increasingly faster rate.
This reality poses significant information security, privacy and legal challenges. Internal security and privacy professionals find themselves ceding control of significant decisions to third parties (“Service Providers”) concerning the implementation, maintenance, enhancement and enforcement of information security and privacy measures. Unfortunately, an organization’s legal risk and compliance obligations do not follow – in most cases they remain with the organization that chooses to outsource (the “Customer”). Of course on the Service Provider side, the main motivation is as follows: (1) secure revenue; and (2) void liability. These motivations often counter-oppose the goals of the company seeking to outsource.
These tensions play themselves out during the contract negotiations with Service Providers. It is at this juncture that the role of the Customer’s information security and privacy attorney, working closely with the Customer’s internal security and privacy professions, becomes increasingly important. To navigate these waters legal experience in the areas of data security and privacy law, contract drafting, litigation risk and negotiation tactics is crucial. However, as important, is a solid understanding of technology and substantive security and privacy matters, and how they relate to and interplay with the law. The net result is intense negotiations around the data security and privacy contract terms, which are often in the form of an information security and privacy schedule or exhibit (“InfoSec-Privacy Schedule” or “Schedule”).
In this two-part post, we explore the function and purpose of these Schedules and discuss how they might be drafted and used. Part One discusses the proactive nature of a Schedule and how it should be viewed as compliance document. Part Two details security incident response provisions that should be considered in a Schedule, and contract terms allocating risk of loss between the Customer and Service Provider.
The Multiple Functions of a Data Security and Privacy Schedule
InfoSec-Privacy Schedules serve multiple functions, some of which are for “consumption” outside of the contractual relationship. Schedules function in traditional ways by establishing the relative duties of the parties and transferring risk of loss. However, information security schedules are also “proactive” in nature in that they mandate the implementation of certain measures to prevent a security breach and comply with certain laws. In addition, Schedules serve a “compliance” function that comes into play in the event of a regulatory action or lawsuit.
Proactive Nature of an Info-Sec Privacy Schedule
InfoSec-Privacy Schedules are interesting because they require Service Providers to implement measures to (hopefully) prevent a security incident, and potential legal liability. Contrast this with a traditional non-disclosure agreement. For the most part, NDAs do not dictate how a Service Provider must protect the confidentiality of confidential information, but rather simply mandate that Service Providers not disclose or expose such information. If such exposure occurs, the Customer’s remedy is to sue the Service Provider.
In contrast, one of the overarching goals of the security schedule is to contractually increase the likelihood that the Service Provider is actively implementing measures and policies to prevent a confidentiality breach in the first instance. This outcome is advantageous for Customers: to never experience a security breach is much better than experiencing the breach and having the right to sue for breach of contract. This is especially true where a Customer’s ability to recover is limited by limitation of liability clauses, consequential damages disclaimers and the like (described more fully in Part Two of this series).
Overall, to the extent that the Service Provider essentially becomes an extension of the Customer’s internal security, the nature of these obligations makes sense. Of course, as discussed below, for both compliance and general operational risk purposes, the trick is consistency between the Customer’s internal security environment and the environments of its Service Providers.
The Infosec-Privacy Schedule as a Compliance Document
Another crucial purpose of an InfoSec-Privacy Schedule is its compliance function. When drafting a Schedule, lawyers should consider how the contract terms relate to specific requirements imposed by applicable information security and privacy laws, and reflect efforts to maintain “reasonable security.” In addition, many laws require Customers to contractually obligate Service Providers to maintain specific security and privacy measures, and the Schedule should reflect those obligations. Ultimately, lawyers negotiating these terms should ask themselves the following question:
If put before a privacy regulator in a regulatory action, or a judge or jury in a lawsuit, will the security and privacy terms in this document reflect efforts to achieve a compliant status and “reasonable security” under the law?
To address this point there are several items lawyers should consider in developing a Schedule:
- Security assessment process. Although the Schedule can serve as a useful document to support a Customer’s arguments in favor of compliance, it should typically be coupled with some sort of due security assessment or investigation. Conducting a security assessment of a Service Provider’s security measures allows the Customer to determine whether appropriate controls are in place and risk adequately mitigated. It also allows the Customer to get an idea whether specific compliance obligations can be met by the Service Provider’s systems and processing. Moreover, (as discussed below) the security assessment process can inform the Customer as to the specific requirements that should appear in the Schedule. This process should be documented so that the Customer has the ability to establish (in a regulatory or litigation context) that it properly vetted its Service Provider prior to allowing it to process, store or transmit sensitive information.
Without a due diligence process, the effectiveness of the Schedule to establish compliance will be diminished. A Schedule filled with hollow promises is not a good compliance tool. The best policy in this situation (as in many others) is to “trust, but verify” the Service Provider’s security and privacy measures.
- Reference specific information security and privacy laws. The Schedule should specifically reference those laws that the Service Provider must comply with. This can be done by using a definition for “Privacy Laws” or “Security Laws,” and indicating applicable laws within that definition. Using this approach Customers put Service Providers on notice concerning their obligations while being able to show regulators or other parties that they were specifically addressing applicable law.
- Customer’s internal control structure reflected in Service Provider’s security and privacy obligations. When outsourcing, for purposes of information security and privacy, a Customer should view their Service Provider as an extension of itself. Most Customers have gone through an extensive process of measuring their information security and privacy risk and implementing security and privacy measures to mitigate their risk to a reasonable level. The second sensitive information or systems are outsourced to a Service Provider, those internal measures no longer apply and the Customer is completely reliant on the Service Provider’s security measures.
Problems arise when the Service Provider’s measures provide less protection than the Customer's own internal controls. Allowing a Service Provider with weaker controls to handle sensitive information will be very difficult to defend in a litigation or regulatory context. As such, the Schedule should reflect a matching of risk and controls between the Customer and Service Provider, and the Service Provider’s security and privacy measures should meet or exceed those of the Customer.
- Specific controls relevant to the transaction. It may be necessary to specify specific security and privacy measures and policies that a Service Provider must have in place. For example, the Schedule might explicitly require 256-bit encryption of data at rest, or anti-virus protection. Some of these individual requirements may be dictated by specific obligations in laws, or just may be of special significance to the Customer in light of its internal infrastructure. Another approach is to tie the Service Provider’s existing security measures (assessed during the Customer’s security assessment process) to the Schedule (with requirements to update those measures, especially for long term contracts).
- Reasonable security. In addition to specific privacy and security measures, the Schedule should require an over-arching duty for the Service Provider to always maintain “reasonable security.” This duty should supersede all other security-related obligations, and reflect an ongoing obligation (as opposed to reasonable security just at the outset of the contract). As part of the general duty, the Schedule should also impose obligations to comply with industry standards. Note that industry standards may constitute reasonable security, but it is also possible that industry standards do not meet the level of reasonableness under the law. As such, the Service Provider’s reasonable security obligation should include industry standards, but not be limited to those standards.
- Assessment and enforcement rights. Things change: new vulnerabilities arise; safer security measures are developed; and Service providers can become lax or fall behind. This is especially true for long term contracts. Schedules should provide Customers with rights to conduct periodic security assessments to confirm compliance with the Schedule, regulatory compliance and whether reasonable security measures are being maintained in light of the existing risk environment. The Schedule can also require the Service Provider to give the Customer access to the Service Provider's own internal assessments or provide notice if it is in non-compliance with applicable standards or otherwise. If material non-compliance is found there should be contractual consequences, including the right to terminate the contract for cause.
These provisions serve two functions. First, just having the right to conduct an assessment can act as deterrent – Service Providers are more likely to stay compliant if they fear an assessment and contractual remedies. Second, they allow the Customer to understand the security and privacy risks they face, and whether the Service Provider is addressing these risks and achieving compliance with applicable laws. This second function is especially important for long term contracts where the risk environment is likely to change over time.
Please note that the need to address the issues above may vary depending on the nature of the transaction. Moreover, the relative bargaining power of the parties and the positions taken by the Service Provider may impact a Customer’s ability to get certain terms into a Schedule. Regardless, when drafting information security and privacy terms, thinking about how those terms might be viewed from a compliance standpoint is very important.
The Schedule serves other important functions beyond being created and used as evidence of compliance. In Part Two we address security incident response provisions and contract terms allocating risk of loss between the Customer and Service Provider.
Compliance as a Service (CaaS): The Enabler Role of Legal, Security and Privacy Professionals
Cloud computing promises incredible benefits for companies looking for inexpensive and scalable computing solutions without the need to do it all themselves (or the costs or personnel). However, as foreshadowed in the InfoLawGroup’s “Legal Implications of Cloud Computing” series (see Part One, Part Two and Part Three) data security, privacy and legal compliance issues are beginning to cause great concern. Stories like this highlight these concerns. High profile information security snafus (fairly or unfairly) have also stoked the fire: Rackspace power outage, Amazon denial of service attack, and the Sidekick Data Loss. Data leakage is maybe problematic as well based on Cloud architecture. In fact, the InfoLawGroup has encountered some companies that are taking a pass on cloud computing (“v. 1.0”) because of regulatory, privacy and security concerns. Do these compliance concerns threaten the Cloud computing model or potentially reduce the cost benefits it promises?
The answer to this question is not clear at this early stage. However, what is becoming clearer is that attorneys, privacy experts and security professionals will increasingly (hopefully) become part of the solution. On one hand, this group of professionals act as organizational gatekeepers when it comes to implementing new IT arrangements such as Cloud. To the dismay of IT managers and business interests, they may have to say “no” to certain Cloud transactions. On the other hand this group will increasingly act as enablers to Cloud vendors by helping them understand their clients’ legal, security and privacy concerns, and providing them with the ability to design their Cloud and services in a manner that addresses those concerns. This activity will take place well before the transaction phase, and its purpose is to create a Cloud that moves the gatekeepers away from “no.” This post explores the enabling role that these professionals will likely play in the coming months and years.
Understanding the End Client/Users Applicable Compliance Issues
The adoption of Cloud computing faces significant potential push-back from legal, privacy and data security stakeholders within an organization. For Cloud to be accepted by certain organizations and industry segments the Cloud solution must address legal, data security and privacy concerns. In essence, by baking compliance into the Cloud, service providers are providing “compliance as a service” (CaaS).
It is important for Cloud service providers to be proactive in this regard. Cloud providers that take the time to understand their clients’ needs ahead of time (as well as the needs of their clients’ clients or users) may gain a competitive advantage against “generic clouds.” If these Cloud providers can implement an architecture that addresses specific client needs and/or provides clients with tools or mechanisms to address these needs, they should rise to the top. Of course, price will also remain a major (the major) factor in a purchase decision. The challenge will be balance: “customizing” Clouds or building in additional features costs money, if these costs materially overwhelm the promised cost savings or functionality of the Cloud then it will not be a viable business opportunity. However, if providers don’t adequately address compliance issues, Cloud services may not be implemented in the first instance. Cloud providers must thread this needle.
A key activity for Cloud providers will be understanding the regulatory, privacy and compliance environments of their clients and end users, and providing Clouds with the infrastructure and tools to meet those needs. Lawyers, security pros and privacy vendors can help Cloud providers (and will be necessary to) achieve this. The legal, privacy and security concerns may vary depending on the industry, the specific activities of the organization, the data being processed and the regulatory environments that impact the company. While there may be commonalities and overlap between different types of organizations, the Cloud services will still have to address the differences that may exist. Ultimately, this may lead to “vertical clouds”: Cloud providers specializing in certain industry verticals that may have different needs or concerns (e.g. banking, healthcare, retail, etc). In fact, this is already beginning to happen (see. e.g. Legal Cloud, FedCloud, athenahealth, bankserv and Rackspace PCI Compliant Cloud).
Creating Transparency
Once the specific legal, security and privacy concerns of clients are understood, Cloud providers will have to go one step further and build transparency into their process to enable potential clients to efficiently perform their due diligence so they can enter into, draft and negotiate Cloud agreements. Again, this is where legal can serve in an enabling role. By understanding the end-client’s compliance issues, cloud providers can make it easier and more transparent for clients to get the information they need to have confidence that their concerns have been addressed by the Cloud provider. Vendor lawyers helping with the design of the Cloud will have to anticipate where transparency is needed, how to most efficiently achieve that transparency, and what information to disclose to clients to smooth through the due diligence and contract negotiation process. Examples of areas where more transparency will likely be needed include:
- Relationships in the Cloud (Who is processing, transmitting and storing the Cloud purchaser’s information?)
- Security policies, procedures and controls (What controls are in place in the Cloud? What security standards [e.g. ISO 27001] have Cloud providers met? Do the controls meet the standard of reasonable security for the purchaser of Cloud services? Are the Cloud provider’s controls consistent with and compatible with the Cloud client's internal security framework? )
- Information handling practices and privacy (What can the Cloud provider do with personal information? What does it plan to do with personal information? Are the Cloud provider’s practices consistent with applicable privacy laws and the Cloud purchaser’s own privacy policy?)
- Geography (Where is the data being stored and processed? What jurisdiction’s laws may be triggered based on the location and cross-border transfer of personal information? Will export restrictions be violated? Will governmental bodies be able to obtain information that flows through their country?)
- Incident response, data preservation and electronic discovery (What procedures are in place to respond to an incident suffered by the Cloud provider? What obligations does the Cloud provider have when it suffers an incident? What information will the Cloud provider provide to the purchaser concerning a security incident? How will a Cloud provider coordinate with a Cloud purchaser in the event of an incident? How will a litigation hold be initiated with respect to data stored or processed by a Cloud provider? How can data be preserved when on the Cloud provider’s systems? What measures are in place to establish the integrity and authenticity of a “document” stored in the Cloud?)
- Service level agreements (Can the Cloud vendor meet SLAs that are appropriate to its clients’ needs? Is the Cloud provider using third party Cloud provider to provide services, and has the former secured contractual rights consistent with the applicable SLA?)
Standards in the Cloud
Going forward, especially where multiple tiers of Cloud providers are involved and/or data is being transferred between multiple Clouds, “universal” standards may develop that could create more transparency. Rather than an ad hoc approach requiring potential Cloud clients to individually investigate compliance aspects of each Cloud provider, it is possible that generally accepted privacy and security standards may develop. Similar to the PCI approach, Cloud providers would certify their compliance with such standards and provide Cloud clients with proof of certification. This could provide more transparency and make the due diligence process more efficient. Moreover, it provides a benefit to Cloud providers: they can certify to the standards once and simply provide proof rather than having each of their clients perform a separate due diligence procedure or assessment for every transaction.
Conclusion
The opportunity for lawyers, security professionals and privacy experts to play a positive role in enabling Cloud offerings is very exciting. Rather than playing their traditional spoiler roles, assuming Cloud providers think proactively, these professions can actually help the Cloud model mature. Moreover, in some cases, early adopters creating customized Clouds that provide “CaaS” may actually achieve a competitive advantage. The end result of CaaS, if done properly, are cost-effective Cloud services that provide all the benefits that have been touted, while reducing legal, privacy and security risk to an acceptable level.
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.
