News Stay informed about the latest enterprise technology news and product updates.

In the fine print: Dissecting a cloud service agreement

Without a cloud service agreement, public cloud users would be in the dark about crucial factors related to cloud performance, security and data privacy.

Like any contract, though, cloud service agreements aren’t the easiest documents to digest; their length and complexity can tempt even the most diligent cloud users to skim, sign and be done. This complexity has only increased as the industry itself has evolved, to reflect the move toward hybrid cloud, as well as new data privacy requirements.

Failing to scrutinize a cloud service agreement, however, is a major mistake, said Claude Baudoin, owner of cébé IT & Knowledge Management, an IT consulting firm in Austin, Texas.

Baudoin and other members of the Cloud Standards Customer Council (CSCC), a cloud user advocacy group, hosted a webinar this week focused on evaluating cloud service agreements. The overarching message: Don’t ignore the fine print.

The four pillars of a cloud service agreement

A public cloud service agreement, Baudoin explained, is generally broken up into four parts:

  1. Customer agreement document – the overarching, “umbrella” document that the user signs
  2. Acceptable use policy – a document that defines what the user is allowed, and not allowed, to do as a tenant of a public cloud service
  3. Service-level agreement – a document that defines the public cloud provider’s commitment to the user, and the consequences when the provider fails to meet those commitments
  4. Privacy policy – a document that outlines what the public cloud provider can, and can’t, do with the personally identifiable information (PII) that the cloud user might share in the process of contracting the service

The language of the agreement is usually spread between these four documents, and often the initial version the provider proposes won’t match the user’s expectations, Baudoin said. “That is why you cannot just close your eyes and sign on the bottom line. You have to scrutinize this language,” he said.

Data privacy and residency terms may not be presented in a single, well-identified place, for example. Instead, those terms could be scattered throughout these four documents, particularly throughout the acceptable use policy, the service level agreement and the privacy policy.

When evaluating the data privacy and residency terms of an agreement, remember that most security clauses are intended to protect the provider from any potential threats that users pose to the provider, the platform itself and to other users of the platform. In other words, most of the language reflects what the cloud users — not the provider — can and can’t do.

Also make sure the agreement outlines, in detail, the process that occurs in the event of cloud security breach. Terms should spell out how users will be notified of a breach, how they will be protected and how they will be compensated for data loss or corruption.

“This is where you really want these [terms] to be well-defined,” Baudoin said.

Agreements vary based on deployment model

Terms of a cloud service agreement will vary greatly depending on the deployment model – infrastructure as a service (IaaS), platform as a service (PaaS) or software as a service (SaaS) – and users should look for specific criteria in each.

With a public IaaS agreement, the service revolves around the provider offering IT infrastructure resources – such as compute, networking and storage – and then supporting and securing those resources. The user is responsible for most everything else, said Mike Edwards, cloud computing standards expert and Bluemix PaaS evangelist at IBM, and a CSCC member.

“Largely, the customer is … responsible for all the components that are going to run on that system – your applications, your data, the operating systems you may install, database software, whatever,” Edwards said during the webinar.

This means, in general, commitments made by the IaaS provider to a user will be somewhat limited.

With PaaS, users receive access to a hosted application platform and development services. When navigating a PaaS agreement, it can be difficult to determine which services are native to the PaaS environment, and which aren’t. For example, in most cases, a database service will be part of the fundamental PaaS offering. Other types of services that your application might access – such as those related to social media – might actually direct your apps to services outside the platform.

Of course, the commitments and expectations for services native to the PaaS offering will differ from those outside it. Users should ask their PaaS provider for a complete list or catalog to identify which services fall into which category.

Lastly, with SaaS, users have access to a “complete” application, with all the middleware, database, storage, compute and other associated components, Edwards said. In this case, the cloud agreement will be most extensive.

“All of these things are really the responsibility of the provider in a software-as-a-service environment,” he said.

However, if the SaaS application deals with personal data – such as a hosted HR application – make sure the privacy statements and data protection policies are clearly defined, as the user is still responsible for the protection of that data.

Negotiation options

When negotiating better terms in a cloud service agreement, there is generally less flexibility with a “bucket” cloud service, such as public IaaS, because the provider expects to give “one-size-fits-all” terms, Baudoin said.

Still, that doesn’t mean there’s no hope in scoring more favorable terms. In most cases, larger cloud users have the most negotiating power, but all cloud users could benefit in the long run.

“Smaller customers are not totally without recourse or help,” Baudoin said. “Over time, if a larger customer demands and obtains certain changes in the terms, that will trickle down to all the customers of this particular cloud service provider.”