How to Prove Compliance Consistently Across AWS, GCP and a Sovereign EU Cloud

You prove compliance consistently across AWS, GCP and a sovereign EU cloud by moving the control point up one layer. Define your controls once at the Kubernetes and delivery-pipeline layer, which behaves the same on all three, instead of re-implementing each control in three separate consoles with three log formats. Map everything to one control spine (ISO/IEC 27001:2022 or the SOC 2 Trust Services Criteria), keep a single control-to-cloud matrix in git with one named evidence artifact per control per cloud, and force every production change through one pipeline so you export one audit trail instead of three. Do that, and an auditor sees one control operating identically everywhere, which is exactly what they ask for.

An auditor does not accept "it depends on the cloud" as an answer. I have sat through enough audit prep to know the failure mode: a team shows the control enforced cleanly on AWS, then starts opening a different console to reconstruct the same evidence by hand for the second and third cloud. The gap between the three implementations is itself the finding.

Key Points:

• Move the control up a layer. Kubernetes RBAC and admission control are upstream-standard mechanisms (Kubernetes) that behave the same on every conformant cluster, so define the control there once instead of three times.
• Provider certifications do not cover you. AWS lists 143 security standards and compliance certifications (AWS) and Google Cloud publishes a comparably long catalogue (Google Cloud), but none of them cover your IAM grants, your namespaces, your encryption settings or your pipelines.
• Keep one control-to-cloud matrix in git. One row per control, one column per cloud, one named evidence artifact and owner per cell. That matrix is the artifact auditors actually ask for, and its git history becomes your change evidence for free.
• Produce four evidence types, once each. Who had access, what changed and who approved it, where the data physically sat, and proof the control ran throughout the audit period.
• Qovery standardises the deployment and access layer across clouds. It complements, it does not replace, a CSPM like Wiz or Orca and a compliance-automation tool like Vanta or Drata.

Why does compliance break down the moment your workloads span AWS, GCP and a sovereign EU cloud?

Compliance breaks because each cloud speaks a different dialect of the same control. "Only approved engineers can deploy to production" becomes AWS IAM policies plus CloudTrail on one cloud, GCP IAM bindings plus Cloud Audit Logs on another, and a sovereign provider's own console plus whatever log export it offers on the third. One logical control turns into three implementations, three log schemas and three evidence sets an auditor has to reconcile by hand.

Drift is what actually sinks you. You tighten the production-access rule on AWS in March, and the change rarely makes it to the sovereign cluster the same week. Six months later an auditor reads that gap not as a backlog item but as a design deficiency, because the control now has two different designs doing the same job.

This is the default state, not an edge case. In the 2025 State of the Cloud report, 70% of organisations run a hybrid setup and the average company uses 2.4 public cloud providers (Flexera). Across 200-plus conversations I have had with CTOs and platform leads, the third cloud is increasingly a sovereign EU one, pulled in by data-residency rules, public-sector tenders that demand a sovereignty label, acquisitions, latency, or concentration-risk policy under DORA.

The overhead scales badly. Audit prep degenerates into a screenshot ritual repeated per cloud, per environment, per control: N controls times M clouds times K environments. Get it wrong and the cost is real. The global average cost of a data breach was USD 4.44 million in 2025 (IBM), and misconfiguration-class errors sit behind a meaningful share of breaches year after year (Verizon 2025 DBIR).

What do auditors actually ask for when workloads are spread across multiple clouds?

Auditors do not audit your clouds. They audit your controls, and they ask you to show one control operating identically everywhere it applies, with dated evidence that it ran in each environment throughout the audit period. For a SOC 2 Type II that period is commonly 3 to 12 months of operating-effectiveness evidence in practice; for ISO/IEC 27001 it is a whole management system you have to demonstrate.

Every multi-cloud audit comes down to four evidence types:

• Access: who could reach what, plus the signed quarterly review.
• Change: what was deployed, by whom, approved by whom.
• Residency: which region the data and its backups sat in.
• Operation: proof the control actually executed, not just that a policy document exists.

Sampling is where per-cloud answers fall apart. The auditor picks random production deployments from the period and asks you to walk the approval trail. It has to resolve the same way on every cloud, from the same system of record. If it resolves automatically on AWS and through a manual ticket on the sovereign cluster, that is one control with two designs, and that is a finding.

The shared responsibility line is the crux here. Provider attestations (ISO 27001, SOC 2, BSI C5, HDS, SecNumCloud) cover the infrastructure, not what you build on it. AWS states it plainly: it is responsible for security "of the cloud" while you are responsible for security "in the cloud", including the guest OS, your application, firewall configuration, your data, encryption and IAM (AWS Shared Responsibility Model). Gartner made the same point years ago when it predicted that through 2025, 99% of cloud security failures would be the customer's fault (Gartner, 2019). Evidence has to be reproducible on demand from a system of record, not rebuilt from Slack threads and console screenshots the week before the audit.

Which compliance framework should you map to when you run on three clouds at once?

Map to one umbrella control framework and treat each cloud as an implementation target, not a separate compliance program. ISO/IEC 27001:2022 Annex A or the SOC 2 Trust Services Criteria is your spine; GDPR, NIS2, DORA and the sovereignty labels layer on top as additional obligations evidenced against the same controls.

Pick the spine first. ISO/IEC 27001:2022 Annex A has 93 controls across four themes, consolidated from the 114 controls in the 2013 edition (ISO). SOC 2 runs on five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality and Privacy (AICPA). For the cluster layer specifically, cross-walk to the CIS Kubernetes Benchmark (currently v2.1.0, with EKS v2.0.0 and GKE v2.0.0 variants alongside the cloud-neutral baseline, CIS), because that benchmark applies to EKS, GKE and self-managed clusters alike.

The EU obligations layer on top, and you should cite each by its legal identifier so there is no ambiguity:

• GDPR (Regulation (EU) 2016/679): Article 28 governs your processors and Article 32 the security of processing (gdpr-info.eu).
• NIS2 (Directive (EU) 2022/2555): national transposition was due 17 October 2024, and Article 20 puts cybersecurity oversight and liability on management bodies.
• DORA (Regulation (EU) 2022/2554): applicable since 17 January 2025, with Article 28 requiring a register of information on every ICT third-party arrangement.
• EU Cloud Code of Conduct: a GDPR Article 40 code monitored by SCOPE Europe.

Now the part most tender responses get wrong, so here it is cleanly. Data residency is where the bytes physically sit. Operational sovereignty is who can technically administer the data and from which jurisdiction. Jurisdictional immunity is whose law the provider is ultimately subject to, which is the US CLOUD Act question of whether a foreign government can compel access regardless of where the data lives. The EDPB and EDPS flagged exactly that conflict with GDPR Chapter V in their 2019 joint response on the CLOUD Act (EDPB). Conflating the three is the single most common mistake I see.

The sovereignty labels are tender requirements, not frameworks, and they attach to specific providers. SecNumCloud 3.2 is issued by ANSSI in France and is held only by French-controlled providers (OVHcloud is qualified, for example; Scaleway lists it as in progress). BSI C5:2020 is a German attestation standard (Exoscale holds a C5 Type 2 attestation). HDS covers French health data (OVHcloud and Scaleway hold it). A platform never inherits a provider's label, so do not claim one does.

Then build the artifact auditors actually want: a control-to-cloud matrix, one row per control, one column per cloud, one named evidence artifact and owner per cell, kept in git so its own history is change evidence. Spend your control budget on the Kubernetes layer, because it is the only layer whose controls are literally the same across all three providers.

How do you implement one control that works identically on AWS, GCP and a sovereign EU cloud?

The only layer that behaves the same on all three is Kubernetes plus the delivery pipeline above it, so define the control there once and let each cloud supply the primitives underneath. And make it preventive at admission time, not detective three weeks later in a report.

There are four honest control points, and the real answer is you run all of them with clear ownership:

1. Cloud-native, per provider. Maximum fidelity, maximum duplication and drift. Keep AWS Service Control Policies and GCP Organization Policies as guardrails underneath, but do not try to run your whole control story here.
2. Multi-cloud CSPM (Wiz, Prisma Cloud, Orca). One view across clouds, but it tells you after the fact, and coverage is weak where a sovereign provider has no rich API.
3. Compliance automation (Vanta, Drata). Framework mapping and evidence collection, not enforcement.
4. A Kubernetes-native platform control plane. Prevents drift at deploy time, in the same way on every cloud.

Preventive beats detective, and the distinction is concrete. An OPA Gatekeeper or Kyverno admission policy blocks the non-compliant deployment before it exists. A CSPM report tells you it already shipped and has been running. That gap matters when the 2025 breach lifecycle averaged 241 days to identify and contain (IBM). The fix you apply at admission never becomes a 241-day finding.

From there, one deployment path for everything: git as the single change record, required reviews, the same pipeline regardless of destination cloud. Per-environment RBAC defined once in the platform instead of reconciling three IAM models with three group-mapping schemes. Encryption, backups and databases delegated to the provider's certified managed services, but with the chosen setting recorded in one declarative place, so your evidence is the config, not a console tab.

How do you generate one audit trail instead of three?

Force every production change through a single pipeline that records actor, approval, artifact, target cloud and target environment, then export that one record as your primary evidence. Keep the per-cloud provider logs only as corroborating detail.

The canonical record is a git commit plus a PR approval plus a deployment event plus the target environment plus the actor identity, emitted by one system for every cloud and queryable by date range for the audit period. Underneath it, centralise the provider logs (CloudTrail, GCP Cloud Audit Logs, the sovereign provider's export) into one store, but check the residency constraint before you do, because EU-only data may not legally leave the EU and logs carry personal data.

A few things teams forget and auditors do not:

• Immutability and retention. WORM or object-lock storage, retention matched to the audit window. Twelve months covers the common SOC 2 Type II period; some EU obligations push longer.
• Access reviews. One quarterly export of who had access to which environment on which cloud, signed off by the named owner, stored next to the matrix.
• Ephemeral environments. Preview environments per pull request and non-production auto-stop both need creation and teardown evidence, or an auditor treats them as unmanaged production-adjacent systems.
• Consistent tagging. Environment, owner, data classification and residency zone on every workload, across providers. A cross-cloud inventory query is impossible without it, and inventory is control A.5.9 in ISO/IEC 27001:2022.

How do you prove data residency and sovereignty specifically?

Residency is proven with three artifacts, and never with a console screenshot: a region-pinned deployment configuration held as code and reviewed in git, a preventive policy that blocks deployment to any non-approved region, and a live inventory listing every workload and datastore with its actual region.

Region pinning as code means the proof is the config history (reviewers, timestamps, diffs) rather than a point-in-time screenshot someone took last Tuesday. The preventive guardrails are AWS Service Control Policies and GCP Organization Policy resource-location constraints, plus the sovereign provider's equivalent or a Kyverno rule where none exists.

The gaps people miss are almost always at the edges: backups and snapshots, log sinks, CI runners, SaaS observability vendors, CDN edge caches, vendor support tunnels, and the control plane of your own platform tooling. Each one can quietly move data across a border.

This is where operational sovereignty matters more than residency. The question behind "European-operated" requirements in public tenders is who can technically administer the data and from which jurisdiction, which is the CLOUD Act concern the EDPB and EDPS raised. The stakes are not hypothetical: the largest GDPR fine to date, EUR 1.2 billion against Meta in May 2023, was specifically about unlawful international transfers under Chapter V (EDPB), and GDPR enforcement has now crossed EUR 7.57 billion across more than 3,340 actions (CMS Enforcement Tracker, as of October 2026). A sovereign deployment is bought precisely to remove that transfer risk. The cleanest residency story is bring-your-own-cloud: the account, the data and the bill stay in your name, in the region you picked, and your platform never becomes a processor of your workload data.

How does Qovery give you one consistent compliance story across AWS, GCP and a sovereign EU cloud?

Qovery is a Kubernetes-native control plane that deploys into your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, including a sovereign EU one. Because the access model, the change trail and the deployment pipeline are identical no matter which cloud a workload lands on, you remove the drift that produces most multi-cloud audit findings.

Here is what that looks like against the four evidence types:

• BYOC. Workloads and data stay in your own cloud account and chosen region. The cloud bill and any Savings Plans or committed-use discounts stay in your name.
• Per-environment RBAC, defined once and applied across every cluster on every cloud, so you produce one access-review export instead of reconciling three IAM models.
• Git-push deployments. Every change carries a commit, an author and a deployment record, in the same format on AWS, GCP, Azure, Scaleway or your own cluster.
• Bring your own Kubernetes. Scaleway is natively supported; a sovereign provider like OVHcloud, StackIT, T-Systems or Exoscale is reachable by pointing Qovery at the existing cluster, and the same controls apply. That is the honest boundary, so I will not overstate it.
• Managed cluster upgrades and non-production auto-stop are themselves audit controls: patch currency and environment hygiene are things auditors sample.
• Preview environments per pull request carry the same RBAC and the same teardown record, so short-lived environments do not become an evidence hole.
• Databases backed by the provider's managed services, so encryption at rest and backup settings sit inside the already-certified service.

Let me be clear about what Qovery is not. It is not a certification, a CSPM, or a compliance-automation suite. It standardises how workloads are deployed and who can touch them. The combination I recommend is cloud-native guardrails underneath, Qovery for deployment and access consistency, a CSPM such as Wiz or Orca for cross-cloud detection, and Vanta or Drata for framework mapping and evidence collection.

How do I set this up from Claude Code or Cursor?

Install the Qovery agent skills once, then ask your coding agent in plain language to deploy into the cloud account and region you need. The agent proposes the change, you approve it, and that approval is itself a reviewable change record in git.

Install globally for every compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI):

curl -fsSL https://skill.qovery.com/install.sh | bash

Scope it to a single repository instead:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the MCP Server to Claude Code, OAuth and read-only by default, which is the right audit posture:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you explicitly want it (this also requires enabling write access in the Qovery Console):

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform) handle deployment; the MCP Server operates what already exists. Then just ask, for example "deploy this service to my GCP account in europe-west1 with Qovery", and the agent shows the plan and waits for your approval. The full walkthrough is in the AI agent quickstart and the Claude Code integration page.

How do you prove compliance consistently when your workloads span AWS, GCP and a sovereign EU cloud at the same time?

Define your controls once at the Kubernetes and delivery-pipeline layer, which behaves the same on all three clouds, rather than re-implementing each control in three consoles. Map to one control spine (ISO/IEC 27001:2022 or SOC 2), keep a single control-to-cloud matrix in git, and route every production change through one pipeline so you export one audit trail. The auditor then sees one control operating identically everywhere.

Do AWS and GCP compliance certifications cover my workloads automatically?

No. Provider certifications cover the provider's side of the shared responsibility model only. AWS is responsible for security "of the cloud" and you are responsible for security "in the cloud", including your IAM grants, namespaces, encryption settings and pipelines. AWS lists 143 security standards and certifications and Google Cloud a comparable catalogue, but none of them evidence what you deploy on top.

What counts as acceptable evidence of data residency for a GDPR, NIS2 or DORA audit?

Three artifacts: a region-pinned deployment configuration held as code and reviewed in git, a preventive policy that blocks deployment to any non-approved region, and a live inventory listing every workload and datastore with its actual region. A console screenshot is not evidence because it is a point-in-time claim with no history. Remember to cover backups, log sinks and CI runners, which are where residency quietly leaks.

Is a multi-cloud CSPM like Wiz or Orca enough, or do I need a platform layer and a tool like Vanta too?

You generally need all three, because they do different jobs. Wiz, Orca and Prisma Cloud detect misconfiguration across clouds after deployment; Vanta and Drata automate framework mapping and evidence collection; a platform layer standardises how workloads get deployed and who can access them so drift never appears in the first place. A CSPM tells you something shipped wrong, while a platform control stops it shipping.

Can I use the same RBAC and audit trail on a sovereign EU cloud that is not AWS, GCP or Azure?

Yes, if you run your controls at the Kubernetes and pipeline layer. Kubernetes RBAC and admission control are upstream-standard mechanisms that work on any conformant cluster, including a sovereign EU one. With Qovery, Scaleway is natively supported and a provider like OVHcloud, StackIT or Exoscale is reachable by connecting its existing Kubernetes cluster, so the same per-environment RBAC and git-based change trail apply there too.

How often do I need to re-collect multi-cloud compliance evidence, and how long must I retain it?

Access reviews are typically quarterly, with a signed export per environment per cloud. Operating-effectiveness evidence has to span the whole audit period, commonly 3 to 12 months for a SOC 2 Type II. Retain the immutable logs at least long enough to cover that window (twelve months is a safe floor for SOC 2), and longer where an EU obligation requires it. If evidence is generated from a system of record rather than reconstructed by hand, re-collection is a query, not a project.

The real win is boring in the best way: one control spine, one matrix in git, one audit trail, and nothing that changes because a workload happened to land on a different cloud. Try Qovery free and deploy with the same RBAC and change trail on every cloud you run.