International In-house Counsel Journal

Vol. 8, No. 30, Winter 2015, 1

International In-house Counsel Journal ISSN 1754-0607 print/ISSN 1754-0607 online

Understanding and Negotiating

Software as a Service (SaaS) Agreements

JUSTIN NELSEN

Vice President, Managing Assistant General Counsel, CA, Inc., dba CA

Technologies, USA

Introduction

Software as a Service or SaaS is an important and growing segment of the commercial

software market. Software as a Service can be viewed as a subcategory of the somewhat

nebulous but increasingly important market generally denoted as cloud computing or

cloud software. ‘The cloud software market reached $39.3 billion [US Dollars] in

revenue in 2013’ growing at annual rate of 22.6% and is projected to ‘grow to $102.9

billion [US Dollars] by 2018’ for a ‘compound annual growth rate (CAGR) of 21.3%’

according to a recent forecast by IDC.1 Projected growth rates around the world are

mixed2 but variances in terms of percentage changes, can be explained, to some degree,

by the law of large numbers (i.e. a large entity or marketplace which is growing rapidly

will be less likely to sustain such a growth rate whereas smaller ones are more likely to

be able to do so for a greater period of time). All of which is to say, if you have not

already negotiated and closed a SaaS or cloud deal, you are more than likely to do so very

soon.

This paper is authored with the hope that it will aid legal colleagues in the understanding,

negotiating, and closing of SaaS transactions, whether from a customer-user entity

perspective or from that of the service provider. It is written from an enterprise to

enterprise relationship perspective and does not comment on nor analyze issues

potentially arising out of consumer-oriented cloud services.

Section 1 of the paper will outline a brief history of distributed computing leading up to

modern software design and production that enabled today’s offerings; define cloud

computing generally and XaaS specifically, including an examination of the essential

elements of such offerings and their various deployment models. Section 1 will conclude

with the commonly perceived advantages arising out of such a distribution and use

model, as well as some of the financial and economic differences compared to traditional

on-premise software licensing.

1 Mahowald, R. and McGrath, B., Worldwide SaaS and Cloud Software 2014-2018 Forecast and 2013 Vendor

Shares, (July 2014) IDC Opinion #249834; See also generally, Brookings Institute Policy Forum: Cloud

Computing for Business and Society, comments of Microsoft General Counsel, Brad Smith, noting that the

survey commissioned by Microsoft and carried out by the research firm Penn, Shoen and Berland found “a full 86 percent of senior business decision makers are excited about the potential of cloud computing to

change the way they work and use technology”, transcript p. 13 available at

http://www.brookings.edu/~/media/events/2010/1/20%20cloud%20computing/20100120_cloud_computing.

pdf. 2 Mahowald, R. and McGrath, B, supra note 1 at 28 showing Latin America outpacing the projected growth

rates of the US (17.1%) and Canada (16.6%) at an incredible 52.2% CAGR; EMEA being fairly balanced with only slight regional deviations from the geography’s projected growth rate of 27.0% and Asia/Pacific

also having fairly homogeneous growth rates rolling up at a aggregate regional rate of 20.6%.

2 Justin Nelsen

Section 2 of the paper will highlight and comment upon the most difficult areas in SaaS

contracts which also serve as the largest impediments to user entity adoption. These

include security, privacy (including data location issues), service availability, defined in

Service Level Agreements (“SLAs”) and remedies for breach of same, as well as data

availability, both from a during and post subscription term perspective. The Section will

also examine data resiliency from a disaster recovery perspective. In all such areas, the

paper will attempt to highlight the basis of such provisions, be it risk allocation between

the parties, service provider data center operations, or legal or economic considerations,

and will also attempt to provide the rationale for possible on and off paper mitigation

strategies.

1. SaaS and Cloud Computing

This Section of the paper will attempt to orient the reader to today’s notion of cloud

computing generally, and Software as a Service specifically, by exploring the computing

history from which such offerings have evolved. It will provide a definition of the

broader construct of cloud computing as well as definitions for the specific subsets of

XaaS (i.e. IaaS, PaaS and SaaS). In addition, this Section will outline the essential

elements of an SaaS offering, including deployment models, and highlight the potential

advantages of SaaS when compared to a traditional on-premise licensing. Finally, the

Section will conclude with a brief description of the financial and business models of an

SaaS distribution model versus an on-premise model where the user entity is responsible

for deploying inside the enterprise, in an attempt to highlight some of the

economic/financial realities and consequent pressure around certain terms and conditions.

I. A Brief History

Examples of compute resource sharing to lower the cost of consumption of such

resources can be seen in the 1960s and 1970s when the notion of timesharing began to

emerge in the marketplace. The offerings were also known as Service Bureau offerings,

where a user essentially rented processing time on a computer (usually IBM) and

submitted either data and/or programs via punch cards and later via more ‘user friendly’

input and output means, such as dumb terminals connected via very slow modems.3 The

notion of timesharing continued throughout the 60s-70s with more and more operating

systems enabling the use model but was ultimately displaced by the availability of

smaller and cheaper hardware. This continues to advance today in terms of computational

power in accordance with Moore’s Law.4 The lower acquisition costs allowed more and

3 Bemer, R., How to Consider a Computer, Data Control Section, Automatic Control Magazine, 66-69 (March

1957) re-printed at www.bobbemer.com/TIMESHAR.HTM (Origins of Timesharing) (noting that the cost

function of large computers and the difficulty for user enterprises to justify the purchase of such a machine if

their effective utilization rates were expected to be low and that timesharing could eliminate the financial disincentive to use such a large, expensive computer by homogenizing the use and “allowing a smaller

[enterprise] and more numerous class of user[s]” greatly expanding the addressable market for computer vendors of larger machines such as IBM).

4 Moore’s Law is an observation or prediction that Intel Co-Founder Gordon E. Moore first made in paper

published in 1965, essentially predicting that the processing power of computers would double every two

years (it is actually couched in terms of transistors per circuit board, but essentially equates to the processing power proposition). Moore, G. Moore’s Law at 40, Chapter 7 of Understanding Moore’s Law, republished at

http://www.chemheritage.org/Downloads/Publications/Books/Understanding-Moores-Law/Understanding-

Moores-Law_Chapter-07.pdf. Moore’s law has indeed held true, although the current cycle time to double processing power is 18 months, nonetheless, the world has benefited from the dramatic increase in compute

power per unit of cost and will continue to do so for some appreciable period, although, experts agree at

some point it will no longer be obtainable. Id. See also http://www.mooreslaw.org/ (for a more lay person- friendly write-up).

Software as a Service (SaaS) Agreements 3

more entities to bring computing in-house and essentially ended the possibility of large

commercial markets around timesharing. The next phase of market activity, which can be

seen as a predecessor to today’s cloud markets, was the ASP or application service

provider phase which was ushered in with a great amount of enthusiasm even if they

were light on actual business plans or new value propositions. Essentially, ASPs were

hosted instances of any type of application or service the provider may offer. ASPs

differed from timesharing in that timesharing allowed users to rent computing resources

who generally created their own programs and then executed them on the timeshared

machines, while ASPs were essentially renting use of their software to users over the

Internet. While the concept created great interest and almost every vendor claimed to be

some sort of ASP, the economics and value add pieces were generally fuzzy at best.5 The

promise of true cloud software lies not only in the cheaper compute power and

virtualization pieces6 but, more specifically, in a new software architecture scheme

generally known as multi-tenancy.7 When modern software is written for consumption

over the Internet it accounts for several things, including multi-tenancy, which generally

means that all users of the service are running the same instance of the software as well

as more and more extensible options for user preferences at implementation. This again

allows for the same instance of the software to be shared across different user entities but

also allows for ‘customization’8 based on use cases and preferences.

II. Cloud Computing Defined

One of the confusing pieces for anyone looking at a cloud offering is the lack of

consistent use of the term in the market. The United States National Institute of Standards

and Technology (NIST), however, does provide a good definition practitioners can apply

across the globe for categorizing a particular service. This can have the effect of enabling

a consistent taxonomy and hence perspective when evaluating potential risks inherent in

such offerings. NIST defines cloud computing as:

[A] model for enabling ubiquitous, convenient, on-demand network access to a

shared pool of configurable computing resources (e.g., networks, servers, storage,

applications, and services) that can be rapidly provisioned and released with

minimal management effort or service provider interaction.

--NIST Special Publication 800-145 (Sept. 2011).

III. Essential Elements of a Cloud Offering and XaaS Definitions

The NIST definition goes on to articulate the five essential characteristics of a cloud

offering: (i) on-demand self-service; (ii) broad network access; (iii) resource pooling; (iv)

rapid elasticity; and (v) measured service. These roughly mean that to be considered a

5 Bianchi, A., Upstarts: ASPs, Say good-bye to software as we know it and hello to ASP start-ups, Inc.com, last

updated Apr. 1, 2000) (“More than 300 vendors claim to be an ASP—each offering a different story and solution … It’s no wonder users are confused and skeptical”)(quoting a Forrester Research Report) available

at http://www.inc.com/magazine/20000401/18093.html. 6 See Section 1.VI. infra.

7 See Kabbedijk, J., et al., Defining Multi-Tenancy: A Systemic Mapping Study on the Academic and the

Industrial Perspective, Pre-Print of submission to Journal of Software and Systems (Oct. 16, 2014)

(surveying definitions used in industry to properly characterize and more fully define the term and its import

on both academia and industry). 8 Extensible code merely means the ‘customizations’ are built into the code base itself and allows election and

configuration of the code at time of set-up and execution rather than the notion of writing new code and

modifying the underlying code base for a customization as may be the case for non-modern code running on-premise.

4 Justin Nelsen

cloud offering the user entity should be capable of unilaterally provisioning the service

over the internet (without a ‘heavy’ client—i.e. industry standard browsers and devices)

accessing a multi-tenant service which by definition pools the service providers resources

for serving all subscribers and allows a user entity to rapidly scale up or down in use rates

while such use is measured and billed, akin to a utility.9 While it is true that a cloud

offering may well meet all of these criteria, it is equally, and perhaps more true, that

given the state of the industry they are increasingly likely to be met the further down the

stack you go. An Infrastructure as a Service (IaaS) offering, where the user entity

controls the software stack from the operating system through any application layer, is

most likely to have all five elements in place. Moving to a Platform as a Service (PaaS)

offering, where the service provider is responsible for the stack through the operating

system and the user entity controls the application layer, one or more elements may not

be present. Finally, for the Software as a Service offering where the provider controls the

entire stack through the application layer, it is unlikely that all five elements will be

present, at least in the form articulated above. For example, many SaaS offerings are not

today truly self-service10

but do meet the other criteria as the services are accessible from

standard clients on the network utilizing a single instance of the software for many

different user entities (multi-tenant). These allow for varying degrees of elasticity and are

generally measured or metered service offerings. In other words, while the essential

elements are helpful, in practice, when evaluating a particular offering, some flexibility in

interpretation and application is required. In addition, it is also helpful to use the level of

user control as a guide to whether the offering is an IaaS (user entity has control of stack

from the OS) PaaS (user entity has control of stack at the OS level) or SaaS (user entity

may merely use the application and possibly has control over certain configuration

settings).

IV. Cloud Deployment Models

The spectrum of cloud deployment models spans many solutions from something

considered a private cloud— created for the exclusive use of the entity’s user group and

usually inside the entity’s firewall — to a public cloud. The latter, as it name implies, is

for open use over the Internet, clearly outside any entity’s user group’s firewall.11

Between these two extremes NIST identifies both a community cloud, an infrastructure

provisioned for a group of like-minded user entities (such as an electronic payments

cloud where the nature of the data exchanged gives rise to a common need for security

requirements for all users), and hybrid clouds which are created by some combination of

two or more of the other categories.12

V. Potential Advantages of SaaS over On Premise Software

The potential advantages of an SaaS offering over licensing software for on-premise

deployment can be examined by looking at benefits in the short and long term. Today,

while the market is still in its relatively early stages with some SaaS offerings written

under older software architecture and hence incapable of benefiting from the economies

of scale offered by modern architecture and deployment, the benefits flow primarily from

9 NIST Special Publication 800-145 at 3 (Sept 2011).

10 See Mahowald, Note 1 at 5 (“In the IT cloud services world, the range of self-service provisioning and

administration vary widely up and down the stack: in the infrastructure as a service area (e.g., cloud storage,

cloud servers), “click to buy” provision is widely available today, whereas much of the SaaS and PaaS

community lags…”). 11

NIST Special Publication 800-145 at 3 (Sept 2011). 12

Id.

Software as a Service (SaaS) Agreements 5

the new distribution model. From the user entity perspective, potential advantages flow

from relieving the IT department or outsourcer from the burden of maintaining the

software, including the entire hardware and software stack it sits on — not an

insubstantial burden when you consider the servers, networking, storage, operating

system and middleware, let alone running in test, staging and finally production

environments. There are also savings with regard to the operational costs of running the

data center, in addition to real estate costs, power, for both operating the dense servers of

today and networking and storage gear as well as the energy required for cooling and

environmental controls. The latter is estimated in the United States to have consumed 91

billion kilowatt hours of electricity in 2013 —roughly the full output of 34 large coal

fired power plants.13

By 2020 it is estimated that US data centers will consume 140

billion kilowatt-hours of electricity annually at an estimated financial cost of $13 billion

US Dollars.14

There are a host of variables giving rise to these numbers, however, one

inefficiency and hence high cost, which a modern cloud offering can improve, is server

utilization.15

Potential advantages, apart from cost reduction include improvements in

reliability and performance, including extremely rapid deployment compared to on-

premise scenarios. In addition, device and location independence is also often cited as an

advantage, given that all that is required for consumption of the services is an Internet

connected device running a standard browser, a necessary feature when supporting

mobility in the workforce. Finally, security is often touted as an additional benefit —

which clearly has a cost side function — but what is implied by commentators is that

quality will generally be improved.16

From a longer time horizon, the advantages include the above but also the possible

provision of new and composite services previously impossible to deliver due to the

disparate systems on which the component services were operated, as well as the lack of

communication and data passing protocols for the service-to-service connections

necessary for such composite services and applications. These include creative new

services simply not possible when running the software as an isolated instance inside the

enterprise’s firewall, and may include areas such as fraud detection and other applications

for big data analytics and modeling.

VI. SaaS versus On-Premise: Financial/Business Model Comparison

It should be clear from the previous section that the cost function for a SaaS provider is

significantly different to that of a traditional on-premise software licensor. Generally, the

marginal cost (the change in total cost arising out of an additional unit produced)

associated with each additional copy of on-premise software is zero. This does not take

into account the costs associated with updates and upgrades, but for the version that is

generally available the marginal cost with each subsequent sale is zero. SaaS providers

will incur all of the same production costs for engineering the underlying product but will

also incur significant operational and marginal costs, albeit a step function. For the SaaS

provider, costs will rise in a stepped manner, increasing significantly as new IT assets and

personnel are required to run the service when operational capacity nears its limits. A

simplified example might be that a SaaS provider may be able to utilize one server and

two IT professionals for every 2,500 users, so the marginal cost of user 1-2,500 (ignoring

13

Natural Resources Defense Council Issue Paper, Data Center Efficiency Assessment, 5 (Aug. 2014). 14

Id. (noting such energy use will cause approximately 150 million metric tons of carbon pollution annually). 15

Id. at 13 (noting “[s]tudies show that average server utilization remained static at 12 to 18 percent between

2006 and 2012” which is to say, they are underutilized 82%-88% of the time). 16

See Section 2.1 infra for a more detailed analysis of security in the SaaS setting.

6 Justin Nelsen

adequate capacity planning for the moment) is the same but rises significantly with user

2,501. (In this case it doubles as another server and two additional IT professionals will

be needed). The salient point is that a service provider has real sunk costs and a stepped

marginal cost function — meaning, all other things being equal, a lower profit rate. In

addition, from a cash flow perspective, the payment streams are markedly different. On-

premise software licenses are generally sold as a one-time upfront fee whereas SaaS

subscriptions are sold and billed based on a mutually agreeable periodicity (e.g. monthly,

quarterly, annually) spread out over the term (e.g. two years). In other words, the SaaS

provider must wait until it has received enough payments over the term to cover the costs

associated with a customer to start earning a profit. From a financial perspective, it is this

time lag that causes the delay in profitability. The effects of the time lag are magnified

when a SaaS provider is building its business and is adding new user entities at a much

greater rate compared with the renewal activities of existing users. Examples of the

difficulty such a pricing and payment stream arrangement places on the service providers

is readily apparent in the market today.17

The pressure on profits and the real costs

associated with certain provisions in agreements creates great difficulties for SaaS

providers when prospective customers request terms which either work against the

economies of scale on which the business model is built (e.g. anything that would require

a move from a multi-tenant instance to a single user entity instance) or which drive

incremental costs (e.g. adhering to a new audit standard).

2. SaaS Contractual Big Issues

I. Security

Security concerns have been and remain viewed as the largest inhibitor to cloud

adoption.18

Although there is a marked difference between those who have ventured into

the cloud (those who are “cloud-wise”) and those who have not yet done so, with a far

greater level of concern from those considering initial adoption.19

Of course, security and

appropriate levels of precaution are context driven. In some circumstances, the nature of

the offering may not require much more than simple controls. One example is an

application or web site monitoring tool that allows a user entity to monitor the

performance of a particular path through or action on their web site using synthetic (or

fictitious) transactions using a scripting tool with user accounts and passwords they

17

A great example of this is Salesforce.com. For fiscal year 2014, Salesforce.com reported revenues from

subscriptions of almost $4 billion US Dollars ($3.8 billion) but reported a loss from operations of more than

$286 million US Dollars. Such a loss more than doubled from the year earlier (FY13 reported loss from operations was $110 million US Dollars), but, not surprising their revenue grew at a significant rate as well

(FY13 subscription revenue was almost $1 billion US Dollars lower than FY14), showing the difficulty of

cash flow and profitability during the growth stages of an offering. See Salesforce.com, inc.’s consolidated statements of operations as reported in its fiscal year 2014 annual report available at

http://investor.salesforce.com/files/doc_financials/2014/AnnualReport.pdf ; See also Wolde, H, SAP sees

lower margins for years to come as cloud transition bites, 1 (“Europe’s largest software group SAP SE had cut profit forecasts and abandoned a target for higher margins, saying its stepped-up push to deliver products

via the cloud would dampen profitability until at least 2018”) (Jan. 20, 2015) available at

http://www.reuters.com/article/2015/01/20/us-sap-results-idUSK BN0KT0DN20150120. 18

Mahowald, R and McGrath, B, supra Note 1 (“IDC research shows that, by far, the greatest inhibitors to

public cloud adoption are the perceptions of security/privacy concerns…”) at 31; See also, Vijayan, J., Cloud

Security Concerns are Overblown, Experts Say, 1 (“Today, though, security concerns are still the major

inhibitor of cloud adoption at many large companies. The concerns are most significant among those IT

executives considering a cloud migration.”) (Feb. 27, 2014). 19

Vijayan, supra Note 17 (“An Intermap survey of 250 decision makers at medium and large companies found

that 40% of those who described themselves as "cloud-wary" cited security as their biggest impediment to adoption. In contrast only about 15% of "cloud-wise" respondents felt the same way”).

Software as a Service (SaaS) Agreements 7

control. This requires very little other than perhaps protection of the user name and

passwords, but this level of rigor would be the same whether the service is consumed

over the cloud or on-premise and is entirely in the control of the user entity. Properly

viewed, in this context, the security procedures of the provider need not be burdensome

and any desire to force such an approach by a user entity would surely require, assuming

for purposes of illustration such an approach was mutually agreeable, a significant

change in pricing. The problem, however, is that in the real world, the cost of the more

stringent security controls would need to be passed on to every current and prospective

user of the service — something that is just not commercially feasible. Similarly, an

electronic payments system requires, at a minimum, that the provider design and carry

out security policies and procedures that meet the rigorous requirements of the Payment

Card Industry Data Security Standards. This is a comprehensive set of requirements

spanning more than fifty (50) pages and espousing guidelines across twelve different

areas of control.20

In other words, the appropriate level of security requirements is a

function of the data types that the user entity inputs and the level of processing and

storage the provider’s service entails.

Due to the loss of control a user entity feels when moving to the cloud for the first time,

such entity users will often try and “take back” such control by asking (often expressed as

a requirement) the service provider to sign up to the user entity’s security policies and

procedures. Although this gives the user entity the feeling that they have indeed now

discharged their obligations with regard to the appropriate level of security for the

offering at hand, such an approach is entirely misguided. First, the security procedures

are almost always a set of corporate-wide generic requirements as opposed to those of the

service provider which should be tailored policies and procedures based on the nature of

the offering. Second, most, if not all, of such user security policies specify fixed

standards (e.g. all data sent over the internet must be sent using SSL as the encryption

protocol) and do not allow for the service provider to move with the evolving standards

(e.g. use of TLS in this scenario). This type of static and overly broad provision points up

the misuse of a general corporate-wide security policy and procedure for a particular

point service to which the user entity would like to subscribe. Finally, even if the user

entity took the time to understand the offering and the underlying infrastructure in order

to enable a tailored security policy, “where multiple users share standardized

infrastructure, it would be difficult, if not impossible, for providers to comply with all

users’ separate security policies, with possibly different, even conflicting,

requirements.”21

Frequently, once the impossibility of implementing different security

guidelines is understood and acknowledged, the new cloud user entity will likely ask to

review the security policies of the service provider, in an effort to find a level of comfort

once the qualified individuals at the potential user entity complete a review.

Unfortunately, the required response of the service provider does very little to quell

concerns and may actually make them more acute: “we cannot provide our policy as it is

confidential and not shared with customers or prospective customers.” This is not

necessarily because the service provider is trying to hide or cover up a lackluster security

policy, rather “provider[s] generally consider[] that, particularly with shared

infrastructure and multi-tenancy, it would be detrimental to security and against their own

20

Available at: https://www.pcisecuritystandards.org/security_standards/. 21

Hon, W., Millard, C, and Walden, I, Negotiating Cloud Contracts: Looking at Clouds from Both Sides Now,

16 Stan. Tech. L. Rev. 81, 111 (Fall 2012) (conducting and reporting out on their qualitative research into negotiated cloud contracts).

8 Justin Nelsen

security policies to provide full details of their security policies and practices…”22

Assuming the now paranoid user entity does not abandon the effort, what can they hope

to see from the service provider to allay their concerns? The answer is an audit report.

Specifically, they require an audit report by a reputable auditor which has been conducted

in the last twelve (12) months to a recognized auditing standard.23

Most providers will be

happy to provide the attestation of compliance from the auditor, usually a short document

setting out the nature of the engagement and the findings of the audit. Depending on the

nature of the data and the degree of risk aversion the user entity has, this may or may not

be enough. The next logical request from those user entities needing more is for the full

report. A provider’s willingness to provide the full report will be dependent on how

sensitive they are to security issues as well, and perhaps more importantly, how detailed

and specific the auditor is in describing each of the controls tested. At one end of the

spectrum, for example, under a SOC 1 report, a provider may well be comfortable

providing the report under an NDA. At the other end of the spectrum, a PCI DSS audit

may simply have too much detail and the nature of the security issues and requirements

may be simply too great to allow the report to be divulged, generally only allowing, as a

possible compromise, the entity user ‘to view[] hard copies in closed rooms, with no

ability to make copies.’24

Finally, from time to time, user entities desire either to see the

results of penetration tests or to conduct them themselves. Both requests are problematic,

the first in that the results may expose vulnerabilities, and the second because the same

exposures may also have ‘potential adverse impact [and potential privacy issues] on other

users’ services or data.’25

II. Privacy

Closely related to security, and an obvious benefactor if administered correctly, is

privacy. Not surprisingly, privacy closely follows security as one of the top inhibitors to

cloud adoption.26

In addition to security providing the means by which the data is kept

confidential and unadulterated, privacy has its own set of requirements, primarily driven

by statutes,27

regulations28

and enforcement agency actions.29

In addition, currently

22

Id at 110. 23

The current standard promulgated by the American Institute of Certified Public Accountants and the

successor to the SAS 70 audit is the SSAE (Statement on Standards for Attestation Engagements) No. 16

(Reporting on Controls at a Service Organization) or SSAE 16. SSAE 16 audits are engaged under three varying standards on controls (e.g., SOC 1, SOC 2, and SOC 3). For a summary of the three engagement

types, see www.aicpa.org/interestareas/.../comparision%20of%20soc%201-3.doc . The Payment Card

Industry has qualified security assessors for conducting an audit under the PCI DSS, see https://www.pcisecuritystandards.org/approved_companies_providers/qualified_security_assessors.php.

24 Supra Note 20 at 110.

25 Id. at 113.

26 See Mahowald, R and McGrath, B, supra Note 1 at 31; See also, Cloud Industry Forum, Cloud UK: Paper

One Adoption and Trends 2011 (2011) (finding 55% of enterprise decision makers polled cited privacy as their biggest concern in cloud adoption and 62% citing security) available at

http://cloudindustryforum.org/downloads/whitepapers/cif-white-paper-1-2011-cloud-uk-adoption-and-trends.pdf

27 See Health Insurance Portability and Accountability Act of 1996, Pub. L. No. 104-191, § 110 Stat. 1936

(1996); Health Information Technology for Economic and Clinical Health Act, Title XIII of Division A and

Title IV of Division B of the American Recovery and Reinvestment Act of 2009, Pub. L. No. 111-5, § 123 Stat. 226, 246 (2009); Gramm-Leach-Bliley Act of 1999, Pub. L. No. 106-102, 113 Stat. 1338 (1999).

28 See Securities and Exchange Commission Regulation S-P at 17 CFR Part 248 (2000).

29 See http://www.ftc.gov/news-events/press-releases/2012/08/google-will-pay-225-million-settle-ftc-charges-

it-misrepresented (announcing record settlement with Google for $22.5 million US Dollars for deceiving users with regard to tracking internet usage when on Apple’s Safari browser).

Software as a Service (SaaS) Agreements 9

proposed laws and regulations around the world30

as well as the European Union Data

Protection Directive31

prescribe data location requirements. Consequently, more and

more service providers are customizing their terms and conditions for service offerings

which are regulated based on data types, as well as specifying the location where all data

will be processed and stored during the service. Outside the scope of this paper are the

fundamental rubrics and doctrines of privacy law and their application or lack thereof to

cloud computing. Such questions are important to society and to the individuals that

engage in cloud based activities, however, they are mostly theoretical at this point and

more focused on the individual’s rights as opposed to the duties of the organizations they

belong to and who may conduct business in the cloud. One of the events which falls both

within security and privacy is a security breach that exposes regulated personal

information giving rise to various notification requirements, and sometimes credit

monitoring duties for the affected persons. Many service providers offer some level of

notification in the event of such a security breach and generally, despite what is written

contractually, cannot, as a matter of public policy, alter the notification requirements of

the governing laws. Accordingly, provisions that are generally applicable, such as

compliance with laws, can be deemed to require notice within the required period of time.

However, when the relationship is enterprise to enterprise with the user entity providing

its customer data to the service provider, a higher level of cooperation is generally

expected including the coordination of any announcement of any data breach involving

personally identifiable information (PII), although often times the agreements are silent

on such post breach cooperation. In addition, most security breach provisions are drafted

from the perspective of the service provider, providing notice to the user entity whose

customer base may have been affected. Composite applications and services, especially

big data analytical services will (and are) posing big questions in terms of consumer

notice and use of data but are outside the scope of this paper.

III. Service Level Availability and Remedies for Breach

Service or application performance in addition to security and privacy, as noted above,

continues to serve as a major inhibitor to cloud adoption.32

Standard contracts generally

define service level availability targets as the amount of actual uptime divided by the total

possible uptime minus planned downtime or (Actual Service Availability / (Total Uptime

Availability – Planned Downtime)). For example, if the service were measured on a

monthly33

basis and the service provider states that planned downtime34

will be two hours

30

See Russian Federal Law 242-FZ which requires that all personal data pertaining to Russian citizens be

stored in the country, compliance is required as of September 1, 2016; see also, Public Notice from the

Office for Nigerian Content Development (ONC) "Public Notice on the Coming into Effect and the

Enforcement of the 'Guidelines for Nigerian Content Development in ICT'" that states that the Guidelines “require local hosting and storage of subscriber and consumer data within 18 months of the Guidelines

effective date)”. Additionally, the notice states that a breach of the Guidelines could result in a criminal

offense under Sections 17 (4) and 18 of the National Information Technology Agency Act of 2007. 31

Council Directive 95/46/EC, on the Protection of Individuals with Regard to the Processing of Personal Data

and on the Free Movement of such Data, 1995 O.J. (L 281) 31. 32

Supra Mahowald, R and McGrath, B, supra Note 1 (“IDC research shows that, by far, the greatest inhibitors

to public cloud adoption are the perceptions of security/privacy concerns and performance/availability

concerns”) at 31. 33

The unit of measurement varies greatly by offering and by service provider. Some offerings are measured at

the minute mark while others, depending on the nature of the services and their suitability for measurement, may be measured by scripts or monitors that continuously monitor in various time increments. In addition, it

should be noted that such a calculation is really mostly applicable to overall end-state service availability. It

is possible to have multiple SLAs measuring not only total application uptime but various components therein as well as data speeds and latency of the system or various components which impact user

10 Justin Nelsen

each week or 8 hours in total, then for a 30 day month the actual service level is

measured and then divided by 712.35

Service level availability targets are generally

expressed as a percentage of total availability, such as 99.5, 99.9,36

99.99, 99.999 and so

on. For a monthly service availability of 99.5 and assuming the numbers above for

planned downtime,37

when expressed on a minute rather than hourly basis, total possible

application unavailability would equate to 194 minutes a month. Moving the service

availability to 99.9 would reduce the total monthly unplanned downtime to 43 minutes or

about 10 minutes a week on average whereas 99.999 would allow for just 26 seconds of

unplanned downtime a month. Obviously, achieving higher and higher rates of

availability increases costs (and diminishes return on investment) for the provider and

hence higher prices for the user entities. When a service provider is designing an offering

it must take into account, amongst other things, the use cases it will address, the likely

value and price it will be able to charge for the service, as well as the costs of

infrastructure and data center operations in establishing the availability rate for the

service. When a service provider is running multi-tenant software, it cannot add

resources, redundancies and the like to bolster its service availability for a single

customer—all customers are running the same instance of the software across a shared

infrastructure. While it is technically true that the service provider could run an instance

for a single customer, it breaks the cost equation and accordingly, when re-priced for

such a use case, most likely also exceeds the reservation price38

of the prospective

customer. Accordingly, service availability rates can be seen as designed into the service

and are critical to the price and cost of delivery—all of which is to say, availability rates

are generally a description of the offering rather than a term to be negotiated. As noted

above, profit margins are low and require some period of earn out to cross over from

negative to positive profit margins. Consequently, if a service provider were to negotiate

and agree to higher availability rates, their viability over the long term may come into

question.

While force majeure events are excluded from downtime calculations, a service designed

for resilience will have a disaster recovery plan. Depending on the service and service

provider, the service provider may offer a recovery time objective (RTO) which

expresses the targeted total amount of downtime or service unavailability in the event of a

force majeure event. Recovery time objectives can be stated in any level of granularity,

from mission critical functions requiring a recovery time objective measured in minutes

to enterprise applications measured in hours and non-critical services measured in days or

experience. The level of granularity of SLAs will most likely grow as markets for various services begin to commoditize, which is to say services which do not offer competitive differentiation and compete on price

and pure performance. 34

Planned downtime is generally for planned maintenance and is often according to a pre-planned maintenance

release and upgrade schedule which can be published monthly, quarterly or annually by the service provider

but rarely forms a part of the contract and can usually be changed with reasonable advance notice. 35

Thirty days are multiplied by 24 hours (720 hours) and the downtime subtracted (720-8) = 712 hours. 36

Informally, availability expressed as 99.9 and above are often times referred to by the number of nines, or in

the case of 99.9 three nines, 99.99 four nines, and so on. 37

Planned downtime is actually overly simplistic as all excused downtime will be subtracted from the

denominator. Common exclusions are client controlled variables, such as customer network, domain name,

or software issues (such as outdated and unsupported browsers), use not in accordance with the

documentation, including custom scripting, internet outages and force majeure events (more on force

majeure in the next paragraph). 38

In microeconomics this is the highest price a customer will pay before walking away from a proposed

transaction.

Software as a Service (SaaS) Agreements 11

simply not measured at all. For example, if a service provider states that the service in

question has a RTO of 24 hours, it simply means that the target for the maximum period a

user entity will be without the use of the service is 24 hours. Of course, the event itself

may make such a target unobtainable even if the service delivery has moved from the

data center affected by the force majeure event to one which is not. This could be due to

other dependencies, such as Internet connectivity, which may be unavailable for a

duration longer than 24 hours.39

Once SLAs are established and the metrics and measurement methodologies are

understood by the parties, the next question is what happens if an availability target is not

met. There are a host of answers in the marketplace, including provision for some

threshold which must be met in order for any remedy to be possible, essentially moving

the availability rate to whatever such a threshold may be (e.g. 99.9% target but remedies

are only available once availability falls below 99.5% measured over a month). Unlike

the tools for measurement and the availability rates themselves, remedies are largely a

commercial term of the transaction. For sure, they impact and are greatly influenced by

the cost structure in which a service provider operates, but variations between customers

are possible, assuming back-end systems support such variations. (In other words that the

service provider can actually administer variances in availability remedies across its

customer base). The industry standard remedy offered is a service level credit for use

against either a renewal term or a payment obligation in the current on-going term of the

service. The level of the credit varies widely, but may appear, at first glance, to be quite

low. The economic and financial reality, however, requires credits to be more or less

proportional to the period of downtime. For example, if a user entity is paying $1,000 for

a monthly service with 100% uptime, and the service provider’s actual uptime for a

month is 99.99% the loss of use expressed as the price it paid for services which were

never delivered is simply one-one hundredths of a percent or (.01%) or (.0001 x $1,000)

= $0.10. Of course, from the user entity perspective, a mere refund of the price of the

service not received is generally not the measure they are interested in. It is the idle time

and purported opportunity cost of not being able to use the service, in addition to the

price paid for services not received, that is of interest. Accordingly, most providers’

expression of credits is something much greater than such a pure refund calculation. In

addition, providers may offer, either as further remedy to credits, or as the sole and

exclusive remedy, the right to terminate the service for failure to meet an SLA

requirement. However these rights are rarely triggered by a single miss of any SLA

requirement but generally require some string of failures over a period of time. From the

provider’s perspective, these are reasonable and required as the delay in profitability

creates real financial (including cash flow) risks if customers are allowed to exit the

relationship too easily. From a user entity’s perspective, the remedies are generally in-

line with the sunk costs, including deployment costs, they face, which are generally $0.

This is due in part to the rapid deployment of SaaS compared to on-premise solutions

making the termination right more meaningful because user entities can generally bring

up a service from an alternative provider very quickly. The avoidance of large front end

lump sum payments and other sunk costs associated with deploying an on-premise

solution must also be considered when evaluating the reasonableness of the SLA

remedies on offer.

39

For example, hurricane Sandy caused twice as many internet outages as normal when the hurricane came on

shore in the Northeastern United States (See

http://www.upi.com/Science_News/Technology/2012/12/18/Hurricane-Sandy-doubled-Internet-outages/UPI-43241355864062/. )

12 Justin Nelsen

IV. Data Availability

Data availability should be considered both during and post subscription term. Generally,

data availability during the term is the same as the availability of the service itself, unless

the two are separated by design and have specific SLAs, something that is currently rare

in the industry. Accordingly, during the term, access to data will be governed by the

applicable SLA. An exception to this is the occurrence of a force majeure event, in which

case, the concept of a recovery point objective (RPO), if defined as part of the service,

will be invoked. A recovery point objective states the maximum amount of data which

can be lost but is not expressed in terms of storage units, rather it is expressed in time

units. For example, if a service offering backs up its data every evening to another

somewhat remotely located data center, it is likely that the service provider will provide

an RPO of 24 hours. This is the maximum amount of data that can be lost if a force

majeure event causes the data center providing the service to shut down. If the data back-

up is performed at 11:50pm every evening and the force majeure event occurs at 12:50am

the next day (assuming near instantaneous data transfer and assuming 24x7 use of the

service and hence data creation) then the likely data loss is limited to the information

input, processed and stored during the hour since the last back up. Move to the other end

of the spectrum, with the force majeure event rendering the production data center out of

commission at 11:49pm, then all data input, processed and stored during the last 23 hours

and 59 minutes would be lost. In either circumstance, whatever the amount of data not

backed-up to the remote site, it is important to note the limits on what the service

provider can offer, technically, as a remedy. As the data is input by the user entity’s

authorized user group (which may be employees, customers, customers of customers and

so on) the provider is simply incapable of re-entering whatever such authorized user

group entered in every circumstance.40

All of which is to say, because the data entered by

the authorized users will be unique to their interaction with the systems or services in

question, there simply is no record that a service provider could utilize to manually or

otherwise re-enter the data. Accordingly, remedies which are limited to the restoration of

the data from the last or most recent archival point reflect a simple operational constraint

rather than a hard-nosed position taken by a service provider.

Post subscription term data availability is equally a function of data center operations.

Generally, service providers allow for data extraction or for copies of production data to

be made according to the features and functionality of the applicable service, during the

subscription term. Once the term is over, all account access is turned off and data may no

longer be retrieved by the user entity unless special arrangements are made. In addition,

and more importantly, service providers regularly scrub their production data. While

account access will be disabled on expiration of the subscription term, the service

provider will retain a copy of the data until the next production data purge cycle. This

varies by service provider and sometimes by offering. Either way, it is unreasonable for a

user entity to allow a subscription term to end without first obtaining a copy of all

necessary data or ensuring arrangements are made to obtain same post term. In addition,

some service providers may agree to a statement of work for the transfer of data, and

perhaps configuration information, to enable an on-premise migration or migration to

another service provider. Transition services are generally not part of a standard offering

and, as the discussion on marginal costs and profits highlights, they cannot be provided

without additional fees, unless a service provider is willing to sacrifice the benefit of the

40

An exception may be where the authorized users were simply performing data entry from paper or other

stored records that were saved after the data were entered, although such use of a cloud offering by an enterprise seems rare.

Software as a Service (SaaS) Agreements 13

negotiated price and to erode margins. This seems unlikely when the user entity is

migrating off the service in question.

***

Justin Nelsen is Vice President, Managing Assistant General Counsel of CA, Inc.,

dba CA Technologies, USA

JD, University of Iowa, 1996 conferred with Distinction

BA in Economics, Hobart College, 1989 conferred with High Honors in Ecomomics

Articles Editor, Journal of Corporation Law

Many publishing and speaking engagements, including: Protecting IP in Commercial

Agreements, American Corporate Counsel Annual Meeting (2011); Antitrust Issues

Arising Out of Licensing Transactions, CLE Presentation to Wisconsin Bar IP Section

(2003); ANTITRUST STATUTES AND PROCEDURES, co-author, Health Care

Chapter (ABA Treatise) (2nd ed.1999); Antitrust: Market Delineation in Health Care

Cases, THE HEALTH LAWYER (1997); Antitrust: Market Delineation in Health Care

Cases, THE HEALTH LAWYER (1997); Delineation of the Proper Geographic Market

in Antitrust Cases Involving Physician Services, 16 JOURNAL OF LAW AND

COMMERCE 1 (1996);

Adjunct Professor, University of Colorado School of Law, Tech Lawyer Accelerator

Summer Program (2014); and Technology Transactions Fall 2014.

AGC at Oracle and Sun Microsystems, Inc., and private practice for four years prior.

CA Technologies is a multinational software company.