How much do risk and compliance teams impact your cloud architecture?

Deloitte on Cloud Blog

Explore some common challenges that companies often face in the areas of cloud risk management and compliance.

March 1, 2018

A blog post by Mike Kavis, chief cloud architect, Deloitte Consulting LLP.

A common pattern I see in heavily regulated industries is that the risk and compliance teams are dictating technology decisions. This ranges from determining which cloud provider (if any) can be chosen to what tools and processes must be used. This can pose challenges because technology decisions should be made by considering all stakeholders, not just those concerned with risk management and audits.

Part of any good cloud strategy is identifying roles and responsibilities. The primary role and responsibility of the risk and compliance teams should be to define policy, not to dictate technology solutions in support of those policies. The technology teams should be tasked with architecting solutions that comply with these policies. 

Here are some common challenges that companies often face in the areas of risk and compliance:

Mistaking current implementations and processes as requirements

Policy definitions are requirements. Current state implementations of those policies are not. Too often I see “requirements” dictating what process or what vendor solutions must be in place in the cloud. An example of this is network segmentation. I have seen “requirement” documents that spell out exactly how network segmentation must be implemented in the cloud. This is incorrect and detrimental to the architecture in the cloud.

The public cloud service providers (CSP) have abstracted the underlying network infrastructure and provide APIs to allow you configure network segmentation in a much more efficient and effective manner than how we solved things in the data center. The VPC (virtual private cloud) provides flexibility for architects to meet policy requirements in support of security, risk, and compliance requirements. Leverage the cloud leading practices for network segmentation and let go of the data center way of doing things.

Applying data center auditing leading practices to the cloud providers

CSPs do not allow access to physical machines in their data centers, so you should not ask them to bring your auditors in for a site visit. If you are Bank 1, do you want Bank 2’s auditors walking the floors of your data center? The cloud providers must protect against that as well. Some cloud providers will allow you to tour their facility but all you will get is a distant view of machines with blinking lights and you won’t have any idea which machines actually host your data. So basically, a tour of a CSP is not time well spent, yet some companies still do it to check the box for their auditors.

Some companies want to audit the CSPs IT processes. They insist that the certifications the CSPs have only are representative of a point in time and do not ensure that the proper processes are being followed daily. Once again, you are not going to be able to walk the floors at your favorite CSP to audit their IT processes. CSPs deploy multiple times daily. They get audited more than once a year. Do we need real-time certification? This request is just not feasible. Some CSPs deploy hundreds of times a day. At some point, you have to accept that their certifications are sufficient and accept some level of potential risk that there may be instances where the CSP is not in compliance.

Not adhering to the shared responsibility model

CSPs have a well-defined shared responsibility model (see picture example figure below).

us-shared-security-responsibility-model.jpg (1420×790)

In this example model, customers are responsible for everything above the hypervisor and the CSP is responsible for everything below the hypervisor. But too often companies burn a lot of energy trying to audit CSPs people, process, and technologies that are not in the customer’s scope of responsibility. If customers can’t adhere to the shared responsibility model of the cloud, then they should not use the cloud. But if they want to use the cloud effectively, they should avoid spending time and energy trying to look at things below the hypervisor.

I remember being at a presentation where a CSP was explaining how their cloud platform performs live migrations with zero downtime. There were a few security engineers in the audience who were asking how they could get all of the log files from CSP’s data centers to prove that the live migration process was compliant. Just stop it! What CSPs do under the covers is their secret sauce and is their responsibility, not their customers'. Just because you have access to infrastructure logs on-premises does not mean you need to have them in the cloud. Adhere to the shared responsibility model and stop spending cycles on anything that falls below the hypervisor.


Risk and compliance teams play an important role in the adoption of cloud, but they shouldn’t be dictating technology and process decisions. They should be determining policies and requirements and review how the architecture and design address those requirements. How risks are addressed in the physical data center are very different than how risks are addressed in the cloud. Understand and apply the shared responsibility model. If you can’t accept the shared responsibility model then cloud may not be the right choice. However, the company that does not adopt cloud could be at a real disadvantage if they are still in the data center business five years from now.

Interested in exploring more on cloud?

Site-within-site Navigation. Do not delete! This box/component contains JavaScript that is needed on this page. This message will not be visible when page is activated.

Insert Custom CSS fragment. Do not delete! This box/component contains code needed on this page. This message will not be visible when page is activated.