Get started Bring yourself up to speed with our introductory content.

Negotiating SLA requirements to ensure cloud regulatory compliance

Outlining your enterprise regulatory compliance reporting needs and establishing these needs with cloud providers during SLA negotiations is critical. Ed Moyle outlines steps to help organizations get started.

When it comes to the cloud, everyone knows how important service-level agreements are. Read almost any guidance...

on the topic of cloud security and chances are good it'll say operational, security and other goals are best addressed in SLAs as part of the contract prior to entering into a relationship. It should come as no surprise then, to hear that regulatory compliance reporting is likewise an important element of the contractual negotiation process.

This is good advice -- and certainly helpful to follow -- but for the compliance or security professional interested in where the rubber meets the road, it's missing some nuances.

First of all, it's seldom a "green field" when it comes to cloud relationships. Many organizations don't have the luxury of assuming no cloud relationships already exist. This means most of the time enterprises are back-fitting desired regulatory-driven reporting into existing relationships.

Second, this advice doesn't go into specifics, meaning, it leaves out the "how" -- like what types of reporting information organizations might want, what options are available to help make reporting easier to consume, and what specifically to look and ask for when conducting these discussions.

What should a security or compliance pro look for when it comes to SLAs supporting regulatory and compliance reporting in the cloud? Obviously there's no one right answer here, since much of the answer will depend on the organization's regulatory environment.

Fortunately there are a few strategies to help get organizations started if they're behind the eight-ball on this front.

Laying the groundwork for cloud regulatory compliance reporting

Some organizations have sophisticated, detailed visualization and reporting in their security and compliance posture. They understand which portions of their environment are covered by which regulations, which mandate applies to which data sets, and so forth.

A good rule of thumb is that whatever an enterprise is doing for its internal compliance posture should ideally line up with what it gets from service providers when its scope of compliance intersects provider environments.

This, however, is a rarity. Instead, a number of medium or large organizations struggle to maintain a view of their own compliance, data and assets -- let alone a detailed awareness of the posture of entities in their supply chain. This is a problematic scenario because, depending on how the business uses these service providers, any one of them could introduce an area of regulatory risk should they fail to follow the mandates of the regulations in scope.

For folks in this boat, the immediate goal probably isn't to get to a perfect "compliance nirvana," but instead to go from "very limited awareness" to "at least some awareness."

The first step starts with self-examination. First, organizations will want to know what their regulatory requirements currently are. This might not sound like rocket science, but it's an important step. For example, hospitals are probably well aware that they have HIPAA in their scope, but they might have PCI DSS as well (for example, if they accept credit card payments for services such as parking, charitable donations or cafeteria items). Going through each one systematically to evaluate applicability can be helpful. Organizations will also want to know how they're addressing those requirements internally. If multiple business units are involved, it can become more complicated since they'll want to understand what the compliance posture is for them all.

Why does it matter what an organization is doing when we're talking about service providers? Because we want the reporting we get to be in alignment with -- or at least compatible with -- what we're currently doing internally.

Next, enterprises need to know which cloud services they're currently using and for what purposes. This is the kind of statement that sounds easy until you actually try to go out and do it, because while large-scale usage (for example, a dedicated IaaS relationship) is likely to hit the awareness "radar" for most within the organization, that's usually just the tip of the iceberg. Any service -- whether used by one employee or thousands -- could potentially represent a compliance problem. This means that ideally organizations want to have an inventory of all locations where potentially regulated data is in the cloud. Realistically, this is seldom feasible. Instead, companies will probably need to settle for a list that's "pretty good." Automated cloud discovery tools can help here, as can existing inventories that organizations may have created for other purposes (for example, for budgetary reasons or for business continuity planning).

Establishing compliance reporting needs

Once an organization has the aforementioned data points in hand, the next step is to determine what reporting is needed from a compliance point of view and what reporting it can get its vendors to agree to, and then to finally establish a validation process to ensure that the reporting agreed on is complete and accurate.

Because of the proliferation of service provider relationships and the popularity of the cloud, other options have started to emerge to help limit the audit and assessment requirements for individual organizations.

The first point -- what reporting the regulatory landscape requires -- is going to be unique to each specific environment. It will vary depending, first on the specific regulatory requirements in scope: PCI, for example, requires organizations to maintain a list of system components in scope for PCI (requirement 2.4), while HIPAA provides more general guidance (for example, a way to "detect and report malicious software" per §164.308(a)(5)(ii)(B)). As you might imagine, one report probably won't satisfy both. Moreover, regulatory requirements might vary based on platforms in use, interpretations of the standards that organizations may have made in the past, specific contractual requirements with customers or partners, etc. For example, enterprises might not be able to obtain the exact equivalent report in Windows that it can from an OS X device.

This said, a good rule of thumb is that whatever an enterprise is doing for its internal compliance posture should ideally line up with what it gets from service providers when its scope of compliance intersects provider environments. For many service providers -- particularly those that service a particular industry and have deep expertise in servicing clients in that industry -- chances are higher that they can or do offer reporting capabilities to address compliance concerns for that industry. For example, a service provider offering a cloud-based, healthcare-focused SaaS is more likely to provide specific HIPAA-oriented reporting that its customers can use, as compared to what a more generally oriented service outside of healthcare can do.

It's helpful for organizations to go through these on a service-provider-by-service-provider basis to ensure this reporting exists, that it can be accessed and that it's actually going somewhere that's useful. Some providers only offer compliance reports in response to an explicit request; others might provide the report via a channel that an organization may not expect, such as providing it as an attachment to a maintenance bulletin sent to an operations contact.

What happens if a provider can't, isn't or won't give its customers the reporting they need to meet their compliance mandates? It's an unfortunate reality that this sometimes happens. Enterprises might be tempted to think the answer in this case is to dump the provider and find another. And, for certain applications that are widely available (e.g., file sync and storage), it's certainly an option. But it bears saying that for many situations, this just isn't practical. Consider large-scale SaaS usage for example: Replacing a widely used, business-critical SaaS application with a competitor (assuming one exists) might create so much business disruption as to make doing it a near-impossibility. In this case, as a fallback position, companies can choose to pressure their vendor to see how close it can come -- the organization might, for example, create enough pressure on the vendor to cause it to implement new reporting or bolster existing reporting. If that's not an option, enterprises should investigate what they might be able to collect on their own side to help compensate. For example, if a company can't get a report from the vendor that provides information about who accessed certain data, maybe there is internal information that can be collected to get part of the way there (for example, network logs of who accessed the service at which times). This is, of course, not ideal, but when the alternative is non-compliance, it's better than nothing.

Lastly, keep in mind there could be third-party services that can help round out the reporting; the more popular the service provider and the offering, the more likely it is that there are value-added vendors that can provide tools to help.

Validating accurate cloud compliance reporting

Once an organization has established what it needs from a reporting standpoint and whether (or how) service providers can provide it (or already are providing it), the last step is to establish a validation process to ensure the reporting is accurate.

Historically, reporting validation has been accomplished through assessment, along with most other compliance-driven requirements. However, there are challenges with this. Notably, the assessment of a service provider isn't cheap. Not only are there costs for staff to go there and do the assessment, but also the "right to audit" does not necessarily mean that the audit is free; even though enterprises might have the contractual ability to audit a service provider, bear in mind that there may be professional service charges if support from provider security, operations or compliance teams are required (for example to answer auditors' questions or to provide evidence).

Report validation can be approached just like any other audit or assessment activity; enterprises can also consider outsourcing it if they don't have internal bandwidth. In fact, because of the proliferation of service provider relationships and the popularity of the cloud, other options have started to emerge to help limit the audit and assessment requirements for individual organizations. For example, service provider registries -- like Cloud Security Alliance's STAR registry or Visa's registry of service providers -- that adhere to PCI DSS help mitigate the requirement for individual organizations to assess each provider. One trusted third-party assessor evaluates providers once and adds them to the trusted registry. Assuming an enterprise trusts the rigor of that process, the registry can alleviate the requirement for the organization to do the assessment itself.

The CSA also has licensed the CloudTrust Protocol, a procedure that helps improve transparency for customers about potential providers' compliance, security, privacy and more. Not only can this help organizations decide if a provider is right for them, but it also can be used as an ongoing methodology for evaluating a provider's compliance.

Conclusion

The point is, the auditing, logging and reporting that are required from a cloud regulatory compliance standpoint are not trivial, and each service provider has their own way of handling the unique compliance-driven reporting requirements for the services they provide. Making sure that what they provide and what your organization needs are in sync isn't always easy. By laying the initial groundwork, having a process to identify gaps in reporting, and building a mechanism to validate reporting is functioning appropriately, organizations can make sure their compliance posture in the cloud is every bit as robust as in the environments they build and maintain themselves.

About the author:
Ed Moyle is the director of emerging business and technology at ISACA. He previously worked as senior security strategist at Savvis Inc. and as senior manager at Computer Task Group. Prior to that, he served as vice president and information security officer at Merrill Lynch Investment Managers.

Next Steps

Get help understanding cloud compliance issues

Confused by your cloud SLA? Breaking it down can help

This was last published in March 2015

Dig Deeper on Cloud Computing SLAs and Legal Issues

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

3 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How has your organization ensured its SLAs fulfill cloud regulatory compliance requirements?
Cancel
We primarily work with compliance in the cloud in one of two ways - where possible, we limit the scope of the audit so that it only covers certain aspects of the cloud environment, not the underlying infrastructure. And it cases where that isn't possible, we either A.) limit the scope of what's deployed into the cloud, or B.) keep it off the cloud. This last option hasn't been invoked too often, only as last resort.
Cancel
If the cloud providers want to move away from startups into the enterprise and government spaces, this is absolutely required, can't be done otherwise.
Cancel

-ADS BY GOOGLE

SearchSecurity

SearchCloudComputing

SearchAWS

SearchCloudApplications

SearchServerVirtualization

SearchVMware

ComputerWeekly

Close