Most teams do not fail audits because their cloud is insecure. They fail — or more often, suffer through — audits because they cannot prove their cloud is secure. The controls exist. The intent exists. What is missing is the continuous, mapped, exportable evidence that an auditor accepts without a month of back-and-forth. And when the environment spans two clouds, each with its own security model and its own native tooling, the evidence problem roughly doubles.
This guide is for teams running on GCP and Azure together — a common shape for mid-market SaaS and FinTech companies that started on one cloud and added a second as enterprise customers, specific services, or acquisitions pulled them there. If you are carrying SOC 2, ISO 27001, and GDPR simultaneously across both providers, this is a walk through why that is hard, where the time actually goes, and how a correlated CSPM approach turns audit prep from a quarterly fire drill into a byproduct of the platform running.
Why Multi-Cloud Compliance Is Harder Than the Sum of Its Parts
A single-cloud compliance program is already non-trivial. A multi-cloud one is not simply twice the work — it is a different kind of work, because the two clouds do not speak the same language.
GCP organises resources as organisation → folder → project → resource, with IAM policies attached at each level and inheritance flowing downward. Azure organises as management group → subscription → resource group → resource, with Azure RBAC and Azure Policy operating on their own model. A “least privilege” control means something structurally different in each. “Encryption at rest” is configured, named, and evidenced differently in each. “Network exposure” is reasoned about differently in each. An ISO 27001 Annex A control like A.8.3 (information access restriction) maps onto two entirely different sets of underlying mechanisms depending on which cloud the resource lives in.
The native tools make this worse, not better, for compliance purposes. GCP’s Security Command Center reports on GCP. Microsoft Defender for Cloud reports on Azure. Each is competent within its own boundary and blind outside it. Neither produces a single, cross-cloud compliance posture, and neither maps its findings to the specific frameworks you are audited against in a form you can hand to an assessor. So the team ends up as the integration layer — manually normalising two sets of findings, in two formats, against three frameworks, by hand.
The Three Frameworks, and Why They Compound
Running SOC 2, ISO 27001, and GDPR together is not three parallel efforts. It is one effort with three overlapping-but-distinct evidence demands.
SOC 2
SOC 2 is organised around the Trust Service Criteria — security, availability, processing integrity, confidentiality, and privacy — with security (the Common Criteria) always in scope. A SOC 2 Type II report, which is what enterprise customers increasingly demand before they sign, requires evidence that controls operated effectively over a period of time, typically six to twelve months. That temporal requirement is the sting: you cannot assemble a Type II evidence package the week before. You need to have been collecting evidence continuously for the whole observation window. A control that was configured correctly only on the day the auditor looked proves nothing about the period.
ISO 27001
ISO 27001:2022 centres on an Information Security Management System and the Annex A controls. Certification audits and annual surveillance audits ask you to demonstrate that controls are not just defined but implemented and monitored. For cloud resources, that means mapping specific configurations — access restrictions, logging, cryptography, network segregation — to specific Annex A controls, and showing that the mapping holds continuously across your estate. Across two clouds, the same Annex A control has two implementations and two evidence sources.
GDPR
GDPR is less a checklist and more a set of principles with teeth — lawful basis, data minimisation, access limited to legitimate need, and demonstrable accountability (Article 5(2)). For a cloud estate, the questions that bite are: where does personal data live, who can access it, is that access limited and logged, and can you prove it? A FinTech holding customer personal and financial data in production databases has to answer those questions about the data tier specifically — which is often the least-instrumented layer of the whole stack.
The compounding effect is that a single underlying control — say, “access to production data is restricted, logged, and reviewed” — has to be evidenced three different ways for three different audiences, across two clouds. Do that manually and you are assembling the same facts repeatedly in slightly different shapes, which is exactly the kind of work that consumes a scarce engineer for weeks per cycle.
Where the Time Actually Goes
If you ask teams what makes audit prep painful, the answer is rarely “fixing problems.” It is the evidence logistics:
- Finding the current state. Pulling configuration state from both clouds, for every in-scope resource, as of the audit date — and for Type II, across the whole period.
- Normalising across clouds. Translating GCP findings and Azure findings into one consistent vocabulary so a control can be evidenced uniformly.
- Mapping to controls. Deciding which specific finding supports which SOC 2 criterion, which ISO 27001 Annex A control, and which GDPR principle — and doing it defensibly.
- Assembling the package. Exporting it all into something an auditor accepts: spreadsheets, screenshots, PDFs, with timestamps and attribution.
- Explaining the gaps. Where a control was not met, documenting the exception, the compensating control, and the remediation plan.
Every one of these is manual by default, and every one of them is repeated each cycle. The result is a predictable, dreaded, multi-week scramble that pulls engineers off product work and still produces an evidence package that is stale the moment it is finished.
The Shift: From Point-in-Time Scramble to Continuous Evidence
The fix is not to work harder on the scramble. It is to eliminate the scramble by making compliance posture a continuous, mapped, exportable property of the environment itself. That requires three things working together:
- One normalised view across both clouds — so GCP and Azure findings share a vocabulary and a severity model.
- Automatic mapping to frameworks — so every finding already knows which SOC 2 criteria, ISO 27001 controls, and GDPR principles it supports.
- Continuous collection — so the evidence spans the whole observation window instead of a single snapshot.
This is where a correlated CSPM earns its place. The point is not “more findings.” It is findings that are already normalised, already mapped, and continuously collected — so the evidence exists as a byproduct of the platform operating, not as a project you launch each quarter.
How Cloudanix Approaches Multi-Cloud Compliance
Cloudanix connects to GCP projects and Azure subscriptions agentlessly — read-only service accounts on GCP, app registrations on Azure — with no infrastructure changes and typically under 30 minutes to onboard. From there, several things change about how compliance works.
1,000+ Checks Mapped to the Frameworks You Carry
Cloudanix ships with over a thousand pre-built checks mapped out of the box to SOC 2, ISO 27001, and GDPR — and many more frameworks besides (HIPAA, PCI DSS, NIST, CIS, and others). The mapping is the valuable part: a finding is not just “this resource is misconfigured,” it is “this resource fails a control that supports SOC 2 CC6.1 and ISO 27001 A.8.3.” The translation work that normally consumes an engineer is already done and maintained.
One Compliance Dashboard Across GCP and Azure
Rather than reconciling Security Command Center and Defender for Cloud by hand, the team sees a single compliance posture spanning both clouds, with findings normalised to a common model. The same control shows its status across GCP and Azure in one place. For a two-person security function, this collapses two reconciliation workflows into one dashboard.
Continuous Monitoring, Not a Snapshot
Posture updates continuously as resources drift and as findings are remediated. For SOC 2 Type II specifically, this is the difference between scrambling to reconstruct a period and having the period already recorded. Audit readiness becomes something you can see in real time rather than something you discover during prep.
Contextual Severity So You Fix the Right Things First
Not every failed check carries the same weight. Cloudanix recomputes severity per asset from a security graph — exposure, environment, data sensitivity, identity — so a public-facing production resource holding personal data outranks an internal dev resource failing the same rule. During remediation sprints before an audit, this focuses scarce engineering time on the findings that actually move the compliance needle (and the risk) rather than an undifferentiated wall of “Critical.”
Audit-Ready Export and Risk Acceptance
Evidence exports to formats auditors accept — Excel and PDF — mapped to controls, with history available. Where a finding will not be remediated before the audit, risk can be formally accepted with a documented reason, which is itself part of a defensible compliance narrative. The evidence package stops being a bespoke assembly job and becomes an export.
The Data Tier GDPR Actually Cares About
GDPR’s hardest questions are about personal data — who can see it and whether access is limited and logged. Posture management answers the infrastructure questions, but the data tier needs its own instrumentation. Cloudanix Database Activity Monitoring adds query-level audit and role-based masking on the databases holding personal data, so “who accessed personal data, and was it limited to legitimate need?” has a concrete, exportable answer — and it correlates with the posture and identity findings rather than sitting in a separate silo. For the fundamentals, see what Cloud Compliance means.
A Practical Sequence for a GCP + Azure Team
If you are standing this up from a manual process today, a sensible order of operations:
- Onboard both clouds agentlessly and let the baseline build. You get an immediate, normalised posture across GCP and Azure without touching infrastructure.
- Turn on the framework mappings for SOC 2, ISO 27001, and GDPR and read the current posture. This is your real starting position — usually more honest than the last manual assessment.
- Triage by contextual severity, not by raw count. Fix the exposed, data-adjacent, production findings first.
- Instrument the data tier with DAM on the databases holding personal data, so GDPR access questions are answerable at the query level.
- Let continuous collection run through the observation window, so when the SOC 2 Type II period closes or the ISO surveillance audit arrives, the evidence already spans the period.
- Export and accept. Produce the mapped package, document any accepted risks, and hand the auditor something coherent on the first pass.
The Takeaways
- Multi-cloud compliance is an evidence problem, not usually a security problem. The controls often exist; the continuous, mapped proof does not.
- GCP and Azure speak different control languages. Native tools are blind across the boundary, so the team becomes the manual integration layer unless something normalises the two.
- SOC 2 Type II is temporal. You cannot assemble a period’s worth of evidence in a week — you need continuous collection across the whole window.
- GDPR lives at the data tier. Posture management is necessary but not sufficient; the databases holding personal data need their own query-level audit and masking.
- Contextual severity makes remediation efficient. Fix the findings that matter to risk and to the frameworks first, not an undifferentiated pile.
- The goal is to make evidence a byproduct. When posture is normalised, mapped, and continuously collected, audit prep stops being a quarterly scramble.
If your environment spans GCP and Azure and you are carrying SOC 2, ISO 27001, and GDPR at once, the win is not another tool that finds more problems — it is one that already knows which control each finding supports, across both clouds, continuously.
Book a Free Assessment to see your GCP and Azure compliance posture mapped to SOC 2, ISO 27001, and GDPR in under 30 minutes.
Related Resources
- What is Cloud Compliance?
- What is SOC 2 Compliance?
- How Can Your Application Accomplish ISO 27001 in AWS, Azure, or GCP?
- What is GDPR Compliance?
- Multi-Cloud CSPM for a GCP-Heavy FinTech with GKE Workloads
- Why Flat Per-Rule Severity Is Broken — and What Contextual Severity Fixes
- Cloud Security for Financial Services: Compliance, JIT Access & Misconfig Playbook
