Let’s say you’re considering deploying or moving one or more applications – maybe mission-critical applications – to the cloud. Compared with an on-premise deployment, what legal risks, regulatory compliance issues and related concerns are new or different?
Recalling SaaS, ASPs and Service Bureaus
To answer that question, let’s begin by rolling back the clock on “cloud computing” and ask what that term really means. Recall software as a service, application service providers and service bureaus. Thirty-five years ago, one court defined a service bureau as “an organization that leases or sells the computer time, manpower, or other computational support to the public.” Fast forward to the 1990s when, with the broad availability of the Internet, ASPs entered the jargon of the technology world.
I remember working on my first ASP deal in 2000, in the context of a joint venture in the travel/technology space. At that time, it was still a mystery to most as to how to best distinguish an ASP from a service bureau. Was delivery of the software application through the Internet one of the key differentiators? Yes. Did the ASP offering effectively provide for no customization for the end user/customer? Yes. Beyond that, things got murky. The business service provider model soon followed the ASP model and then disappeared, virtually overnight. Then emerged SaaS. Cloud computing followed, and, while cloud computing technically encompasses more than SaaS (as it includes infrastructure and platform as a service, etc.), the fundamental issues are not materially different than those associated with the ASP model more than 10 years ago, and in some respects not different from those associated with the service bureau model in the distant past.
Methods of Deployment
Software applications may be deployed in only two ways: 1) on-site or on-premise, where the application is installed on local servers, or 2) hosted, in the “cloud,” which effectively means one or more data centers, somewhere else in the world. In terms of potential risks to either a software application customer or vendor, there is a significant amount of overlap between the two models. After all, from the perspective of both customer and vendor, the software application obviously needs to perform more or less in conformance with the applicable documentation, a third party can bring a claim against both for infringement by the vendor of intellectual property rights, risk must be allocated appropriately given a particular party’s superior knowledge and control, and the vendor must be financially viable (and if there are questions, a source code escrow probably makes sense).
Of course, the issues do not map exactly. In the source code escrow example, while a vendor should be readily able to (subject to appropriate protections) put into escrow the object and source code of the software application that is being delivered through a cloud model, the same may not be said of other technology necessary to provide the software application on a hosted basis. In fact, the operating environment deployed by the vendor to support the software application can be considerable, and the source may simply not be available.
Similarly, with respect to limitation of the liability, given that the vendor has considerably less control in an on-premise deployment, there is a stronger argument to further limit the dollar amount and/or type of damages available to the customer. Regardless, consequential (e.g., lost profits) and indirect damages will be excluded for most, if not all, breaches of the hosted services agreement. And, some considerations simply do not map from the on-premise environment to the cloud environment. For example, as a hosted environment is in effect “locked,” whether or not there is open source software subject to a copyleft license in the hosted software application is moot because a customer will not be able to distribute it.
Risk and Compliance
So, what are the fundamental risk and compliance differences between on-premise and cloud deployments? Actually, they result from two factors:
- The Internet, and;
- Control of the application and data that is uploaded to and that results from the operation of the application.
Think of it as: service bureau + Internet = ASP (or SaaS, or cloud). As for the first factor, let’s just say that more than a few lanes have been added to the Internet superhighway in the last 15 years, such that, for example, the cloud vendor needs to mitigate risk associated with the significant amount and types of data and content uploaded to the vendor’s cloud environment.
Available tools include representations and warranties from the customer regarding the provenance of the data and content, an indemnity in case a claim is made against the vendor by a third party because of that data or content, and mandated scanning before uploading. Conversely, due to advances in the Internet and vast improvements in connectivity, your data can be anywhere, which creates privacy issues (as discussed below), among others. That said, contracts have for some time disposed of the many vagaries of the Internet (such as performance or security) through well-accepted disclaimers - though protections may be taken, as detailed below.
The second primary difference between on-premise and in-cloud deployments deserves greater attention. While the same issues have been hashed out for at least 10 years, they are still as real today as they were when I worked on my first ASP deal. In the cloud computing model, the customer is physically separated from the software application, inputs (data) and resulting outputs (data). That lack of control brings expectations from the customer. Further, once the vendor takes control of the customer’s data or provides certain processing services, there may be legal obligations imposed upon the vendor, independent of the terms of service agreed with the customer.
For the hosted software application, a savvy customer will ask for service level commitments and reporting as well as service level credits for availability of the services, restore and response time and/or performance metrics tied to specific critical transactions. While invariably the credits, will be capped for each period of failures, vendors should take care that credits in the aggregate are also capped. Typically, service credits are the sole remedy for a service level agreement violation. Note that whether or not a software application actually conforms to its documentation is different from whether or not service levels are met. Interestingly, internal IT departments are just as likely to have issues deploying or running software installed on-premise as an external IT department through a hosted deployment, though in a hosted deployment there are explicit disincentives like service credits.
The main issues for data inputs, outputs and associated processing services, are: confidentiality, privacy (which is related to confidentiality), delivery of data, security, compliance with certain industry or governmental regulations (namely, Payment Card Industry Data Security Standard and other related requirements, if the hosted application accesses, collects, transmits, or stores credit card information), a disaster recovery plan, system backup requirements, and security and internal control audits. While a detailed description of the potential issues related to each of the above is beyond the scope of this article, at the very least the following should be considered.
Regarding privacy, will personally identifiable information (i.e., in general terms, information that can be associated with a specific individual) be stored in the hosted application? If so, the customer must comply with specific obligations under privacy laws and, therefore, the customer will mandate the vendor comply as well. Where is the data stored? That is, where is the relevant data center(s)? Are they in the U.S.? As for delivery of data, is the data to be delivered at termination or expiration of the hosted services agreement, within some period thereafter, or any time during the term of the agreement, whether or not the customer has paid any outstanding fees? One form of agreement I reviewed provided that data would be returned only upon payment of all fees (which for a customer should be a non-starter).
As for security, has the vendor implemented measures leveraging best-in-class or industry-standard tools and technologies, such as virus screening software and encryption? Is there a formal security policy? If the customer has its own security policy, should the vendor comply with such policy? As for disaster recovery, is there a formal disaster recovery plan? In connection with disaster recovery, is the force majeure clause drafted properly to ensure that performance should be excused only to the extent that, despite implementation of the plan, the vendor was not able to perform services under the agreement? Is there a meaningful audit process?
The Cloud’s Fine Print
Rather, I would explore the issues described above in the context of a choice between deploying a particular application in the cloud as an alternative to an on-premise deployment. In that exploration, context is important (e.g., will the hosted application be only for internal use or will it be exposed to my end customers, is the application mission-critical, what is the size of the transaction, etc.).
So, does the fine print matter? Yes. Should you lose sleep over the potential risks of cloud computing? No. Just be mindful of your options and bear in mind that the issues, while important, are not terribly new.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access