If It’s in the Cloud, Get It on Paper:

Transcription

If It’s in the Cloud, Get It on Paper:
Cloud Computing Contract Issues
By Thomas J. Trappler
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."1 This is the case with cloud computing. Most transitions to a
cloud computing solution entail a change from a technically managed solution ("I build
http://www.educause.edu/EDUCAUSE+Quarterly/EDUCAUSEQuarterlyMagazineVolum/IfItsintheCloudGetItonPaperClo/206532
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.2 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."3 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."4 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.5
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.6 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?7 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...
Data Center Security Cam Recordings of 09.09.09...
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)8
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.9
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 inhouse 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.10
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.11
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.12 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.
Note: Since cloud computing services are easily initiated — typically via click-through
agreements — by end users without involving institutional experts, it can be important to
disseminate such guidelines and best practices documentation through an institution-wide
outreach campaign to educate faculty and staff.
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.
Contribute to the Cloud Computing Contracts Wiki
In concert with this article, a new EDUCAUSE wiki focused on cloud computing
contracts has been established. The example contract clauses in this article have been
posted to this wiki with the hope that others will add to them and create a living
repository of such clauses.
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.
Endnotes
1. "The Evolution of the CIO: An EDUCAUSE Issues Brief," EDUCAUSE, October
2009.
2. Frank Ridder and William Maurer, "Negotiation and Contracting for CloudEnabled 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..
AUTHOR INFORMATION:
Thomas Trappler
Director, UCLA Software Licensing
UCLA

If It’s in the Cloud, Get It on Paper:

Transcription

Similar documents

Forming underneath the base of a cumulonimbus cloud, mammatus

Read More - FusionStorm

iPPlus Sales Sheet - IP Plus Consulting, Inc.

Public and Private Cloud Interoperability

Company Fact Sheet 2016

Changes That Heal_indd

for Kamstrup Omnipower - smart-me

02. Plenair Tom Welling Dharminder Debisarun

Open Cloud Initaitive http://www.opencloudinitiative.org/ Sam

Zajil Telecom eHosting Datafort