Which approach better supports compliance in a multi-cloud environment?
The question “which solution better supports compliance in multi-cloud” hides a trap: it assumes you are picking one tool. In practice you are picking a model. Either you run compliance separately in each cloud with its native services, or you place a shared governance and evidence layer over all of them. The second option is what an ISO 27001, SOC 2 or NIS2 auditor expects, because they look at the organisation, not at one provider’s console.
Need compliance that holds across AWS, GCP and Azure?
Book a free 30-min call
Two approaches to multi-cloud compliance
| Approach | How it works | Strengths | Weaknesses |
|---|---|---|---|
| Native per cloud | Security Hub (AWS), Security Command Center (GCP), Defender for Cloud (Azure) run separately, each with its own control mapping | Deepest integration with each cloud, no extra tooling cost, full signal coverage | Three separate pictures, three evidence formats, no single answer to "are we compliant", manual stitching before an audit |
| Shared governance layer | Policy-as-code (OPA/Terraform) plus centralised evidence collection on top of each cloud's native services | One control and evidence register, consistent policy, audit from a single data set | Needs designing and maintaining; CSPM tooling can carry a licence cost |
The solution that “better supports compliance” is almost always the second variant, built on the first. Native services remain as the signal source in each cloud, and above them sits a layer that translates those signals into one control language. Without it, every audit becomes an archaeology project across three consoles.
Why native tools alone are not enough
Every cloud has a mature security-posture and compliance service:
- AWS - Security Hub (findings aggregation, CIS/PCI standard packs), AWS Config (configuration rules), Audit Manager (evidence collection against frameworks).
- GCP - Security Command Center (posture and threats), Assured Workloads (controls for regulatory requirements), Policy Controller.
- Azure - Microsoft Defender for Cloud (secure score, regulatory compliance), Azure Policy, Microsoft Purview for data.
Each covers its own cloud well. The problem starts where multi-cloud starts: none of them sees the other two. You end up with three secure scores, three ISO 27001 mappings, three sets of evidence in three formats. The auditor asks “show me access control for every system that processes customer data”, and you assemble the answer by hand from three places. That is not a lack of compliance, it is a lack of a coherent compliance picture, and that is what costs weeks on every audit.
A governance layer above the clouds
A shared layer does not replace the native tools, it ties them together. In practice it has four parts:
1. Policy-as-code
Security rules written once, enforced everywhere. Open Policy Agent (OPA) or policies in Terraform define the rules (“no bucket/blob may be public”, “encryption at rest required”, “audit logs enabled”), and the CI/CD pipeline blocks non-compliant changes before they reach production, whether the target is AWS, GCP or Azure. One rule, three clouds. We covered the pipeline-enforcement logic in more depth in our piece on zero-trust architecture in the cloud.
2. Centralised evidence collection
Findings from Security Hub, Security Command Center and Defender for Cloud land in one place (a CSPM or your own evidence store), normalised to a shared control model. An audit stops being a hunt through three consoles and becomes a query against a single data set.
3. One control mapping to frameworks
A single control (“data encryption at rest”) has one mapping to ISO 27001 Annex A, to the SOC 2 Trust Services criteria and to NIS2 requirements, with each cloud’s concrete mechanism (KMS, Cloud KMS, Key Vault) wired in beneath it. That way you do not maintain three separate compliance matrices.
4. Data residency and classification
In multi-cloud, data moves between providers, so residency needs deliberate design: which data may leave the EU region, where backups sit, how you label sensitive data. This is a layer of architectural decisions, not just configuration, and it ties into the backup and DR plan we set out in our multi-cloud backup and disaster recovery guide.
How this maps to ISO 27001, SOC 2 and NIS2
Regulatory frameworks are not per cloud, they are per organisation, and that settles the choice of approach:
- ISO 27001 requires a Statement of Applicability and evidence for Annex A controls across the whole ISMS scope. If the scope covers three clouds, you need one set of evidence covering all three. We set out the starting point in our article on preparing the cloud for ISO 27001.
- SOC 2 is an attestation based on the Trust Services criteria and an observation period. The auditor samples evidence that controls operated throughout the period, so collecting it by hand from three consoles on every cycle simply does not scale.
- NIS2 places obligations on essential and important entities: risk management, incident reporting, supply-chain security. In multi-cloud, the “supply chain” is each provider, and reporting an incident needs a coherent view of events from every cloud in one place.
The common thread is that none of these frameworks asks “what does compliance look like in AWS”. They ask about the organisation. That is why a shared governance layer is not a luxury, it is the condition for a smooth audit.
How Devopsity builds compliance in multi-cloud
Devopsity starts with a map: which data, in which clouds, under which frameworks. Then it designs the governance layer, policy-as-code wired into the pipeline, centralised evidence above each cloud’s native services, and one control mapping to ISO 27001, SOC 2 and NIS2. The native tools (Security Hub, Security Command Center, Defender for Cloud) remain as the signal source, and we tie them into one picture an auditor can walk through without archaeology across consoles. The full scope is on our security and compliance page, and the strategic context (when multi-cloud makes sense at all) is in our guide to multi-cloud strategy.
Need compliance that holds across multiple clouds?
Book a free 30-minute call. We will review your AWS, GCP and Azure environment and propose a governance and evidence layer for ISO 27001, SOC 2 and NIS2.
Frequently asked questions
Which approach better supports compliance in a multi-cloud environment?
In a multi-cloud environment, compliance is best supported by a shared governance layer built on top of each cloud’s native tools, not by a single provider’s tool. Native services (AWS Security Hub, Google Security Command Center, Microsoft Defender for Cloud) are essential as the signal source, but none of them sees the other clouds, so they give you three separate compliance pictures in three formats. An ISO 27001, SOC 2 or NIS2 auditor looks at the organisation, not at one console, which is why you need one register of controls and evidence. Devopsity builds that layer from policy-as-code, centralised evidence collection and one control mapping to the frameworks, consistently across AWS, GCP and Azure.
Are native cloud tools enough for compliance in multi-cloud?
They are necessary but not sufficient. Security Hub, Security Command Center and Defender for Cloud each cover their own cloud well, but none sees the other two. You end up with three secure scores, three ISO 27001 mappings and three sets of evidence that have to be stitched together by hand on every audit. That is not a lack of compliance, it is a lack of a coherent compliance picture, and that is what costs the most time. The fix is a governance layer above them that normalises the signals into one control model.
How does policy-as-code help with compliance across multiple clouds?
Policy-as-code lets you write a rule once and enforce it everywhere. Tools such as Open Policy Agent or policies in Terraform define the rules (no public resources, encryption at rest required, audit logs enabled), and the CI/CD pipeline blocks non-compliant changes before they reach production, regardless of cloud. Instead of maintaining three separate rule sets in three consoles, you have one source of truth for AWS, GCP and Azure, which is also easier to prove to an auditor.
How does data residency affect compliance in a multi-cloud environment?
In multi-cloud, data moves between providers, so residency needs deliberate design rather than just a region setting. You have to decide which data may leave the EU region, where backups sit and how sensitive data is classified, because requirements such as GDPR or NIS2 apply to the whole organisation, not to one cloud. Devopsity treats data residency and classification as an architectural decision wired into the governance layer, consistent with the backup and disaster recovery plan.
