5 Key Compliance Implications of The Cloud

Once upon a time, achieving compliance goals for workloads hosted in the cloud was a tremendous challenge. Cloud vendors offered few tools to simplify compliance, and compliance rules themselves often lacked detail about what was and wasn’t allowed in the cloud.

Those days are gone. It’s much easier to reconcile compliance requirements with the cloud today.

But that does not mean that moving workloads to the cloud — or reconfiguring those that are already in the cloud — doesn’t carry compliance implications. It’s still critical to address the special compliance challenges that arise for cloud-based workloads today, as well as to plan ahead for those that may appear in the future.

Here’s a look at five key lessons businesses should know about compliance in the cloud today, along with best practices for building a cloud strategy that meets compliance requirements over the long term.

#1. The Cloud Compliance Landscape Is Rapidly Changing

One ongoing challenge of compliance in the cloud is the fact that regulatory compliance frameworks are changing quickly. The past several years have witnessed the introduction of major new compliance frameworks, like the European Union GDPR and Brazil’s LGPD. Others, such as the CPRA, a California law that takes effect in 2023, are on the horizon.

None of these compliance frameworks ban the use of the cloud. But they do impose rules, such as auditing requirements and the implementations of “reasonable” security mechanisms for protecting private data, that carry major implications for workloads running in the cloud.

For businesses, the evolving compliance landscape means that the regulatory rules that cloud workloads must meet today may change a year or two down the road. To ensure long-term compliance success, it’s important to look not only at which compliance rules are in effect today and which mandates they impose, but also which ones may appear in coming years.

#2. Cloud Compliance Is About More Than Regulatory Rules

Regulatory frameworks like those mentioned above are often what developers and IT engineers first think of when they hear the word “compliance.” However, the fact is that regulatory compliance represents only one part of the compliance landscape.

The other part involves internal compliance, meaning the rules that businesses set internally regarding the way IT resources are set up and managed. Those rules might include, for example, a requirement that business units get approval from the IT department before spinning up new resources, or for engineers to implement certain minimal access control rules when creating network-connected data stores.

Ensuring internal compliance can be especially challenging in the cloud due to the speed and ease with which cloud resources can be created and moved. For instance, it’s typically hard to stand up an unauthorized on-premises server without being noticed, because the server will exist on a physical site that multiple people can access. But in the cloud, there is little to stop an employee from spinning up a clandestine VM without getting permission.

This means that businesses must work extra hard to ensure internal compliance in the cloud. The compliance services from cloud vendors can help (even though most of them are designed for regulatory compliance more than for internal compliance). So can the use of monitoring and observability tools that help central IT teams to track cloud resource deployments and reveal patterns or trends that run afoul of internal governance rules. Resource tagging also helps businesses keep track of what they are running in the cloud, although it’s important not to rely on tagging too heavily because it’s usually impossible to ensure that employees properly tag every resource they create.

#3. Cloud Environments Are Rarely Compliant by Default

Today, cloud vendors offer a variety of tools, such as IAM frameworks and automated risk assessment services, to help businesses meet compliance rules.

Unfortunately, most of these tools are not enabled or properly configured by default. For example, AWS Audit Manager, the main risk assessment tool in the AWS cloud, has to be set up manually before it begins monitoring your environment for compliance risks. Likewise, although the object storage services on most public clouds are designed to make data private by default, they don’t necessarily guarantee compliance. They may allow users within the organization to access data that should not be available to all internal users, for example, or they may not be strict enough to meet the “reasonable” security requirements of regulatory compliance laws.

The takeaway here is that it’s on the business to ensure that it makes use of the compliance resources available in the cloud. While modern tools make it much easier today to create compliant cloud workloads than it was ten or fifteen years ago, you still have to take the initiative to leverage the tools to their full effect.

#4. More Cloud Accounts Mean More Compliance Challenges

An often-overlooked factor in cloud compliance is multi-account cloud environments. This means scenarios where organizations maintain multiple discrete accounts on a cloud platform, rather than managing all of their workloads through a single account.

For smaller organizations, it’s usually easy enough to manage everything with one account. But enterprises with multiple business units may assign a different cloud account to each unit. Doing so helps to isolate workloads, while also making it easier to track cloud spending on a department-by-department basis.

From a compliance perspective, however, more cloud accounts add significant complexity to compliance and auditing operations. Businesses either have to monitor and audit each account’s environment separately, which is inefficient, or find a way to aggregate compliance data from all accounts so they can monitor risks centrally. The latter approach is possible (and tools like AWS Audit Manager support it, provided you also configure the AWS Organizations service), but it requires more setup and administrative overhead.

The lesson: Having multiple cloud accounts is unavoidable for larger businesses. Be sure to plan ahead for the compliance challenges that stem from a multi-account cloud.

#5. Cloud Compliance Can (And Should) Be Automated

Traditionally, compliance risk assessment was a mostly manual affair for businesses. They performed period audits, identified risks and mitigated them manually.

The problem with taking this approach to compliance in the cloud is that it undercuts scalability, which is one of the chief selling-points of the cloud. If you have to vet each new cloud workload manually for compliance conformance before you can deploy it, or you periodically pause your regular work so you can overhaul your IAM configurations to meet compliance risks identified in your latest audit, you end up with workflow bottlenecks that reduce the overall business value of the cloud.

That’s why it’s vital to leverage tools that automate cloud compliance as much as possible. Ideally, compliance automation should start early in the CI/CD pipeline. In other words, before a new application release has even been deployed to the cloud, it (and configuration data associated with it) should be scanned automatically for compliance conformance. Then, once it is in production, automated risk assessment tools should continuously scan for configurations or behaviors that violate whichever compliance policies you establish within the tools.

The Ongoing Challenge of Cloud Compliance

Like many things in the world of IT, compliance in the cloud is continually becoming both harder…and easier. It’s growing harder as new regulatory rules come into force, and as cloud workloads themselves grow more and more complex (and therefore more difficult to monitor and audit). At the same time, however, the emergence of tools designed to help automate cloud compliance offers businesses the resources they need to keep pace with cloud compliance rules — provided that organizations take the steps necessary to use these tools properly.