Compliance. We know the feelings that this may evoke – fear, anxiety or even sheer dread.At the most basic level, compliance is about following the rules. But rules come in many shapes and sizes, particularly when it comes to the idea of compliance.

For instance, companies may have external rule sets, such as:

  • PCI – primarily for financial services
  • HIPAA – primarily for healthcare data
  • FedRamp – primarily for US government and companies that services the public sector
  • SOX – Sarbanes-Oxley – primarily for publicly traded companies

These are often referred to as compliance regimes.

And digging deeper, let’s look at what a policy regime can contain. Here, we’ll use the PCI standards, specifically the prioritized approach for PCI DSS from March 2015. Here is the approach that’s recommended for companies to follow:

  1. Remove sensitive authentication data and limit data authentication.
  2. Protect systems and networks, and be prepared to respond to a system breach.
  3. Secure payment card applications.
  4. Monitor and control access to your systems.
  5. Protect stored cardholder data.
  6. Finalize remaining compliance efforts, and ensure all controls are in place.

What can we observe from this, is that PCI compliance is a combination of technical controls, data policies, and operational process. But again, technical controls can vary widely, from detailed specifications like:

  • Firewall configuration to protect cardholder data
  • Not using vendor defaults for system passwords
  • Encrypt transmission of cardholder data across public networks

To very softly defined, subjective controls like:

  • Protect stored cardholder data

An interview with a CEO of cloud managed service provider focused on HIPAA compliance revealed that his firm’s approach to compliance was centered around “building a common set of controls, but more importantly, a standard process for each type of action, and then a full audit trail for all actions taken.”

The cloud presents unique challenges

Some of the main drivers for companies moving to the cloud include rapid deployment, decentralized IT, and elastic provisioning where infrastructure can scale both up and down.

Each of these values is a problem in itself.

  • Rapid deployment means decreased time to verify that the appropriate security controls are in place.
  • Decentralization means decreased visibility from staff who specialize in compliance.
  • Elastic capacity means needing to monitor and control your environments constantly for new vulnerabilities or compliance issues.

And to top it off, cloud vendors typically explicitly place the burden for most of the difficult controls (network, security, data policy) compliance on the customer through the shared responsibility model.

Amazon Web Services and the shared responsibility model. Image Credit: Amazon Web Services. Amazon Web Services and the shared responsibility model. Image Credit: Amazon Web Services.

That’s no reason to abandon the cloud completely. Most leading cloud vendors will go out of their way to help enable you, from providing helpful guides to compliance reports for their services.

But remember the shared responsibility model – that only covers physical infrastructure and the virtualization layers. The application layer, and – most importantly – the actual customer data, are explicitly excluded!

Overcoming cloud compliance problems with policy automation

Most companies working in regulated spaces with compliance requirements employ specific people or have specific job roles responsible for ensuring compliance. That team can lead the organization’s efforts for compliance in the cloud. Policy automation tools can help you overcome all these challenges, and more.


While each application or data type may have slightly different set of rules, building these controls centrally, and then pushing them out as an overlay to both existing and new cloud infrastructure can ensure that all infrastructure stays within the guidelines that the organization requires.


What happens when there are problems? Having the team consider each control, each risk of policy violation, and the type of response needed is great. Having that documented and shared widely among all the people who might need to follow the documented response process is even better. Having the documented response process turned into an automated script that automatically corrects the problem is the best.


Many organizations implement centralized logging and IT service management (ITSM) ticketing systems to gather the necessary documentation to provide to auditors, and to alert them to areas of concern. However, in the rush of a security incident or outage, this documentation often has to be created and reviewed after the fact. This is not only inefficient, but also subject to human error. Modern policy automation tools can generate the needed documentation automatically and systematically.

Get Started with an Enterprise Trial

Deploy an enterprise version of BotFactory