If It's in the Cloud, Get It on Paper: Cloud Computing Contract Issues

Key Takeaways

Ensure that your contract with a cloud service provider:

• Codifies the specific parameters and minimum levels required for each element of the service, as well as remedies for failure to meet those requirements.
• Affirms your institution's ownership of its data stored on the service provider's system, and specifies your rights to get it back.
• Details the system infrastructure and security standards to be maintained by the service provider, along with your rights to audit their compliance.
• Specifies your rights and cost to continue and discontinue using the service.

source: http://www.flickr.com/photos/lisanolan/502590059

Much recent discussion has focused on the pros and cons of cloud computing. Some institutions are attracted to cloud computing benefits such as rapid deployment, flexible scalability, and low initial start-up cost, while others are concerned about cloud computing risks such as those related to data location, level of service, and security infrastructure. For institutions that have done due diligence and determined that the benefits of cloud computing outweigh the risks, this article serves as a resource to help mitigate those risks through the contract terms with a cloud services provider.

Contract Negotiation and Management Skills Needed

"The Evolution of the CIO" notes that the need for CIOs to "negotiate, contract, and work with suppliers has grown significantly and will increase further as institutions move to above-campus sourcing."¹ This is the case with cloud computing. Most transitions to a cloud computing solution entail a change from a technically managed solution ("I build it, I maintain it") to a contractually managed solution ("Someone else is doing this for me; how do I ensure they're doing what they're supposed to?"). This change necessitates increased IT contract negotiation skills to establish the terms of the relationship ("What do I get?") and vendor management skills to maintain the relationship ("How do I ensure that I get it?").

A cloud computing provider's standard contract is typically written to favor that company. Gartner recommends that an institution considering cloud computing "understand the detailed terms and conditions ... and the risks of signing the service provider's standard contract" before moving to a cloud computing solution.² I would take that a step further and suggest that you work with the service provider to negotiate any revisions necessary to ensure that the terms of the contract effectively address your institution's needs. (Note that special factors influence negotiating contracts for "free" cloud computing services.) Examples of standard contracts for prominent cloud computing vendors include Amazon Web Services, Google Apps for Education, Microsoft Windows Azure, and Salesforce.com.

In early 2009, UCLA identified the need to establish its first enterprise-wide software as a service (SaaS) contract, for virtual classroom/meeting services. Since UCLA did not have a designated cloud computing contract expert at that time, responsibility for these efforts and negotiating the SaaS contract fell upon me in my role as director of UCLA Software Licensing. To ensure that our needs and concerns relative to the unique challenges of adopting a cloud computing solution were addressed effectively, I conducted extensive research into best practices in this area. After completion of that contract, I've continued to seek examples of successfully negotiated cloud computing contract revisions to facilitate effective negotiations for subsequent cloud computing contracts at UCLA. I've summarized the results of my ongoing research here in the hope that others will find the information useful.

This article is intended to highlight some key contract issues that are either unique to cloud computing or essential to its effective adoption. Most of these issues don't have simple right or wrong answers, but must be evaluated based on your institution's needs and tolerance for risk. Examples of actual contract clauses in this article suggest ways of contractually addressing these issues. Some are from UCLA's SaaS contract, while others are ones I wish I had seen before finalizing that contract.

While there are multiple variations of cloud computing — software as a service (SaaS), infrastructure as a service (IaaS), platform as a service (PaaS) — the contract issues associated with each are similar and typically fall within one of four categories:

• Service level agreements
• Data processing and storage
• Infrastructure/security
• Vendor relationship

Service Level Agreements

While differing definitions of cloud computing exist (Burton Group, NIST, Forrester, etc.), I'm using the Gartner definition here: "a style of computing in which scalable and elastic IT-enabled capabilities are provided as a service to consumers using Internet technologies."³ A key word here is 'service.'

Since much of the relationship between an institution and a cloud computing provider will be contractually governed, it is important for the contract to include service level agreements (SLAs) stating specific parameters and minimum levels for each element of the service provided. The SLAs must be enforceable and state specific remedies that apply when they are not met. Aspects of cloud computing services where SLAs may be pertinent include:

• Uptime
• Performance and response time
• Error correction time
• Infrastructure/security

Exhibit A (page 83) of the City of Los Angeles' Google Apps contract provides a good example of a cloud computing SLA.

SLA Parameters

Per Jordan Wiens in InformationWeek, "...outages can and do happen. The question isn't if the system will go down, but how often and for how long."⁴ Exhibit A focuses on system availability:

Google Apps SLA. During the Term of the applicable Google Apps Agreement, the Google Apps Covered Services web interface will be operational and available to Customer at least 99.9% of the time in any calendar month (the "Google Apps SLA").

It is important to consider an SLA in relation to your institution's specific needs. In this example, system unavailability would seem to be no more than .72 hours a month ((30*24)*.001). When looking at an uptime SLA like this, however, realize that the ability to use cloud computing services depends on Internet availability, which is not within the service provider's control. Internet downtime could further reduce access to a cloud service.

SLA Definitions

The specific definitions of pertinent SLA terms are important as well. Exhibit A includes the following definitions:

"Downtime" means, for a domain, if there is more than a five percent user error rate. Downtime is measured based on server side error rate.

"Downtime Period" means, for a domain, a period of ten consecutive minutes of Downtime. Intermittent Downtime for a period of less than ten minutes will not be counted towards any Downtime Periods.

"Monthly Uptime Percentage" means total number of minutes in a calendar month minus the number of minutes of Downtime suffered from all Downtime Periods in a calendar month, divided by the total number of minutes in a calendar month.

"Scheduled Downtime" means those times where Google notified Customer of periods of Downtime at least five days prior to the commencement of such Downtime. There will be no more than twelve hours of Scheduled Downtime per calendar year. Scheduled Downtime is not considered Downtime for purposes of this Google Apps SLA, and will not be counted towards any Downtime Periods.

Such definitions can provide a fairly narrow way of calculating uptime. Note also that standard contract language will typically exclude from uptime calculations any downtime for maintenance that is scheduled or announced in advance. Consider how any defined or scheduled downtime aligns with the times your institution has critical access needs. If contractually allowable downtime conflicts with your critical month-end processing, for example, you could face significant problems.

An institution should take all of these factors into account when determining whether or not the collectively calculated amount of uptime will be sufficient. The InformationWeek Analytics report "The Public Cloud: Infrastructure as a Service" provides a helpful summary of the standard uptime SLAs for some cloud computing providers.⁵

SLA Remedies

SLAs must be enforceable, and they should state specific remedies, such as corrections or penalties, for when they are not met. Corrections codify the actions the service provider must take to prevent a future failure to meet an SLA. Penalties often take the form of a financial credit, as in Exhibit A:

If Google does not meet the Google Apps SLA, and if Customer meets its obligations under this Google Apps SLA, Customer will be eligible to receive the Service Credits described below...

Exhibit A then specifies the number of days of service credit to be provided at various percentages of monthly uptime, followed by:

Service Credit shall be applied as liquidated damages against the following year of service cost. If service is discontinued for any reason, the Service Credit shall be in the form of a rebate at the end of service.

Service Credits shall be computed by dividing the number of Days of Service credited by the number 365 and multiplied by the Annual Service Fee.

Customer Must Request Service Credit. In order to receive any of the Service Credits described above, Customer must notify Reseller or Google, or Customer's Reseller must notify Google, within thirty days from the time Customer becomes eligible to receive a Service Credit. Failure to comply with this requirement will forfeit Customer's right to receive a Service Credit.

It is important to codify when and how a credit will be provided. In this example, if service continues, then the credit will be realized as a cost reduction the following year, but only if the customer provides the required notice. The credit computation is similar to what we used for UCLA's SaaS agreement and is fairly standard.

Gartner advises that, unless a financial penalty is in the 10-20 percent range, it might not get a vendor's attention.⁶ That said, the goal of including such penalties is not to get credits but to motivate the vendor to provide the required level of service. Other ways of contractually motivating appropriate performance include reputational penalties, such as a requirement to publicly announce missed service levels, and rewards for exceeding service levels. An institution must conduct its own assessment to determine the level and type of remedy sufficient to offset potential damages.

To assist with tracking and enforcement of SLAs, a contract should include the institution's right to audit performance records and access daily service quality statistics. Currently available examples of the latter include those provided by:

• Salesforce.com
• Microsoft
• Google
• Amazon

In addition, it might be possible to leverage third-party cloud performance management providers such as Cloudkick, which monitors cloud servers, or Apparent Networks, which provides a Cloud Provider Scorecard.

Data Processing and Storage

source: http://www.flickr.com/photos/ian-s/2152798588/

Cloud computing entails a paradigm shift from in-house processing and storage of data to a model where data travels over the Internet to and from one or more externally located and managed data centers. This shift raises significant issues regarding:

• Ownership of data
• Disposition of data
• Data breaches
• Location of data
• Legal/government requests for access to data

Ownership of Data

Since an institution's data will reside on a cloud computing company's infrastructure, it is important that the contract clearly affirm the institution's ownership of that data. The well-established cloud computing companies are beginning to include language along these lines in their standard contracts. For example, section 10.2 of the Amazon Web Services contract states:

10.2. Your Applications, Data and Content. Other than the rights and interests expressly set forth in this Agreement, and excluding Amazon Properties and works derived from Amazon Properties, you reserve all right, title and interest (including all intellectual property and proprietary rights) in and to Your Content.

Depending on the nature of your data and how it is processed, you might need to negotiate language to affirm your institution's ownership of the results of any processing of its data that occurs on the cloud computing provider's system.

Disposition of Data

To avoid vendor lock-in, it is important for an institution to know in advance how it will switch to a different solution once the relationship with the existing cloud computing service provider ends. To help facilitate such a transition, the contract should state the institution's rights to access its data on an ongoing basis. The following example is from the UCLA SaaS contract:

University retains the right to use the Services to access and retrieve University Content stored on Vendor's Services infrastructure at its sole discretion.

When negotiating your institution's contract, you should also consider whether emergency situations might require immediate access to your data. If so, codify procedures and timelines for time-sensitive access that meet your needs.

It is important to elaborate on the process by which the data will be returned to or retrieved by the institution upon termination of the contract. The Internet2 Wiki Information Security Guide includes the following sample contract clause (clause 8):

Upon request by Customer made before or within sixty (60) days after the effective date of termination, [Vendor] will make available to Customer for a complete and secure (i.e. encrypted and appropriate[ly] authenticated) download file of Customer Data in XML format including all schema and transformation definitions and/or delimited text files with documented, detailed schema definitions along with attachments in their native format.

This clause covers the timeframe within which the vendor needs to provide access to the institution's data, as well as the process and the format for the data. An institution should identify the appropriate data format depending on what they plan to do with the data (move it back in-house, port it to a different service, etc.). Data provided in a proprietary or otherwise inaccessible format would be of little or no use when moving to an alternative solution.

Additionally, as shown in the European Commission's "Standard Contractual Clauses (processors)" (Annex, Clause 12) example, the contract should obligate the vendor to destroy the institution's data after termination of the contract:

1. The parties agree that on the termination of the provision of data processing services, the data importer and the subprocessor shall, at the choice of the data exporter, return all the personal data transferred and the copies thereof to the data exporter or shall destroy all the personal data and certify to the data exporter that it has done so, unless legislation imposed upon the data importer prevents it from returning or destroying all or part of the personal data transferred. In that case, the data importer warrants that it will guarantee the confidentiality of the personal data transferred and will not actively process the personal data transferred anymore.
2. The data importer and the subprocessor warrant that upon request of the data exporter and/or of the supervisory authority, it will submit its data processing facilities for an audit of the measures referred to in paragraph 1.

Paragraph 2 provides the institution's right to conduct an audit to confirm that their data has been destroyed appropriately.

Data Breaches

source: http://www.flickr.com/photos/nostalgicglass/1188551383/

The contract should cover the cloud service provider's obligations in the event that the institution's data is accessed inappropriately. The repercussions of such a data breach vary according to the type of data, so know what type of data you'll be storing in the cloud before negotiating this clause. Examples of higher risk data include FERPA, HIPAA, or other personally identifiable information. While not specifically written for cloud computing, Article 6 of the existing University of California "Appendix — DS" serves as a helpful illustration of contractual language regarding vendor security breach obligations:

Contractor shall report, either orally or in writing, to University any use or disclosure of Covered Data not authorized by this Agreement or in writing by University, including any reasonable belief that an unauthorized individual has accessed Covered Data. Contractor shall make the report to University immediately upon discovery of the unauthorized disclosure, but in no event more than two (2) business days after Contractor reasonably believes there has been such unauthorized use or disclosure. Contractor's report shall identify: (i) the nature of the unauthorized use or disclosure, (ii) the University Covered Data used or disclosed, (iii) who made the unauthorized use or received the unauthorized disclosure, (iv) what Contractor has done or shall do to mitigate any deleterious effect of the unauthorized use or disclosure, and (v) what corrective action Contractor has taken or shall take to prevent future similar unauthorized use or disclosure. Contractor shall provide such other information, including a written report, as reasonably requested by University.

This example covers key vendor data breach obligations, including the requirement to notify, notification timeframe, and provision of pertinent breach details. Additionally, it outlines vendor obligations to describe the circumstances surrounding the breach, corrective actions, and prevention plans.

Of equal importance to the breach notification process, the service provider should be contractually obligated to provide indemnification should the institution's data be accessed inappropriately. The University of Minnesota's Google Apps for Education contract provides a good example:

6.5 Personally Identifiable Information. Each party acknowledges that, in the course of performance hereunder, they may receive personally identifiable information that may be restricted from disclosure under the Health Insurance Portability and Accountability Act (HIPAA) and/or the Family Educational Rights and Privacy Act (FERPA). Notwithstanding any other provision of this Agreement, each party will be responsible for all damages, fines and corrective action arising from disclosure of such information caused by such party's breach of its data security or confidentiality provisions hereunder.

This example focuses on two data categories of particular concern to higher education institutions, HIPAA and FERPA. For any cloud computing service provider that handles your institution's HIPAA information, you will want to investigate entering into a business associate contract with that vendor. For any cloud computing service provider that handles your institution's FERPA information, you should consider contractually identifying the vendor as a "school official" to ensure their compliance with associated FERPA obligations. Additional FERPA contract clause samples can be found at the Internet2 Wiki Information Security Guide.

In this example, if a breach occurs due to the vendor's errors or omissions, they are "responsible for all damage, fines," etc. This is important due to the high financial and reputational costs resulting from such a breach. Similar liability limitations language is now incorporated in section 13.3 of the standard Google Apps for Education contract.

Location of Data

A variety of legal issues can arise if an institution's data resides in a cloud computing provider's data center in another country. Different countries, and in some cases even different states, have different laws pertaining to data. One of the key questions with cloud computing is, which law applies to my institution's data, the law where I'm located, or the law where my data's located? Additionally, there are questions about export control: Does saving controlled data on a cloud computing service with a data center located outside the United States constitute a violation of export control laws?⁷ For these reasons, it can be important for the contract to identify the geographic region within which the data center hosting your institution's data may be located.

The U.S. federal government is making headway with cloud computing companies in this arena. In fall 2009, Google announced plans to establish a Google cloud for government customers in the United States. And in February 2010 Microsoft announced a series of cloud enhancements and certifications designed to meet the needs of government agencies. Higher education institutions should be able to leverage these efforts just as local governments do. Appendix J, 1.7, of the City of Los Angeles' Google Apps contract provides a good example of data location language that piggybacks on these efforts:

1.7 Data Transfer. Google agrees to store and process Customer's email and Google Message Discovery (GMD) data only in the continental United States. As soon as it shall become commercially feasible, Google shall store and process all other Customer Data, from any other Google Apps applications, only in the continental United States...

While "commercially feasible" is a loosely defined term, this is the best example I've found of an existing contract clause on data location.

Legal/Government Requests for Access to Data

The contract should specify the cloud provider's obligations to an institution should any of the institution's data become the subject of a subpoena or other legal or governmental request for access. The following data disclosure language is from the UCLA SaaS contract:

Where a Receiving Party is required to disclose the Confidential Information of the Disclosing Party pursuant to the order of a court or administrative body of competent jurisdiction or a government agency, the Receiving Party shall: (i) if practicable and permitted by law, notify the Disclosing Party prior to such disclosure, and as soon as possible after such order; (ii) cooperate with the Disclosing Party (at the Disclosing Party's costs and expense) in the event that the Disclosing Party elects to legally contest, request confidential treatment, or otherwise attempt to avoid or limit such disclosure; and (iii) limit such disclosure to the extent legally permissible.

The goal is to make the service provider responsible for notifying the institution as soon as they receive any such request, ideally before they provide access to any of the institution's data, and to cooperate with the institution's efforts to manage the release of such data. In this example, the definition of Confidential Information includes the institution's data stored on the vendor's infrastructure.

Infrastructure/Security

The virtual nature of cloud computing makes it easy to forget that the service is dependent upon a physical data center. All cloud computing vendors are not created equal; there are both new and established vendors in this market space. This section will cover some contractual ways to help you ensure that you don't get this...

If you watched the YouTube video to at least the three- or four-minute mark you'll get a good laugh (trust me on this), but if this were the data center of a cloud computing vendor hosting your data, you might not find it funny.

To ensure that you don't get this kind of service, you should verify the specific infrastructure and security obligations and practices (business continuity, encryption, firewalls, physical security, etc.) that a vendor claims to have in place and codify them in the contract.

Data Center Audits/Certifications

The Cloud Security Alliance's Security Guidance report advises, "A right to audit contract clause should be obtained whenever possible..." This clause should state requirements for third-party audits and/or certifications and that any reports related to such certification processes or other vulnerability assessments or penetration tests be provided to your institution. The U.S. General Services Administration (GSA) has developed a cloud computing contract Amendment, section V of which includes the wording:

...An SAS 70 Type II audit certification will be conducted annually, and Company agrees to provide Agency with the current SAS 70 Type II audit certification upon the Agency's request...

While there is no common standard for cloud computing certifications, SAS 70, issued by the American Institute of Certified Public Accountants (AICPA), is the most commonly used. An SAS 70 Type II report is generally preferable for cloud computing situations. (Find explanations of the two types of certification on the SAS 70 website.) The GSA example also requires that the results of the certification be provided.

Other currently used cloud computing certifications include:

• Systrust issued by the AICPA
• ISO 27001 issued by the International Standards Organization
• Certification under the Federal Information Security Management Act (FISMA)⁸

To address the current lack of standards in this area, the Cloud Security Alliance recently proposed the Trusted Cloud Initiative with the goal of developing industry-recommended infrastructure and security configurations and practices.⁹

Data Center Inspections

Certifications are not sufficient by themselves. Best practice would be for the contract to include your rights to confirm the vendor's infrastructure and security practices via an onsite inspection at least once a year. The Internet2 Wiki Information Security Guide includes the following sample contract clause:

[Vendor] agrees to have an independent third party (e.g. Cap Gemini, Ernst & Young, Deloitte & Touche, or other industry recognized firms) security audit performed at least once a year. The audit results and [Vendor]'s plan for addressing or resolving of the audit results shall be shared with the Institution within XX (X) days of the [Vendor]'s receipt of the audit results. The audit should minimally check for buffer overflows, open ports, unnecessary services, lack of user input filtering, cross site scripting vulnerabilities, SQL injection vulnerabilities, and any other well-known (published on bugtraq or similar mailing list) vulnerabilities.

While such an inspection could be conducted by an institution's IT security experts, this sample specifically discusses third-party auditors, which can be helpful if you don't have appropriately trained staff. This example covers pertinent specifics such as frequency of audits, minimum audit check requirements, and sharing of the results with the institution. Northwestern University has developed standard "Contract Language for the Secure Handling of NU Data" that provides additional useful sample language regarding security infrastructure.

If you don't have the resources to conduct such audits, a second-best practice would be to obtain the cloud provider's infrastructure and security specifications in writing, have in-house data center experts review and confirm that those meet your needs, then append the specs to your contract as the minimum infrastructure and security requirements. This is the approach UCLA took with its SaaS agreement due to limited resources and budget.

A vendor may push back on audit requirements, citing costs related to hosting audits. One way to mitigate this concern would be to include a contractual cap on the labor costs associated with audits. A cloud computing provider with solid data center infrastructure and security should have no problem agreeing to certification and audit clauses. Doing so is a sign of the company's confidence in their system. Failure to do so could signal that their infrastructure and security do not meet your needs.

Disaster Recovery/Business Continuity

The cloud computing company's ability to provide service could be interrupted by disasters or other unforeseen events. To protect your institution, the contract should state the provider's minimum disaster recovery and business continuity mechanisms, processes, and responsibilities to provide the ongoing level of uninterrupted service required.

Furthermore, the contract should specify the service provider's obligations should any of the institution's data become lost or damaged due to the vendor's errors or omissions. This section should detail the notification process, how the vendor will correct the underlying problem and continue to provide the service, and the vendor's obligation to reimburse the institution's costs related to lost or damaged data.

Vendor Relationship

While some of the issues covered in this section are not unique to cloud computing, they are essential to its effective adoption. For example, both traditional software licenses and cloud computing services involve ongoing rights, necessitating effective management of the relationship throughout the product's useful life cycle. Cloud computing contract terms that clearly define each party's rights and responsibilities will facilitate a more effective relationship between the institution and the service provider.

The cost to change to a different solution will typically be the largest cost associated with the use of a cloud computing service. An institution's leverage is typically strongest prior to signing the initial contract and making the initial payment, so it is important to codify in advance the terms under which the institution can continue using the service as well as those under which it can change or terminate the service.

Price Caps

Vendors typically attempt to get an institution to focus on the initial buy-in costs. To protect your future interests, it is essential to ensure that the contract also specifies your cost to continue using the service after the initial purchase period and volume. Contractual language along the following lines can help:

University shall pay Vendor annual renewal fees (on the annual anniversaries of the Effective Date) based upon Vendor's rates for renewal term; provided that Vendor may not increase the renewal fees more than three percent (3%) or CPI-U, Not Seasonally Adjusted, U.S. City Average, All Items, Base Period 1982-84=100, whichever is less, from one annual term to another; and provided further that the renewal fees shall, at all times, be at the lowest rate charged for the same services to any of Vendor's other customers.¹⁰

In this example it is important to note that the price cap is the lesser of a specific Consumer Price Index (CPI), a set percentage, or what the vendor charges others. An institution should negotiate to have these prices effective for as long a period as possible.

Before signing a contract, negotiate costs for any expansion of your initial volume or usage so that it is equal to or less than the cost per unit of your initial purchase. The exercise of these rights should be at your institution's option. One of the much touted benefits of cloud computing is scalability — "only use what you need" — so endeavor to ensure that the contract doesn't tie you to minimum purchase volumes or multiyear commitments. Your price per unit should not increase if your volume decreases.

Functionality

One clause often overlooked is a description of the functionality of the services being acquired; many contracts simply state a product's name without saying what it does. The constantly evolving nature of cloud computing services means that a cloud service provider could update their underlying infrastructure at any time. Such updates could result in functionality being added — or deleted — at any time.

A deleted functionality could be one that you depend on, so a cloud computing contract should include a clause requiring the vendor to provide notice prior to discontinuing a feature or functionality of its service. The notification period should be in line with the time that it would take your institution to move to another solution, ideally 18 to 36 months. Without such a clause, a vendor could effectively force you to shift to a replacement service at a potentially higher cost than under your original contract.

Termination

Of equal importance to detailing the terms under which you can continue to use the service are the terms under which you can terminate it. Section T of the GSA cloud computing contract Amendment provides a simple, straightforward example:

Agency may close Agency's account and terminate this agreement at any time.

You may want to negotiate for your institution to have this right, but elaborate by adding "without having to show cause and without incurring any fees or penalties." At the same time, you may want to have the vendor's rights to discontinue service be more narrowly restricted, as in the following example from the UCLA SaaS contract:

Unless otherwise required by law, Vendor may not withdraw availability of the Services during the Term of this Agreement without first providing University with ninety (90) days advance notice of same, and then only if Vendor is withdrawing availability from all of its customers.

In applying the UCLA example, you'll want to consider how much advance notice is sufficient based on your usage of the service. An institution can also negotiate to restrict vendor termination rights to triggering events, such as institutional actions that pose a significant threat to the security or integrity of the vendor's infrastructure. Be sure to include the institution's reasonable opportunity to correct any such actions prior to vendor termination. Additionally, any payments subject to a legitimate dispute should not be cause for the vendor to terminate service.

Mergers and Acquisitions

An institution should always do its due diligence (researching the stability of a vendor's finances or leadership, searching for legal issues, conducting reference checks, etc.) when considering using any cloud contracting services provider. While this can provide a solid foundation upon which to base your decision, none of us can predict the future. Cloud computing is still a growing market space made up of both new and well-established companies. The weaker among the newer companies might not have long-term viability, while the stronger ones might ultimately become targets for acquisition. In either event, your data and ongoing access to the service could be at risk, so it is important to contractually mitigate these risks. Contractual language along the following lines can help:

ASSIGNMENT. This Agreement shall be binding on the parties and their successors (through merger, acquisition or other process) and permitted assigns. Neither party may assign, delegate or otherwise transfer its obligations or rights under this Agreement to a Third Party without the prior written consent of the other party.¹¹

SaaS escrow services from vendors such as Iron Mountain and NCC Group have begun to address the concern that a cloud computing vendor will go out of business, so you might want to consider negotiating to include escrow language in your contract.

Vendor Outsourcing

It is not uncommon for one cloud computing company to use the services of a different cloud computing company to provide their service to you. For example, with the UCLA SaaS contract, the SaaS provider leverages a third-party IaaS company for their data center infrastructure. This can increase the complexity of a cloud computing contract, especially in determining which vendor is responsible for which action. To mitigate risk, the contract should obligate the vendor you're doing business with to identify any functionality that is outsourced and to whom. Additionally, no matter who your cloud provider outsources to, they should remain directly responsible for all aspects of complying with the terms of their contract with you.

Next Steps

As noted, the contractual and vendor relationship aspects of software licensing and cloud computing are similar. Once you've established a cloud computing contract, you will need to dedicate resources to monitor and manage your relationship with the service provider to ensure continued adherence to the contract terms. Existing institutional staff responsible for the acquisition of software licenses are likely skilled in contract negotiation and vendor management, so can be leveraged to advise and assist your institution as it moves forward with cloud computing solutions.

Cloud computing has a broad set of implications, however, ranging from meeting your business needs to ensuring compliance with institutional policy and the law. It's important that your software licensing experts establish an effective collaboration with your institution's:

• IT end-user unit(s)
• Legal counsel
• Policy experts
• Procurement office

The ECAR case study "Partnership of Four: Managing Alternative Sourcing at Oakland University" provides a useful description of the needs and strengths of these key units and the necessity of working together to effectively manage the wide-ranging implications and risks associated with adopting a cloud computing solution.¹² Such partnerships can help establish standard processes appropriate to the acquisition of cloud computing solutions, including developing guidelines and best practices documentation regarding the appropriate use of cloud computing services.

Additional action items for this cloud computing experts group could include developing cloud computing contract templates and sample clauses, along with investigating and implementing opportunities for institution-wide contracts with cloud computing vendors. Such institution-wide contracts could over-ride the terms of click-through agreements to provide additional protections for end users.

Conclusion

Cloud computing represents a significant shift from the way IT solutions have been implemented in the past and comes with its own unique set of challenges. It is possible to effectively address many of these challenges by leveraging, or enhancing, in-house resources skilled in contract negotiation and vendor management to contractually address the risks related to service levels, data processing and storage, infrastructure/security, and your institution's relationship with the cloud computing service provider.

UCLA selected a SaaS solution because the benefits of getting a new enterprise-wide service up and running quickly while not having to establish and maintain the supporting infrastructure outweighed the risks of adopting a cloud computing solution. Usage of the service available under this contract continues to expand, and the contract was recently renewed for a second year.

One article cannot cover all cloud computing contract issues. A good source for additional information is the National Association of College and University Attorneys (NACUA). The information in this EQ article is intended to highlight some best practices and complement, not obviate, your institution's existing legal, contractual, or purchasing policies. All contracts should be appropriately reviewed by your institution's in-house legal counsel to ensure that the language effectively represents your needs.

1. "The Evolution of the CIO: An EDUCAUSE Issues Brief," EDUCAUSE, October 2009.
2. Frank Ridder and William Maurer, "Negotiation and Contracting for Cloud-Enabled Outsourcing" (G00170695), September 9, 2009, Gartner subscription required.
3. David Mitchell Smith, David W. Cearly and Daryl C. Plummer, "Key Issues for Cloud Computing, 2010" (G00175264), March 29, 2010, Gartner subscription required.
4. Jordan Wiens, "Tech Center Report: Using E-Mail Security Service Providers to Round Out Protection," Information Week, January 18, 2010.
5. Andrew Conry-Murray, "The Public Cloud: Infrastructure as a Service," InformationWeek Analytics, September 4, 2009; see page 9.
6. Alexa Bona, "SaaS Contracting Guide: Avoid Costly Mistakes" (G00162248), November 19, 2008, Gartner subscription required.
7. Educational institutions and researchers in other countries have their own concerns about storing data on servers located in the United States because of U.S. laws permitting government access to data.
8. Details are available in the report by the Computer Security Division, Information Technology Laboratory, "Guide to Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach," NIST Special Publication 800-37, Revision 1, National Institute of Standards and Technology (February 2010).
9. In addition, Conry-Murray's report, "The Public Cloud: Infrastructure as a Service," provides a helpful table summarizing the standard audits/certifications available for some IaaS vendors on page 10.
10. This language comes from a toolkit of software license agreement clauses that I developed over the years. It's another case where clauses/issues pertinent to software acquisition are similar and applicable to cloud computing acquisition.
11. Ibid.
12. Bob Albrecht and Judith A. Pirani, "Partnership of Four: Managing Alternative Sourcing at Oakland University" (ECAR Case Study 7, 2009), EDUCAUSE Center for Applied Research; restricted to ECAR subscribers.

© 2010 Thomas J. Trappler. The text of this article is licensed under the The text of this article is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 license..