Cloud computing, like the virtualization technologies on which it is based, separates function from the physical platform on which it is based. While this brings tremendous advantages in terms of data center efficiency and server manageability, it can run head-on into corporate policies and government regulations that were written in an era of one server per computer, and that computer sitting in a single, well-established location in the data center. When moving to a cloud computing environment, a path to fitting the server into a regulatory framework must still be found. That path runs straight through the service level agreement (SLA) that exists between enterprise customer and cloud service provider.
SLAs have been around for a long time, and they've generally been concerned primarily with, well, the service that the customer can expect. The definition of "performance" can take page after page of verbiage, words covering everything from how long it takes for the first screen to appear to how long a user has to wait for the response to a query to appear on the screen. SLAs often specify how many minutes a year the service can be unavailable and how many employees can simultaneously use the service while the conditions concerning performance are still met. Until recently, though, SLAs were concerned almost totally with the service to be delivered — not with the infrastructure in the provider's data center that delivers the service.
Why should the customer care about the contents of the "black box" delivering the service? The customer cares because regulators care. The things regulators care about tend to revolve around ensuring that data is transmitted and stored securely, and that only those authorized to see and use it, can. Proving that those conditions are being met to the satisfaction of regulators requires knowing things most cloud service customers would really rather not know about — and that cloud providers would rather not have to tell you.
Take the rather simple question of precisely where your data is. In an internal system, it's typically easy to point to a particular storage device or file system and say, "There it is." The storage system, with all its federated services, de-duplication features for backup, and other processes, are under the control of the IT department with known policies and thorough activity logs. What is the backup policy of the cloud storage provider? What password policies does it enforce on its servers to make sure no one can get to the information without authorization?
If the cloud service is an application rather than storage, the same questions can apply. How stringent are the password rules on the management consoles for the back-end application servers? What combination of policy and technology ensures that the data used in your application isn't available to any other applications? And try this one: Are all the servers used to deliver the service within the United States? If not, what assurances are in place to guarantee that US laws and regulations apply to the data at every point on the application chain?
If your business is using cloud services for any purposes that might fall under regulatory review, then the SLA in place with the cloud provider must provide for the same protections required of your internal servers and systems and must require that the cloud be able to satisfy compliance auditors that necessary conditions are being met. In the world of today's enterprise IT, those requirements may be far more critical than timing application performance to the second.
For more information:
Enterprise Contract Management
IT Strategy and Planning
Digital Strategy and Risk Assessment
        | 
 |
