Just a little bit about me, my practice, and my firm. My background is heavy technology with 2 degrees in engineering and stints at Andersen Consulting (now Accenture) and IBM. I am a certified information privacy professional and focus my practice on commercial transactions involving technology and intellectual property. Basically if you want to sell or acquire technology to further your business objectives, I am the person to help you get that done. My firm is a general practice firm with offices on both costs and internationally. We’re a pretty large firm with well over 500 lawyers and professional.
This slide supports what I was just discussing. There is quite a bit of interplay between the providers of the cloud services. Vendors provide all three types of services. Notice that infrastructure supports platform and platform supports software. Developers may be consumers of infrastructure and platform, so they can provide software. Now this isn’t the only way that they relationships work, as clearly and end user could use the infrastructure as its backup storage solution and not have any relationship at all to platform or software at all. That being said, as a consumer plugs in at higher and higher levels, its reasonable to assume that the provider of the service has utilized supportive cloud services.
Of the five characteristics presented here, note that cloud differs in some way from both outsourcing and ASP. Many have asked ‘well, isn’t cloud just outsourcing or the same thing as application service providers services.’ The answer is both yes and no. Cloud computing is a form of outsourcing, but many of the features of traditional outsourcing are different than cloud computing. And, as we mentioned earlier, application service provider services are the predecessors to software as a service. But again, there are some differences. Let’s take a look at the matrix here. Of the five characteristics presented here, note that cloud differs in some way from both outsourcing and ASP. A couple of quick definitions – outsourcing in this context is where a company takes a technology or business process and let’s a third party essentially step into the company’s shoes and deliver the services as if it were the company. Usually the company provides the software and/or hardware for the outsourcer to use and the environment is closed for each customer. Application service providers offer services that are accessed via the internet, but the hardware is housed in a set of known data centers. The environment is closed in that the ASP is running its software on its hardware. There is no sharing of technology resources. With those definitions under our belt, lets go to location of service or data. The notion of location irrelevance is a key feature of cloud computing. When one contracts for cloud services, the user has absolutely no idea where the data is, how its being processed, where its being processed. This is different from both outsourcing and ASP, where generally as a matter of contract the user knows exactly where processing occurs and where data resides. Second, the owner of the technology – with both cloud and asp, the provider owns the technology. As we just discussed with outsourcing, the company outsourcing the services owns the technology. Third, the nature of the contract – in most public cloud contracting the contract is an online agreement commonly known in legal circles as a click wrap agreement. That term is a permutation of the shrink-wrap agreement that is found in most commercially available software. The agreement is underneath the shrink-wrapped plastic. This gives the user no opportunity to review the terms of the agreement before purchasing the software and eliminates the negotiability of the terms. Similarly in the click wrap context, the user has the ability to review the terms, but has no ability to negotiate them. This is completely different than what has been traditionally seen in the outsourcing and ASP context, where the contract has been potentially highly negotiated. This lack of negotiability ties into the next item, contract risk. Not surprisingly, since the cloud provider does not give the user the right to negotiate the terms, they create a contractual relationship where all the risk sits with the user of the services. This is different with outsourcing, where the provider carries significant contract risk, and ASPs where the risk is typically shared. Finally, cloud systems are quickly scalable by design, but outsourcing – also by design – are not. That’s because the hardware and software is limited by the acquisitions of the company contracting with the outsourcer. The scale is limited by the available excess capacity. The ASP may have some ability to scale, but that scalability is based on customer-base growth, not on having on-demand capacity.
Most public cloud services are contracted for using the click wrap model as we previously discussed. This chart shows what the user loses through this contracting mechanism. The click wrap is not negotiable, provides no or very little protection for the user in the event the provider does something wrong. As a result, the risk of problems is born by the user. If the contemplated cloud services warrant an RFP being issued by the potential user, then a standard contract may result. This will most likely result in much more favorable contract terms for the user.
The United States, as you know, does not have a comprehensive data privacy regime. It’s laws are sectoral on the federal level. Also, the states have gotten into the mix with their data breach legislation. What this slide illustrates is that depending on the nature of the business information being placed in the cloud, there may be any number of laws that apply to it. The following slides discusses data breach and a bit on each of these laws. Also, what’s not here is the new Massachusetts law that requires personal information of Massachusetts residents to be encrypted on servers.
Let’s switch to some commercial considerations. We will take these items in turn. Ultimately its all about assessing and minimizing risk regarding the processing and data placed in the cloud. Each of these points all deal with risk mitigation in one form or another.
What are the big risk areas? Data integrity, service level agreements, and disaster recovery. Data integrity deals with the data remaining in the form that it was provided with no alterations of any kind other than the intended alterations caused by processing. If data is corrupt bad information results. In this case paying attention to the contractual language regarding data integrity, if any, will give you some sense of what the provider is willing to agree to. This, of course, may be very different (and far less than) what they try to do. But you can only recover under a contract if the language giving you a recovery is actually in the contract. The SLAs are another place to look to drive down risk. If the provider gives a robust SLA regarding uptime and other key metrics and provides some sort of remedy if the SLA is not met, then the user should have comfort that the provider is at least attempting to do the right thing to make sure its systems stay up and the data remains available. In an environment where the user doesn’t control its data, since the user has placed the data in someone else’s hands, knowing that the environment will have highly availability is key. A low or no SLA is a yellow flag. Whether it’s a deal breaker depends on the nature of the information potentially being placed in the cloud. For the most part, a user has to rely on the cloud provider with respect to data integrity and SLAs. However, both the user and the provider have a role in disaster recovery. While it is important to try to glean what a provider’s DR strategy is, this information may not be accessible. I would suggest that this burden should rest more with the user. Ultimately the user has the responsibility to a customer, whether that customer be internal or external. So, the user should have a workable disaster recovery strategy in case a cloud provider has a catastrophic event or has a data outage. Let’s look at Gmail. In 2009 Google has had roughly 6 email outages of various durations, various severity, and effecting different numbers of people. For those that use Gmail as their primary email provider they have had a bit of a rocky road this year. Ultimately, we have to figure out how much to trust these providers and how much to use our own DR strategies that are independent of the cloud provider.
Viability of the cloud provider. It definitely matters. Why does it matter? Because the user makes an investment in a cloud provider when it selects it. Limited interoperability between providers makes migration between providers difficult. Also, there is a bit of ambiguity surrounding what might happen to a user’s data in the event that the provider files bankruptcy, or is merged with or is acquired by another company. Let’s talk about these in turn.
A potential merger or acquisition is potentially less troublesome than a potential bankruptcy. Why, well at least in the near term business will continue as usual. The user will get little if any notice at all regarding the transaction. So the user will wake up one day and learn that company X is now company Y. There may be some rights of termination in the contracts if the user is displeased with the new company, but the user would need to have access to the contract terms to determine that. Almost assuredly, the data will go with the transaction. So the same issues regarding discomfort with the new potential owner would apply. One risk – that the new owner will change the services over time in a way that no longer satisfies the user’s objectives. The option in such a scenario is really just one – terminate the relationship.
Cutting To The Chase: Cloud From A Customers Perspective
Your Presenter <ul><li>Janine Anthony Bowen, Esq. </li></ul><ul><ul><li>Janine’s practice focuses on strategic commercial transactions involving technology and intellectual property. Such transactions include licensing and acquisition of technology, including cloud computing services; issues surrounding the protection and exploitation of Internet-based assets; privacy and information security; and technology export compliance. </li></ul></ul><ul><li>McKenna Long & Aldridge LLP </li></ul><ul><ul><li>500+ Attorneys and Public Policy advisors </li></ul></ul><ul><ul><li>A national, general practice firm focused on transactional, litigation, and government/regulatory matters </li></ul></ul><ul><ul><li>9 US-based offices, 1 international office (Brussels, Belgium) </li></ul></ul>
Agenda <ul><li>I. What is it? </li></ul><ul><li>II. Distinguishing Cloud from Outsourcing and ASPs </li></ul><ul><li>III. The Various Cloud Contracting Models </li></ul><ul><li>IV. Data Privacy and Security Considerations </li></ul><ul><li>V. Commercial and Business Considerations </li></ul><ul><li>VI. Negotiation Strategy </li></ul><ul><li>VII. Take Away Messages </li></ul>
Cloud Computing Plain English Definition <ul><li>From the Customer ’ s Perspective </li></ul><ul><ul><li>Data processing and storage, application development, and software hosting over the Internet instead of on a personal computer or over a business ’ network </li></ul></ul><ul><ul><li>Available on an ‘ on demand ’ basis </li></ul></ul><ul><ul><li>Location of information stored ‘ in the Cloud ’ is potentially unknown at any given point in time </li></ul></ul><ul><ul><li>Relatively inexpensive </li></ul></ul>
How’s it Different? <ul><li>Geography – Data in the cloud can be anywhere; multiple copies can be in multiple locations </li></ul><ul><li>The potential for brokering capacity exists, this is ‘surge computing’ </li></ul><ul><li>In current state of play cloud providers assume virtually no liability – all risk resides with the user </li></ul><ul><li>Difficult for a user to know where liability rests, even if it were properly assigned </li></ul><ul><li>The nature of the potential legal issue depends on where a user plugs into the cloud </li></ul><ul><li>Virtually complete loss of control by data owner (who holds it and where is it?) </li></ul><ul><li>Relatively inexpensive OPEX instead of CAPEX </li></ul>
Service Model Relationships Gerard Briscoe, London School of Economics and Political Science, Alexandros Marinos, Faculty of Engineering & Physical Sciences, University of Surrey, “Digital Ecosystems in the Clouds: Towards Community Cloud Computing” March 2009
Understanding the Differences: Cloud vs. Outsourcing vs. ASP Cloud Computing Outsourcing ASP Location of Service/Data unknown known known Owner of Technology provider Probably the user provider Contract non-negotiable highly negotiated negotiated Contract Risk company provider shared Scalability Yes No Maybe
Cloud Contracting Models: Online Contract vs. Standard Contract Online Contract Standard Contract Negotiable No. Yes, generally. Limits Placed on Provider ’ s Liability Yes. Very little or no liability to provider. Yes. Risk shared by provider and user. Risk in the Event of Problems Born by user. Born by party responsible.
The Law is the Law is the Law: Privacy from the Customer’s Perspective <ul><ul><li>Data Breach/State Laws </li></ul></ul><ul><ul><li>HIPAA/HITECH Act </li></ul></ul><ul><ul><li>USA PATRIOT Act </li></ul></ul><ul><ul><li>European Union Data Privacy Directive </li></ul></ul>
Data Security: A Key Consideration <ul><li>Confidentiality </li></ul><ul><ul><li>Limits on who can get what kind of information </li></ul></ul><ul><li>Possession/Control </li></ul><ul><ul><li>Loss of control of the information, regardless of whether there is a breach of confidentiality </li></ul></ul><ul><li>Integrity </li></ul><ul><ul><li>Information is correct or consistent with its intended state </li></ul></ul><ul><li>Authenticity </li></ul><ul><ul><li>Correct labeling or attribution of information </li></ul></ul><ul><li>Availability </li></ul><ul><ul><li>Timely access to information </li></ul></ul><ul><li>Utility </li></ul><ul><ul><li>Usefulness of information (e.g. loss of encryption key for encrypted data eliminates its utility or usefulness) </li></ul></ul><ul><ul><li>*Parkerian Hexad proposed by Donn B. Parker (can be found on Wikipedia) </li></ul></ul>
Commercial & Business Considerations <ul><li>Methods to Minimize Risk </li></ul><ul><li>Viability of the Cloud Provider </li></ul><ul><li>Other Factors to Consider When Selecting a Vendor </li></ul><ul><ul><li> </li></ul></ul>
Commercial & Business Considerations: Minimizing Risk <ul><li>Contractual Methods to Minimize Risk </li></ul><ul><ul><li>Data Integrity – ensuring that data at rest is not subject to corruption </li></ul></ul><ul><ul><ul><li>Look for contractual obligations or representations regarding data integrity </li></ul></ul></ul><ul><ul><ul><li>Perhaps have SOW-level detail </li></ul></ul></ul><ul><ul><li>Service Level Agreements (SLAs) – the cloud provider’s contractually agreed to level of performance </li></ul></ul><ul><ul><ul><li>What is the SLA and what happens if it is not met? Look for teeth here. </li></ul></ul></ul><ul><ul><li>Disaster Recovery requirements </li></ul></ul><ul><ul><ul><li>Learn more about the cloud provider’s DR strategy? </li></ul></ul></ul><ul><ul><ul><li>If your information is lost due to a catastrophe at the cloud provider, can you recover? </li></ul></ul></ul>
Commercial & Business Considerations: Viability of the Cloud Provider <ul><li>Viability matters. Why? A cloud user makes an investment when choosing cloud provider. For example a user: </li></ul><ul><ul><li>Integrates cloud services into existing business processes </li></ul></ul><ul><ul><li>Migrates data from its environment to a cloud environment </li></ul></ul><ul><li>Lack of standardization makes moving to a new cloud provider difficult </li></ul><ul><li>What happens to a cloud user’s data in the event of: </li></ul><ul><ul><li>Bankruptcy </li></ul></ul><ul><ul><li>M&A </li></ul></ul>
Negotiation Strategy <ul><li>Start with a considered list of what’s important AND what’s not </li></ul><ul><ul><li>If you can recover money will that make you whole? </li></ul></ul><ul><li>Recognize the business model of the cloud provider </li></ul><ul><ul><li>Set reasonable expectations about the provider’s flexibility and reasonable expectations about your own </li></ul></ul><ul><ul><li>Assess whether the provider is really a cloud provider </li></ul></ul><ul><li>Understand there is a trade off between dollars spent and contract protections desired </li></ul>
Negotiation Strategy <ul><li>Limitation of Liability </li></ul><ul><ul><li>Data Breach/Privacy </li></ul></ul><ul><ul><li>Compliance with laws </li></ul></ul><ul><li>SLAs </li></ul><ul><ul><li>What’s commercial in a non-cloud environment </li></ul></ul><ul><ul><li>Determine whether you need contractual terms or business-level comfort </li></ul></ul><ul><li>Whose Problem is it? </li></ul><ul><ul><li>Determine what is your responsibility and what’s the provider’s </li></ul></ul>
The Take-Aways <ul><li>Be thoughtful about which parts of your business are cloud-worthy. All business processes are not suitable. </li></ul><ul><li>Have a plan to deal with mistakes that will happen in the cloud (business, technology, legal). What level of risk can you tolerate? </li></ul><ul><li>Work with your key internal and external advisors to think through your cloud strategy. A cross-functional strategy is in order. </li></ul>