Advanced Issues in Cloud Computing Agreements

COMMON INTERNET AND
TECHNOLOGY CONTRACTS
Advanced Issues in Cloud Computing
Agreements
Cloud computing has brought a revolution in the world of internet and technology in the
last decade. Microsoft’s new resurgence under the leadership of Satya Nadella is also
Common Internet and technology contracts
Advanced Issues in Cloud Computing Agreements
based on its growth in the cloud services segment. Google, Microsoft, Amazon, Apple and
all such major service providers are themselves using and also providing cloud computing
services. Amazon Web Services, Skydrive, Google Drive, internet hosting services like
HostGator are some examples of cloud computing services.
Cloud computing agreements are generally made for three different types of models of
cloud computing:
IaaS or Infrastructure as a service - IaaS providers would provide remote access to

cloud servers and networking infrastructure which is highly automated and scalable and
can be accessed on demand. Client is generally provided with dashboards, APIs and other
resources to enable access to the servers. Eg, Amazon Web Services
PaaS or Platform as a service - It is an online platform that allows software developers

to developers to develop their software on. The platform takes care of interactions with
server hardware and network infrastructure, allowing the developer to focus on
developing the software. For example, Google App Engine
SaaS or Software as a service - Here the software can be accessed by the client through
a web browser. Many of today’s softwares as SaaS based products, for example, Google
Docs
This shift has enabled businesses to reduce costs and at the same time retain the
capability to scale up quickly when the need arises. Cloud computing raises certain legal
issues - related to data protection and others related to contractual aspects, which are
discussed here.
This chapter is relevant for businesses which utilize cloud based services - it covers key
legal and contractual issues that arise with respect to any cloud computing agreement,
and provides pointers for negotiating them. Some agreements may be standardized and
offer little room for negotiation, while others may be more customizable depending on
the needs of individual users. Examples from standardized agreements of the largest
cloud computing services providers (listed below) are used to discuss these issues
wherever possible:
● Amazon Web Services (AWS) Customer Agreement1

● Salesforce.com Master Subscription Agreement2
1
Amazon Customer Agreement (version updated on March 15, 2012) at http://aws.amazon.com/agreement/
2
Available at http://www.sfdcstatic.com/assets/pdf/misc/salesforce_MSA.pdf
© Addictive Learning Technology Pvt. Ltd.

Any unauthorized use, circulation or reproduction P-2
shall attract suitable action under applicable law.
● Google Apps Agreement3
Note: Depending on the circumstances, it may be possible to negotiate standardized

agreements as well (for example, where the client is availing of cloud-related services in
large volumes). In other cases, standardized agreements may specifically leave room for
addition of certain ‘optional’ components, which can be used by businesses to customize
the services to their needs – entrepreneurs, lawyers, consultants and other advisors who
are aware of such possibilities will be in a better position to obtain favourable terms which
protect their own or their client’s interest.
For example, most terms of the AWS agreement are standardized, with one exception -
the data-retrieval terms in the agreement (these terms are applicable if the customer
wants to recover any data from AWS services) clearly specify that Amazon may provide
additional data retrieval assistance (over and above the assistance ordinarily provided to
other users) depending on mutual agreement between parties.4 Therefore, there is room
to negotiate these terms for a business.
Cloud service agreements (CSA) primarily consists of three different agreements (though
there is a variation within the industry):
i) Customer Agreement: It defines the overall relationship between the parties. It

is also referred to as the “Master Agreement”, “Terms of Service”.
ii) Acceptable Use Policy (AUP): Most cloud providers would prohibit usage of their
services for illegal use or improper use.
iii) Service Level Agreement (SLA): This defines the performance level, availability,
etc.
In addition to the above agreements, there might be “Privacy Policy” which is applicable
on the usage of the cloud services.
Part 1: Legal and contractual issues in standardized cloud

computing agreements
Most cloud computing contracts are standard form contracts with pre-decided terms.
Entrepreneurs are usually faced with the choice of accepting all the terms in totality, or
3
Available at http://www.google.co.in/apps/intl/en/terms/premier_terms.html
4
See Clause 7.3, Amazon Customer Agreement.

else they may have to risk finding another service provider. Since the terms of the contract
are drafted by the service provider itself, they are usually one sided to begin with, but may
be modified to accommodate the interest of the business. It is much easier for
entrepreneurs to negotiate if they are able to adequately identify the risks arising from
such contracts. It is equally important for entrepreneurs who are planning to provide
cloud based services and entrepreneurs using cloud services to understand key terms in
cloud computing service agreements. After going through this chapter, they should be
able to identify the risks and even negotiate terms of agreements pertaining to cloud-
related services.
1. License to use
All cloud services, will be required to grant the user a license to use and access the
Service. The following clause can be used for a software as a service (SaaS) based
provider:
During the term of this Agreement, Customer may access and use Vendor’s
_______ service (the “Service”) pursuant to Vendor’s policies posted on Vendor’s
website at www.____________, as such policies may be updated from time to time.
Vendor retains all right, title, and interest in and to the Service, including
without limitation all software used to provide the Service and all logos and
trademarks reproduced through the Service, and this Agreement does not
grant Customer any intellectual property rights in the Service or any of its
components.
The following clause can be used for IaaS (infrastructure as a service) or PaaS
(platform as a service), where the customer is given remote access to servers:
Customer may access and use the computer system described on Attachment __ (the
“System”) from ________ until _________ (the “Subscription Period”). Vendor retains all right,
title, and interest in and to the System, including without limitation all computers, other
hardware, and software incorporated into or used by the System, and this Agreement
does not grant Customer any intellectual property rights in the System or any of its
components.
2. Data security, Confidentiality and Data policies

If your business handles personal data which is either processed or stored on cloud
servers located in multiple locations, the primary responsibility under statutory

provisions for data security and confidentiality is on your business, not the cloud
computing service provider. Breach of this responsibility can result in serious
liabilities. Key legal and contractual issues connected with this are described below:
i) Cloud computing agreements sometimes mention that security practices

that are ‘reasonable’ or which qualify as ‘industry standard’ will be observed
with respect to customer’s data. However, these terms are not objectively
defined, so it is prudent to specifically identify and mention any industry
standards that the service provider will be compliant with under the
agreement. For example, ISO 27001 is one such standard.
ii) Some organizations also state that their controls, processes and data
protection policies will be periodically reviewed and audited – often, clients
are not provided the opportunity to understand or observe the results of
the audit process. Wherever possible, an entrepreneur should incorporate
an opportunity to be informed about review and audit processes.
iii) Sometimes large companies assign functions to their ‘associate’ or ‘group’

companies, or to third parties. Certain cloud SLAs also allow the service
provider to transfer data to any jurisdiction that it considers fit. This can be
dangerous if the entity in the new jurisdiction to which the data is
transferred does not follow similar standards - in such cases, it should be
ensured (through incorporation of specific terms in the cloud computing
agreement), that the security practices adopted by a transferee entity are
at least of the same level as required under Indian law. Moreover, it is
necessary to check the agreement whether the data can be moved to
another country and whether any advance notice would be given to the
customer.Also one needs to check if there is any way to verify the physical
location of the data and whether such transborder flow of data has any tax
or regulatory implications. This might be important if you are specifically
dealing with client data of EU countries and other countries which have laws
restricting or regulating transborder flow of data.
Further, the circumstances under which government and regulatory

authorities can be provided access to such information is important - if
access to an Indian regulator is refused by the cloud computing service
provider without justification, the Indian startup may be in breach of data
protection laws. Therefore, a business (which has presence in India) should
consider inserting a clause imposing an obligation on the cloud services

provider to allow access to information to Indian government or its

authorized agencies as per the provisions of Indian law. In case of seizure
of data by government agencies, the cloud provider should provide notice
of such access.
iv) It is also important for the entity using the cloud computing services that
confidential data is not used by the cloud computing service provider, its
agents, or any third parties who provide backend services to the cloud
computing service provider, for any purpose, apart from providing the specific
service that is the subject matter of the agreement.
A business could consider incorporation of a specific term that prohibits the

cloud computing service provider from disclosing any confidential
information to any other entities unless it provides prior notice. Many
standardized agreements lack this provision by default.
v) It is important to have proper data preservation and retention policy. Users

should ensure the CSA supports their data preservation strategy that
includes sources, scheduling, backup, restore, integrity checks, etc. The
cloud provider should be able to demonstrate tests for such practices.
Examples from standardized agreements
● AWS: Section 9.2 of the AWS Agreement provides that the Amazon Services
does not have any confidentiality obligation and cannot be held liable in
case of breach of privacy.
● Google Apps: According to Section 8 of Google Apps Agreement, duty to

protect any information will only exist if it is clearly and specifically marked
as confidential or whose confidentiality is not in doubt (this is a subjective
expression). A reasonable degree of care is supposed to be exercised in
protecting the data. Hence, it is prudent for businesses using this service to
specifically identify which data is confidential.
● Salesforce: Under Section 8.2 of the Salesforce Agreement the service

provider must use reasonable degree of care to protect data, and cannot
use confidential information of the user for any other purpose apart from
those given in the agreement.

3. Limitation of service provider’s responsibility with

respect to data protection
An enterprise user will desire that a cloud computing service provider is held liable
for any losses caused out of a security breach - the liability of the service provider
should therefore be linked to the loss caused to the business. However, most service
providers contractually impose a financial limit on their liability (which may be too
low) and even exclude indirect losses or special damages. Standardised SLAs such
as AWS, Google Apps or Salesforce completely disclaim all liability with respect to
consequential or indirect losses. Salesforce, for example, limits its liability to US
$500,000 for any single incident, even if actual losses are higher.5
Ideally, in case of a negotiated cloud SLA, the cloud service provider should be
informed about the importance of the service to the entire process by the business
availing of the service, and the quantum of loss that interruptions could cause to it
– which should be recorded in the contract. Even if indirect or special damages are
excluded, any financial limitations on the liability of the service provider should be
computed keeping in mind how critical the function outsourced to the cloud
computing service provider is to the business operation as a whole.
4. Third party dependencies

Cloud computing service providers may be dependent on a lot of third party vendors
for provision of their services. This can create a potential risk for an enterprise user
– since the quality and availability of cloud computing services is dependent on the
capability of these third parties as well. Often, cloud services providers may state
that they are only responsible for failures in performance arising from the
infrastructure or services that they own. It does not include responsibility for failures
by third parties.
Sometimes, third parties can provide extremely critical services to the cloud
computing service provider which endangers the availability of the cloud computing
service itself. In such cases, cloud computing service providers tend to retain the
right to terminate the agreement altogether (without providing any costs or
compensation to the client/ enterprise user) if a third party relationship has been
adversely affected.
5
Clause 11, Salesforce Agreement.

For example, a clause in the AWS Agreement characterizes the uncertainty inherent
in cloud computing agreements – it states that Amazon can terminate the
agreement immediately upon notice if its relationship with a third party partner who
provides software or other technology it uses to provide its services expires,
terminates or requires it to change the way it provides software or other technology
as part of its services, if it believes providing the services could create a substantial
economic or technical burden or material security risk for itself.6
It is important to understand whether third parties (other than the cloud provider)
are involved in the provision of cloud services. From the perspective of a business
availing cloud-based services, it is important that the responsibility for performance
of the third party’s services is undertaken by the cloud service provider, since it does
not itself have a direct relationship with the third party service providers.
Often the providers will put the responsibility of updating third party software on
the client itself. This is often done to absolve liability in case the update breaks the
system and disrupts client’s operation. Another way of updating of third party
software is done through “push updates”. While negotiating agreements, one should
ensure that the provider must provide prior notification of the same with an on
option to opt out or defer the update. In some cases, the provider might not be
willing to provide support for older systems. The provider should generally seek an
exception for updates for critical security updates which can be made mandatory.
Steps to ensure reliability of cloud-based infrastructure for your business
It is one thing when the cloud fails to serve you (personally), and another when it
fails all your customers. As, cloud computing service providers may be dependent
on third party vendors for provision of their own services, it can create a potential
risk for an enterprise user. They may state in their SLAs that they are only
responsible for failures in performance arising from infrastructure or services that
they own, but not from failures of any third parties that their services are dependent
on. This is extremely risky for businesses, and many entrepreneurs are not insist on
SLAs or fail to read them carefully enough - hence, they fail to address such risks.
Thus, any business availing a cloud-based service must undertake efforts to find out
about third party dependencies of the service provider and specifically allocate risk
of failures arising from the dependencies through negotiation of the agreement. If
6
Clause 7.2(b)(ii) of the AWS Agreement.

the service provider is unwilling to accept appropriate responsibility for such risks,
it may be worthwhile to consider alternative service providers.
5. Key business level terms

i) Acceptable use policy: This clause would typically lay down the terms and
conditions for usage of your services. It would also mention the grounds for
which you cannot use the service.
ii) Excess use: What will happen if the usage exceeds the prescribed level
mentioned by the provider? Users may find that some of the service
providers might have clauses which might state usage above the thresholds
would result in high costs (often in a punitive manner). This needs to be
taken into account.
iii) Activation: It is important to identify from when the service will start, for
example, it can start from a designated date or when the user logged in to
the system for the first time. As many performance indicators are laid down
for particular time period, it would be essential to identify the starting date
of activation of the service to measure such performances.
iv) Payment: Most cloud providers require the customers to make payment
on a periodical basis (say 1 month/ 3 months/ 1 year) or “pay as you use”
basis (where the invoice is made based on usage). In certain agreements,
the provider gives credits (in compensation for outages and downtimes)
which can be used to make payment as well. Understand the terms clearly.
v) Versioning: Cloud providers may introduce new features or deprecate old

features during the term of the agreement. It is important to have clauses
which would require the Cloud provider to intimate the users of such
changes in advance.
vi) Renewal: Many agreements have clauses that will lead to automatic
renewal of the agreement if no notice of cancellation of service is given
before the specified date (often 90 to 30 days). This might impact you, if you
are planning to move to a different service or want to cancel the service
altogether after the first term. In case, there are such clauses, do keep a
reminder to cancel before such due dates.

vii) Transferability: One must check, if the user can transfer the license to
someone else (especially if the business is acquired or merged). At the same
time, one might not want to continue with the service, if the provider is
acquired by a different company. Is there a way to terminate the agreement
in such cases.In case an user has multiple accounts with the same provider,
is it possible to offset credits between such accounts.
viii) Support: It is one of the most important clauses in the agreement. The
support clause should clearly lay down service levels for providing support,
for example first response time, resolution time, escalation metrics, etc.
6. Discretion of the service provider to terminate services

Vendors can have extensive freedom under the cloud computing agreement, often
standardized SLAs specify the circumstances in which the vendor can terminate the
agreement or unilaterally modify the scope of its services without sufficient notice
or compensation.
An entity availing of cloud computing services must bear in mind whether the
agreement can be terminated prematurely when it is not at fault. It may consider
specifying a longer notice period (so that it can look for alternative service providers)
or compensation by the service provider if a shorter notice is provided in case of
premature termination.
Usually the notice period is longer if the contract is terminated due to no fault of the
customer, and much shorter if it is terminated for reasons of breach, or due to
changes caused by occurrences that are not in the hands of a cloud computing
services provider, e.g. a change in legal regulations that make it difficult or
commercially unviable to provide the services.
Examples
● AWS: under the AWS Contract, Amazon can terminate the contract any time
for any reason or no reason after giving a notice 60 days in advance.
● Google Apps: The Google Apps Service Contract provides for a 6-month notice
period, if the termination is without cause, or for 30 day notice period if a user
fails to cure any breach of contract caused by him. In case of multiple instances
of a breach by a client, Google can terminate, suspend or modify the terms
service at its option, after giving a reasonable notice. Google may also do so if

Any unauthorized use, circulation or reproduction P - 10
it reasonably determines that it is commercially impractical to continue

providing the Services in light of applicable laws.
● Salesforce Agreement: Under the Salesforce Master Subscription (SMS)

Agreement, A party can terminate the agreement after giving a notice of 30
days if there has been a breach, and if the breach has not been cured in that
period. It can also terminate if the other party becomes the subject of a petition
in bankruptcy or any other proceeding relating to insolvency, receivership,
liquidation or assignment for the benefit of creditors.
7. Changes to the terms of services under the agreement

Service providers often retain a unilateral right to modify the terms of the agreement
at any point of time, just by posting the modification on their websites. Often, the
scope of the ‘modification’ is not limited or restricted. A business should insist on
written assurances in the cloud computing agreement that the key commercial
terms of the contract will be preserved, and that modifications which adversely
affect the customer will not be made without consultation with the customer or
providing suitable compensation for any losses.
Examples:
● AWS: As per Clause 2 of the Amazon Web Services (AWS) agreement, Amazon
reserves the right to revise or modify the terms of the contract anytime, which
become effective upon posting on the website and it is the user’s responsibility
to keep checking the website for renewed/ modified agreements.
● Google Apps: As per the Google Apps agreement, Google can make
modifications to the agreement at any time, which become effective upon
posting on the website and it is the user’s responsibility to keep checking the
website for renewed/ modified agreements.
Comments on the Google Apps and AWS Agreement
1) In case of both – AWS and the Google Apps agreement, it is not necessary for
the user to have been specifically intimated about the change or for it to have
read the modified conditions on the website - if the user continues to use the
service, it is automatically assumed that it has accepted the revised condition.
2) The agreements do not specify whether the customer has any consequential
right to terminate the agreement (apart from the ability to terminate the

agreement by a notice) in the event there is a modification. The vendor can

modify the agreement by simply posting on its website and the continued use
of the service by the customer implies the latter’s approval to the modification.
This takes away the customer’s right to terminate the agreement if the
modifications are unacceptable to him.
Note: As per the Indian Contract Act, 1872, such modification of the contract
amounts to novation, which is considered to be a fresh agreement in law. A fresh
agreement requires fresh consent of all parties and cannot be effective simply
through unilateral alteration. Secondly, if a service provider can unilaterally modify
the agreement at any time, a court of law may hold (in case the agreement is
challenged) that the agreement is uncertain and hence ineffective.
8. Provisions with regard to suspension of services or other

interruptions
Suspension of service and unplanned interruption in service by the service provider
can have a serious impact on continuity and might lead to considerable damage to
the user. Generally under these contracts, the service provider is insulated against
any liability arising out of such suspension of service.
Examples
AWS: As per Clause 7 of the AWS agreement, Amazon can suspend the service for
any reason, including system failure. Amazon is only required to give a 60-day
notice. It is not required to assign any reason. For suspension on account of a
reason specified in the contract, a shorter notice of only 15 days is sufficient.
Salesforce: Salesforce can suspend service under the Salesforce Agreement if the
amount owed by the user is overdue for more than 30 days, after a 7-day notice.7
9. Client’s right to terminate an agreement

While negotiating an SLA for using cloud services, a business should assess whether
it has the right to terminate the service in case the service regularly falls below
agreed service levels. In such cases, the duration of notice required for termination
must be short. The amount of termination penalties payable and the quality of
7
Clause 6.4, Salesforce Agreement.

support available from the service provider’s end for migration of client’s data in
such cases should be known in advance.
10. Conflicting agreements / clauses

Cloud documentation with service providers can be quite complex – many
companies do not enter into a single agreement but refer to multiple agreements
and policies such as service level agreements, privacy agreements, terms of service,
etc., which must be agreed by the user (by a simple click on the ‘I Agree’ button) as
a condition to availing the cloud computing services. Services offered by Google are
an example. In such cases, it is extremely difficult for an uninitiated user to
understand the terms that collectively apply. There is also a risk of inconsistency
amongst different policies.
What should a businessman/ entrepreneur availing cloud computing services be

aware of in such cases?
It is important to know whether the documents apply to different components of

the service, or whether all of them apply together to the same service. For example,
the terms of service for Google Hangouts are different when it is private, compared
to when the Hangout is broadcast live on YouTube. Similarly, there should be some
level of consistency with respect to the essential terms - an entrepreneur should try
to find out which document takes precedence in case there is a conflict in the terms
of different documents. If such a clause is absent, it must be specifically included in
the agreement.
11. Disputes, governing law and jurisdiction of courts

A cloud computing agreement usually specifies the law of the country which will be
applied in resolving any contractual dispute. Indian entities availing of cloud
computing services would prefer Indian law to be applicable (for the sake of
certainty and convenience), wherever possible. Some cloud computing service
agreements specify that the law of the country where the contract has been entered
into will be applicable. A service provider operating from India is likely to agree to
the applicability of Indian law. However, this is not the case in case the service
provider is a behemoth and is based in another jurisdiction – for example, Google,
Amazon, etc.

For example, the AWS agreement and the Google Apps Agreement are both subject
to laws of the US, while the Salesforce agreement is subject to the law of U.S.,
Canada, Switzerland, Japan or Singapore, depending upon the place of contract.
Similarly, the jurisdiction whose courts can be approached in case of a dispute is

also important. In most cases, a judicial authority is likely to respect the choice of
the parties as specified in the agreement, so long as the contract has some
relationship with that jurisdiction. For example, if a service provider is based in the
US and the client is in India, an Indian court will refuse to entertain a dispute before
itself. However, if the agreement confers jurisdiction on the courts of UK, such a
choice will be invalid.
Standard form agreements drafted by major service providers specify that all legal
claims are subject to the exclusive jurisdiction of the country where the service
provider is situated (and not the user’s country). In a substantial number of cases,
the user is based in another country, making the clause extremely inconvenient for
the user to enforce (in case such a situation arises).
For example, under the AWS Agreement, any dispute where compensation of more
than US $7,500 is claimed is subject to exclusive the jurisdiction of courts in
Washington. The Salesforce contract, on the other hand, specifies 5 cities (by region)
where disputes may be settled, depending on the region where the user is based.
India is not one of the countries on that list.
There must be an escalation clause included within all contracts for disputes. Clear
processes should be in place for resolving contractual issues, especially those
associated with SLA adherence. Strong escalation processes around SLAs can be a
critical element in establishing open communication, transparency and a healthy
overall relationship with key vendors.
12. Termination process, vendor’s responsibility on

termination, including data retention and transfer
provisions
A cloud computing agreement may be terminated on account of various reasons -
expiry at the end of its stipulated term, termination for default or simply by notice
by either party. A business user should have the ability to terminate the contract by
serving a notice (which could be useful in the event of migration to an alternative
service provider).

At the time of entering into the contract, an entrepreneur must be aware of how
data will be treated post termination of the contract - whether it will be stored on
the cloud servers post-termination for some time or immediately deleted, whether
data can be migrated in a usable form, downloaded for transfer in a format which
is compatible for use on other cloud computing platforms (without compromising
on confidentiality or security of the data).
Since there are no obligations for a service provider to facilitate data migration, an
obligation for facilitating and cooperating in the process of data migration or
retrieval must be specified in the contract. Where a cloud computing agreement is
negotiable, the user should make sure that terms regarding data transition are well-
documented under the SLA.
The discussion below highlights some of the important post-termination issues in

relation to cloud computing agreements in greater detail:
i) Does the SLA have any provision regarding data transfer? What is the
mechanism for data transfer?
It may be prudent to incorporate a detailed mechanism for retrieval,

transfer or migration of data. The mechanism should ideally indicate when
and how the transfer process can be initiated, the costs for transfer, time-
process in which transfer can be completed, format in which data is
transferred (the migrated data must be in some standard format which is
compatible with other service providers’ infrastructure as well) and any
other critical details keeping in mind the business of the user. Usually, data
can be retrieved if request is made upon within a stipulated time period
after termination. Some agreements may require additional fees to be
payable in case of termination.
The contract must also clearly specify the liability of service provider in case
of loss of data. Specific provisions regarding the form, appearance or
presentation in which data needs to be returned should be given in the
contract.
ii) For how long after termination will data be stored on the cloud? What are
the conditions for retrieving data?

(Note: This question is especially relevant if third party data is also stored on
the cloud)
The user might prefer that the data is deleted and that no backups of the
same remain once he terminates the services of the cloud operator.
Questions relating to confidentiality and circumstances permitting
disclosure of data assume even more important if the business has availed
of cloud services for storing or processing third party data. The user’s
responsibility for the third party data will depend on the provisions of the
Information Technology Act and terms and conditions in any contract, end-
user license agreement (EULA) or disclosure statement with the third
parties.
Examples
● AWS: As per the AWS Agreement, ordinarily data will be stored for 30
days post termination (barring exceptional cases), and Amazon will
extend the same level of assistance in data retrieval as is provided to
other users. Any further assistance is subject to mutual agreement
between the user and Amazon.
● Salesforce: As per the Salesforce Master Subscription Agreement,

Salesforce is only responsible for returning data if a request is made
within a period of 30 days by the user – after 30 days they are free to
delete data from their system. Salesforce provides user data in CSV
(comma separated values) format and in the native format that was
uploaded by the user.
● Google Apps - Under the Google Apps Agreement, Google may

transfer, store, and process customer data wherever it maintains its
facilities or wherever it wants to. The customer consents to this
transfer, store and process, by using the services.
13. Service models and considerations

The Cloud Standards Customer Council recommends the following standards and
consideration for different service models.
IaaS

● Cloud IaaS CSAs are similar to SLAs for network services, hosting, and data
center outsourcing. The main issues concern the mapping of high-level
application requirements on infrastructure services levels.
● Metrics are well understood across the IaaS abstractions (compute, network,
and storage). Customers should expect to find a subset of the following
metrics in their cloud SLA.
○ Compute metrics: availability, outage length, server reboot time

○ Network metrics: availability, packet loss, bandwidth, latency, mean/max
jitter
○ Storage metrics: availability, input/output per second, max restore time,
processing time, latency with internal compute resource
● Compute metrics usually exclude service levels for compute performance.

Customers are simply guaranteed availability of the compute resources for
which they paid.
● Customers must distinguish between IaaS development environments and
IaaS production environments when reviewing their cloud IaaS service
agreements. IaaS production environments will typically require more
stringent service level objectives than IaaS development environments.
● Network metrics in a cloud SLA generally cover the cloud provider's data
center connectivity to the Internet as a whole, not to any specific provider or
customer.
● Whenever possible, customers should ensure the CSA includes provisions
requiring their cloud providers to support open standard interfaces, formats
and protocols to increase interoperability and portability.
PaaS
● Two main approaches exist for building PaaS solutions: integrated solutions
and deploy-based solutions. When reviewing the PaaS service agreement,
customers should consider tradeoffs in flexibility, control, and ease of use to
determine which approach best meets their business needs.
○ Integrated solutions are web accessible development environments which

enable developers to build an application using the infrastructure and
middleware services supported by the cloud provider. Management of the
application and its execution is primarily controlled by the cloud provider.

Typically, service developers only have access to a provider-defined set of

APIs which offer limited control on the coordination of code execution.
○ Deploy-based solutions enable deployment of middleware on top of
resources acquired from an IaaS cloud provider, offering deployment
services to the customers which automate the process of installation and
configuration of the middleware.5 These PaaS solutions offer a rich set of
management capability including the ability to automatically change the
number of machines assigned to an application, and self-scaling according
to the application’s usage.
● At a minimum IaaS SLA’s should roll into PaaS SLA’s.
● Customers must distinguish between PaaS development environments and

PaaS production environments when reviewing their cloud PaaS service
agreements. PaaS production environments will typically require more
stringent service level objectives than PaaS development environments.
● Standards are emerging to help identify PaaS services offered by cloud

providers and standard interfaces for communicating with PaaS providers to
provision or manage PaaS environments. Standards, like OASIS Topology and
Orchestration Specification for Cloud Applications (TOSCA) have come about
to address portability and interoperability across providers. In addition, PaaS
open source offerings such as Cloud Foundry and OpenShift are starting to
build momentum in the market.
● Customers should ensure their CSA includes support for open standards, as
they become available, to reduce vendor lock in.
SaaS
● Customers should insist on flexible CSAs that are measurable against their
objectives, not the cloud providers’ reporting needs.
● Given the wide variation of services provided at the SaaS level, it is difficult to
provide a comprehensive and representative list of SaaS service level
objectives for customers to look out for in their CSAs.
● Customers should expect general SaaS service level objectives like monthly
cumulative application downtime, application response time, persistence of
customer information, and automatic scalability to be included in their CSA.

● Customers should ensure that data maintained on the provider’s cloud

resources be stored using standard formats to ensure data portability in the
event that a move to a different provider is required.
14. Deployment model and terms to be reviewed

Apart from service models, it is important to specify the deployment terms. Here
are some of the deployment models and typical considerations that must be
addressed in the agreement:
● Private (On-site) - It would be similar to a typical enterprise IT SLA. As it would

be deployed within a large number of users, customers must ensure that the
agreement has taken into account critical service objectives like availability
and response time are met via ongoing measurement and tracking.
● Private (Outsourced) - It is similar to the private (on-site) model, with the

difference that the service is provided by an external service provider. With
the introduction of third party, the customer should ensure that the
agreement specifies security techniques for protecting the provider's
perimeter and the communications link with the provider.
● Public - With public model, the security risk increases as the IT resources are
used by multiple clients. Customers should carefully review the CSA to
understand how the provider addresses the added security, availability,
reliability and performance risks introduced by multi-tenancy. One should also
check whether they have the ability to measure and track specific service level
objectives.
● Hybrid model- The considerations are similar to the public model, with
specific requirement of integrating cloud services with enterprise solutions.
The agreement should cover the service and data integration requirements,
and security requirements.
15. Negotiating service levels

While Amazon, Salesforce and Google Apps have standardized agreements and it
may not be feasible to negotiate these in a real-life situation for a small business,
the business could avail cloud-based services from other providers (whether they

operate in India or abroad), who provide the opportunity to negotiate

commitments. In such cases, apart from negotiating the clauses in the agreement
(as explained above), the heads specifying the ‘service levels’ (typically in the
annexure to an agreement) may also require negotiation. Typically, the business
should know about the uptime percentage. However, the computation of uptime
percentage can vary depending on the way it is calculated under the specific cloud
computing agreement. Usually, the following variables must be scrutinized to
understand how uptime percentage is calculated:
● Downtime: When is a site or service considered to be down? Every moment

at which the site or service is not accessible is not counted towards downtime.
In many agreements, downtime count starts only when there is more than a
5% user error rate. While defining metrics for Uptime and Availability it is
essential to define certain terms which might vary from one country to
another. For example, if the uptime guarantee is for “regular business hours,”
then organizations with multiple locations in different time zones need to
clarify whether the guarantee covers only the headquarters location or all
regions. Similarly, “week-ends” or “holidays” have different meanings in
different countries.
● Downtime period: A period of 10 consecutive minutes of downtime.
● Intermittent downtime: A period of less than 10 minutes is not counted

toward downtime periods.
● Monthly uptime percentage: (Total number of minutes in a calendar month

- number of minutes of downtime) / (Total number of minutes in a calendar
month).
● Scheduled downtime: This refers to periods when a provider notifies

customers of downtime at least five days prior to the commencement of such
downtime. Is there a limit on the maximum scheduled downtime per calendar
year? Is scheduled downtime counted towards total downtime? Providers such
as Google do not consider scheduled downtime as countable toward the total
downtime.
● Response time: It is the elapsed time between when the service is invoked
and when it is completed (measured in milliseconds).

How should service levels be negotiated?
A business should ideally identify critical needs and times when the cloud computing
service must be available for users. Usually, this is done through managerial
processes which identify and establish key performance indicators (KPIs) which are
unique to the company’s business requirements. Some of the metrics which are
relevant to establish KPIs could be:
● acceptable latency levels,

● the measured impact of downtime or lost data,
● the need for constant access to business data (current or archived), and
● a usage patterns for cloud services
For example, if a business expects peak transaction load at certain times of the
month (and at other times the transactions are relatively insignificant), latency
figures based on monthly averages will not be ideal indicators of the quality of the
service – it is possible that the monthly average is good, but the service is not
available during times when the business faces peak transaction load.
Example – How Google altered its policies to benefit users
In January 2011, Google announced that it will no longer provide an exception for
scheduled downtime (usually services are down during pre-planned upgrades) or
intermittent downtime (downtime (downtime lasting less than 10 continuous
minutes). Therefore, both scheduled downtime and intermittent downtime would
be considered by Google as regular downtime and hence would be counted as a
shortfall in the service. It became the first cloud provider to eliminate headroom for
maintenance activity.
Consequences of failure to meet service levels
The reliability, performance and reputation of a cloud service provider must be

evaluated before entering into a commercial relationship with the provider - if the
website or an essential application is down at a time when it is witnessing its highest
traffic, end users may lose access to critical data and applications, which could
severely impact the business.
At the time of entering into an agreement with a cloud service provider, the
consequences of failure to meet desired service levels should be known in advance.

What is the policy of the service provider if it fails to meet agreed service levels?
Many SLAs entitle users to receive ‘credits’, which usually is set-off against future
payments of the service to the provider (money is not usually refunded directly in
liquid cash or equivalents). A more sophisticated structure could involve service
credits that progressively escalate as the length of downtime increases. The credits
should impose significant obligations on the vendor, so that he is incentivised to
provide acceptable levels of service.
Secondly, the length of the period over which downtime is measured is important.
The longer the measurement period, the more diluted the effects of the downtime.
For example, downtime of 5 minutes per week may be more acceptable, as
compared to 5 minutes per day.
Thirdly, any circumstances when failure to meet service credits will not lead to
accumulation of credits should be taken into account.
16. Reporting requirements

While most cloud providers will provide a user with certain reports which discusses
about the health of the system. Here are a list of reports that should be obtained
from the provider:
i) Periodic assessment of achieved cloud service levels against agreed CSA

ii) Periodic assessment of compliance of cloud service - It is important to verify
whether the provider is in continued compliance with specific standards or
regulations.
iii) Service failure reports- It should mention all events which affected service
availability, security breaches and failure to protect personal data
iv) Changes: It should mention changes in functionality, service level objectives,
pricing, terms, etc.
v) Key indicator reports: It should include the following parameters:
High impact problems and time to resolution
● Number of open problems and their respective impact

● Total view of problems not resolved within agreed to time frames

● Trends of number of problems being reported with the resulting

resolutions
vi) Problem reports: Reports that focus on the current reporting period
addressing:
● All problems reported (sorted by impact)

● Problems closed (sorted by impact)
● Duration of open problems (sorted by impact)
vii) Request report: It would contain reports on (non-problem) requests made by

the cloud service customer to the cloud service provider including the
following parameters:
● All requests made

● Number of open requests
● Time to action requests
viii) User satisfaction report
This reports should be analysed periodically to identify deviation, suitable

recourse and fixing of problems. In some cases, the customers may be able
to seek damages, which often needs to be communicated in a manner as
provided in the agreement.
17. Measuring and metering

As many services are billed based on usage, it is important to have a proper
mechanism to measure the services used. Here are some of the pointers which
should be taken into account while negotiating an agreement:
1. Assurance of accurate billing, and a methodology for handling objections or

challenges to any automated metered billing
2. The ability to segregate different services into different methods of billing:

for example, performance testing, analytics, security scanning, backup, and
virtual desktops might all be measured differently and metered separately.

3. Ability to handle taxation issues from geography to geography, and from

user to user. As each country and municipality has implemented different
approaches to taxation of online commerce, your provider must be able to
discern between these sources of use and meter them independently.

Pointers to deal with downtimes and outages
❏ Here are a list of questions/pointers that must be taken into account to deal
with downtimes and outages:
❏ How is service outage defined?
❏ What level of redundancy is in place to minimize outages including co-
location of services in different geographical regions?
❏ Will there be a need for scheduled down time?
❏ Who has the burden of proof to report outages? This can be difficult to prove
in case of conflicts with the cloud providers.
❏ What is the process that will be followed to resolve unplanned incidents?
❏ How will unplanned incidents be prevented or reduced?
❏ When does the time clock start on lack of service availability in order to
measure service credits?
❏ How will incidents be documented or logged?
❏ What actions will be taken in the event of a prolonged disruption or a
disruption with a serious business impact?
❏ What is the process of performing disaster recovery testing, and how often
are the tests conducted? Are the reports of the tests provided to clients and
are the tests automated?
❏ What is the problem escalation process?
❏ Who are the key service provider and customer contacts (name, phone
number, email address)?
❏ What is the contingency plan during a natural disaster?
❏ How is the customer compensated for an outage? It must be noted that cloud
providers have limits on the maximum compensation provided in case of an
outage, and the compensation is an insignificant remedy in case of serious
outage.
❏ Does the cloud vendor provide cloud insurance to mitigate user losses in
case of failure? Although this is a new concept, some major cloud vendors
are already working with insurance providers.


Advanced Issues in Cloud Computing Agreements

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Advanced Issues in Cloud Computing Agreements

Uploaded by

Copyright:

Available Formats

COMMON INTERNET AND

IaaS or Infrastructure as a service - IaaS providers would provide remote access to

PaaS or Platform as a service - It is an online platform that allows software developers

● Amazon Web Services (AWS) Customer Agreement1

© Addictive Learning Technology Pvt. Ltd.

● Google Apps Agreement3

Note: Depending on the circumstances, it may be possible to negotiate standardized

i) Customer Agreement: It defines the overall relationship between the parties. It

Part 1: Legal and contractual issues in standardized cloud

© Addictive Learning Technology Pvt. Ltd.

2. Data security, Confidentiality and Data policies

© Addictive Learning Technology Pvt. Ltd.

i) Cloud computing agreements sometimes mention that security practices

iii) Sometimes large companies assign functions to their ‘associate’ or ‘group’

Further, the circumstances under which government and regulatory

© Addictive Learning Technology Pvt. Ltd.

provider to allow access to information to Indian government or its

A business could consider incorporation of a specific term that prohibits the

v) It is important to have proper data preservation and retention policy. Users

Examples from standardized agreements

● Google Apps: According to Section 8 of Google Apps Agreement, duty to

● Salesforce: Under Section 8.2 of the Salesforce Agreement the service

© Addictive Learning Technology Pvt. Ltd.

3. Limitation of service provider’s responsibility with

4. Third party dependencies

© Addictive Learning Technology Pvt. Ltd.

Steps to ensure reliability of cloud-based infrastructure for your business

© Addictive Learning Technology Pvt. Ltd.

5. Key business level terms

v) Versioning: Cloud providers may introduce new features or deprecate old

© Addictive Learning Technology Pvt. Ltd.

6. Discretion of the service provider to terminate services

© Addictive Learning Technology Pvt. Ltd.

it reasonably determines that it is commercially impractical to continue

● Salesforce Agreement: Under the Salesforce Master Subscription (SMS)

7. Changes to the terms of services under the agreement

Comments on the Google Apps and AWS Agreement

© Addictive Learning Technology Pvt. Ltd.

agreement by a notice) in the event there is a modification. The vendor can

8. Provisions with regard to suspension of services or other

9. Client’s right to terminate an agreement

© Addictive Learning Technology Pvt. Ltd.

10. Conflicting agreements / clauses

What should a businessman/ entrepreneur availing cloud computing services be

It is important to know whether the documents apply to different components of

11. Disputes, governing law and jurisdiction of courts

© Addictive Learning Technology Pvt. Ltd.

Similarly, the jurisdiction whose courts can be approached in case of a dispute is

12. Termination process, vendor’s responsibility on

© Addictive Learning Technology Pvt. Ltd.

The discussion below highlights some of the important post-termination issues in

It may be prudent to incorporate a detailed mechanism for retrieval,

© Addictive Learning Technology Pvt. Ltd.

● Salesforce: As per the Salesforce Master Subscription Agreement,

● Google Apps - Under the Google Apps Agreement, Google may

13. Service models and considerations

© Addictive Learning Technology Pvt. Ltd.

○ Compute metrics: availability, outage length, server reboot time

● Compute metrics usually exclude service levels for compute performance.

○ Integrated solutions are web accessible development environments which

© Addictive Learning Technology Pvt. Ltd.

Typically, service developers only have access to a provider-defined set of

● At a minimum IaaS SLA’s should roll into PaaS SLA’s.

● Customers must distinguish between PaaS development environments and