Don`t Lose Control in the Cloud

By Philip D. Porter  |  Posted 2011-10-03

Cloud computing involves giving up direct oversight of technology assets, but it shouldn’t mean losing control.

The customer must rely on the service provider to restore operations when a cloud computing service malfunctions. Before entering into a cloud transaction, a prospective customer should evaluate the service provider’s obligations to ensure the availability and utility of the service, as well as determine the incentives the service provider has to meet those obligations. Areas to consider include service levels, availability, issue resolution, measurement and reporting, and performance incentives.

Service level is the customary term for a service-delivery obligation in a cloud computing transaction. Service levels for availability, error correction and user support are found in many cloud computing contracts, and the parties to every cloud computing transaction should consider whether any or all of these service levels are appropriate.

Not all cloud-based services are mission-critical. Service levels that are appropriate for a cloud-based service that is necessary for a customer’s ability to operate its business are different from service levels, if any, that may be appropriate for a cloud-based service on which a customer’s business continuity does not depend.

Another area to consider is availability, which refers to the percentage of time a cloud-based service is available for access and use by the customer. An availability service level of 99.5 percent is customary, and mission-critical cloud comput-ing services can carry service levels as high as 99.99 percent.

The percentage is calculated by subtracting the time during the measurement period when the cloud-based service is unavailable from the total time during the measurement period, dividing the result by the total time during the measurement period, then multiplying the result by 100.

Customers should evaluate a service provider’s proposed availability calculation by identifying the proposed measurement period, measurement unit and scheduled downtime allocation. The customary measurement period is a calendar month, and the customary measurement unit is minutes.

If the technology used to provide cloud-based services requires periodic maintenance, the calculation may specify maintenance windows (periods of time during which the service provider is entitled to suspend services without consequences. Such suspensions are called “scheduled downtime.”

A description of scheduled downtime might have two components: specified days and times for maintenance windows and—if the maintenance windows are longer than two to four hours on one or two days each week—the minimum advance notice a service provider must give for times within the maintenance windows during which the service will be unavailable.

Resolution and Support

Severity-level response obligations that are customary for technologies located at a customer’s premises are equally applicable to cloud-based services. They often describe the impact of service problems on customers at a minimum of three severity levels—serious, moderate or minor impact on customer operations—and prescribe the time within which the service provider must resolve issues at each severity level.

User-support service levels can include average and/or maximum times within which users receive responses to their support requests; the percentage of support requests that are resolved by the service provider’s initial response, and the percentage of support requests that are resolved within a specified period of time after the support request.

Prospective customers should also examine the service provider’s obligations to measure achievement of service-level obligations and report the results. Many service providers allocate to their customers the obligation to identify instances in which the service fails to achieve agreed-upon service levels. However, customers may not have the necessary tools and resources to measure the service provider’s performance.

A prospective customer might reasonably expect a service provider to measure its own performance of each service level and report the results by a specified date each month.

Performance Incentives

Customers should seek contract provisions that create meaningful incentives for the cloud service provider to meet agreed- upon service levels. The most common of these incentives are service credits, technology escrows and, for extreme circumstances, termination rights.

Service Credits: Service credits can take the form of amounts of money that customers could apply to subsequent payment obligations to a service provider, or refunds of amounts already paid to which a customer becomes entitled if service levels are not achieved. They typically do not exceed 20 percent of the total fees charged by the service provider. This at-risk amount is then allocated among the various service levels. Service credits are most effective when they reduce a service provider’s profits. They should not cause a service provider to incur operating losses that could force the vendor to cut its operating costs and impair its ability to deliver functional and reliable services.

When charges for services are payable monthly, customers should be entitled to apply service credits to payments for the following month. When payments are annual or service credits are attributable to service-level failures during the final month of a contract, the service provider should issue a refund in the amount of the service credits to which the customer is entitled.

Technology Escrows: Technology escrows are used most frequently in software as a service (SaaS) cloud computing transactions. These transactions require two separate escrow accounts—one for object code and another for source code, with overlapping, but not identical, events that trigger release of the deposit.

An escrow agreement for object code provides for release of the deposit to a customer in the event of a service provider bankruptcy, cessation of business, discontinuation of services or a specified failure by the service provider to meet an agreed-upon availability standard. Upon a release of the deposit, the customer can duplicate the cloud-based service in its own computing environment or in the computing environment of a third-party hosting-services provider.

An escrow agreement for source code provides for release of the deposit to a customer in the event of a service-provider bankruptcy, cessation of business, discontinuation of services or a specified failure by the service provider to meet an agreed-upon issue-resolution standard, which might be inability to resolve a single high-severity-level issue or repeated failures to resolve high- or moderate-severity issues in multiple consecutive months. Escrow provisions should be evaluated for enforceability under applicable bankruptcy laws.

Termination: Finally, if the service provider’s nonperformance of its obligations—including nonperformance attributable to a force majeure occurrence (an unforeseen event beyond the service provider’s control)—affects a customer’s operations so seriously that it must seek an alternative technology solution, a cloud computing agreement must permit the customer to terminate the agreement without a termination fee, with an entitlement to a pro rata refund of service fees that the customer has prepaid for any period following the effective date of such a termination, and without a cure period.

When offering or availing themselves of the often-substantial cost and scalability benefits of cloud computing services, service providers and customers must recognize that these services are delivered with technology assets that are neither in the customers’ possession nor under their control.

It is in the interest of both parties to structure contracts for these transactions in a manner that gives customers a reasonable expectation that the cloud-based services will be reliable. Each party to a cloud computing transaction is responsible for making sure that the agreement satisfies this interest.

Philip D. Porter is a partner in the Northern Virginia office of Hogan Lovells. He's a member of the firm's Intellectual Property Practice and leads the technology transactions and outsourcing practice groups in the United States.