5 Best Practices for Compliance-Proofing Your Cloud Strategy

One of the tricky things about compliance is that the rules are always changing. Not only are most compliance frameworks updated periodically, but new ones — such as, in recent years, the GDPR and CCPA/CPRA — are introduced.

For cloud architects and developers, this pattern begs the question: How do you ensure that your cloud environment is compliant not just with the rules you need to meet today, but also with those that may arise in the future? How do you avoid having to upend your cloud strategy due to unexpected changes in compliance requirements?

There are no simple answers to those questions, of course. But by thinking strategically about how cloud environments are designed and managed, it's possible to "compliance-proof" your cloud, which means running a cloud that meets future compliance requirements, even if you don't currently know what those requirements might be.

Here's a look at five such tips that can help make clouds compliant over the long term.

1. Isolate Cloud Workloads

The more applications you have running alongside each other, the harder it is to ensure that those applications meet compliance rules — especially if each application is different and therefore must be secured and assessed in different ways.

This is one reason (there are others) why it's a best practice to design cloud environments in such a way that workloads are isolated wherever possible. In Kubernetes, that means creating different namespaces — or, where possible, clusters — for each workload. For cloud VM services, it means sticking to one application per VM instance. For data storage, it means creating different storage buckets for each data set. And so on.

Related:4 Reasons Why AWS Could Lose Its Dominant Cloud Market Share

The more granularity you have over the way workloads are structured, the easier it is to audit each one individually, as well as to secure each one in whichever ways future compliance rules may dictate.

2. Tag, Tag, Tag

In most cases, you can apply "tags" to various cloud resources. Tags allow you to name and label resources so you can locate them more easily later.

In addition to conferring benefits like greater billing visibility, tags play an important role in compliance-proofing. They help ensure that you can locate all of your workloads easily, which may be important if you need to identify certain workloads because a new compliance mandate applies to them. Without tags, the process of figuring out how to deploy new compliance rules is much messier.

3. Turn On Auditing

You may not be required to audit a given cloud workload today. But if compliance rules change in the future, that workload could well require auditing.

Related:What Is Cloud Security?

For that reason, it's a best practice to enable cloud auditing services — like AWS Audit Manager or Kubernetes audit logs — even if you don't need them yet. At a minimum, you should at least ensure that your workloads are configured in such a way that they will be compatible with auditing tools in the future, should you need them. You don't want to discover that you're suddenly required to perform audits for a given workload but you can't unless you overhaul the workload.

4. Make Sure Apps and Data Can Move to New Cloud Regions

You also don't want to discover that you need to host applications or data in a specific geographic region — which you may due to data sovereignty requirements — but you can't because the regions you need to move to don't support the workloads.

In general, this is not a major risk because most regions of most major public clouds support all major cloud computing services. But there are exceptions. For example, AWS CodeGuru is currently only supported in a subset of AWS cloud regions, which could pose a challenge in the event that you needed to run it in a non-supported region due to new compliance rules.

5. Use Multicloud Tooling

From a compliance-proofing perspective, tools for monitoring, security, auditing, and other functions are best when they work across multiple clouds.

That's because, if you need to move a workload to a different cloud to meet changing compliance rules, you ideally won't have to adopt a whole new set of management tools to do it.

Tools that only work in a specific cloud platform (which are, in most cases, tools provided by cloud vendors themselves) have their purposes. They may be useful for performing basic administrative tasks, and they are usually very easy to deploy and configure. But to gain the greatest compliance guarantees over the long term, prioritize tools that work across any cloud.

Conclusion

Compliance rules are complicated by their very nature. But they're even more complicated when you can't meet them easily because the rules have been updated and your existing cloud workloads are no longer compatible with the new requirements.

The good news is that you can mitigate this risk by taking steps to ensure that your cloud environment can adapt easily for a changing compliance landscape. Strategies like enabling cloud auditing, tagging resources consistently, and isolating cloud workloads help get you there.