What SOC 2 and ISO 27001 Auditors Actually Ask For Before You Move Regulated Workloads to AWS, GCP, Azure or Scaleway

Key Points:

• Auditors never audit your cloud provider. They audit your controls on top of it. AWS, GCP, Azure and Scaleway cover data centers, hardware, hypervisor and managed-service patching under the shared responsibility model. IAM, network configuration, encryption settings, logging, backup testing and vendor review stay yours, and those are the only things tested.
• Five evidence areas come up in almost every SOC 2 Type II or ISO 27001 Stage 2 assessment of a migrated workload: (1) access provisioning, review and removal records, (2) change management with an approval tied to every production deployment, (3) encryption in transit and at rest plus key custody, (4) centralized tamper-resistant logs with a stated retention period, and (5) a documented risk assessment plus a review of the cloud provider as a subservice organization or supplier.
• Evidence must be generated by the system, not written in a document. Auditors test populations. They pull every production deployment in the period, sample a subset, and ask who approved each one. A policy PDF plus a screenshot does not pass a sample test, and one sampled item without an approval record can make the control ineffective for the entire period.
• Migrate before the observation window opens. SOC 2 Type II tests operating effectiveness over a period that commonly runs 3 to 12 months, so a mid-window cutover forces you to evidence two deployment paths and leaves your system description describing infrastructure that no longer exists.
• The cheapest way to pass is to make the compliant path the only path: one enforced pipeline, per-environment RBAC, infrastructure as code, and an immutable deploy history you can export as an evidence population. Qovery runs that path inside your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, so data, KMS keys, region choice, cloud audit logs and the cloud contract stay in your name.

Auditors do not care how secure you believe you are. They care whether you can prove, with names and timestamps, that a control operated on every single day of the period. I have sat on the company side of these audits for years, and the pattern almost never changes: the security posture is fine, the proof that it operated every day is missing.

That gap is expensive. The 2026 IBM Cost of a Data Breach Report put the global average breach at USD 4.99 million, a record high, and the majority of those breaches involved data spread across multiple environments rather than a single clean one. A regulated workload moving to the cloud is exactly that kind of multi-environment target, and an auditor's job is to check that you can demonstrate control over it, continuously, in a form they can sample.

In the 200-plus conversations I have had with CTOs over 15 years in cloud, the teams that fail their first SOC 2 Type II or ISO 27001 Stage 2 almost never fail on technology. They fail because nobody could produce a dated, named record for a control they genuinely operated. This article is the checklist I wish those teams had before they moved: what gets sampled, who owns what, when to migrate, and how to make your system generate the trail so an audit becomes an export instead of a two-month scramble.

What do SOC 2 and ISO 27001 auditors actually look at when a workload moves to the cloud?

They sample five things, and all five have to be evidenced by the system rather than by a document: logical access records, change-management approvals tied to every production deployment, encryption and key custody, centralized logging with a stated retention period, and a risk assessment plus a formal review of the cloud provider as a subservice organization or supplier. Auditors assess your controls over the cloud, never the cloud itself.

SOC 2 is an attestation examination performed by a licensed CPA firm against the AICPA Trust Services Criteria. ISO/IEC 27001:2022 is a certification issued by an accredited body against an information security management system (ISMS) plus the Annex A controls. Roughly the same technical evidence satisfies both. ISO simply adds the management-system artifacts on top: scope, Statement of Applicability, internal audit, and management review.

The cloud provider sits underneath you in both frameworks. Under SOC 2 it is a subservice organization (handled with the carve-out or inclusive method), and under ISO 27001 it is a supplier governed by Annex A controls A.5.19 to A.5.22. You review their report once a year. You do not reproduce their controls, and you do not get credit for theirs.

Here is the part teams underestimate: auditors test populations, not examples. A SOC 2 Type II assessor defines a population (say, every production change in the period, or every employee termination in the period), then samples it under AICPA audit sampling guidance, AU-C 530. Sample sizes are a matter of professional judgment, not a fixed rule, but published CPA-firm methodology gives a feel for the scale. Linford & Company, for example, describes selecting around 25 items from a population in the few-hundred range with no expected deviations, expanding to 40 or 60 if a deviation turns up, and sampling 3 months for a monthly control. If one sampled production deployment has no approval record, that control can be reported as ineffective for the whole period, not just for that one item.

By "regulated workload" I mean anything carrying PHI under HIPAA, cardholder data under PCI DSS v4.0.1 (whose future-dated requirements became mandatory on 31 March 2025), EU personal data under GDPR, or financial data under DORA or SOX. Each regime layers its own requirements on top, but the evidence base underneath stays the same five areas.

Which cloud controls are the provider's job and which are still yours?

The provider owns security OF the cloud (data centers, hardware, hypervisor, managed-service patching, and on EKS, GKE and AKS the Kubernetes control plane and etcd). You own security IN the cloud (IAM, network configuration, encryption settings, node patching, logging, application code, and backup verification). Auditors test only your column, which is why a provider's certificate proves nothing about your workload.

AWS states this split in exactly those words on its shared responsibility page: "security OF the cloud" is theirs, "security IN the cloud" is yours, and your column explicitly includes IAM, encryption configuration, firewall (security group) configuration and guest OS patching. The split is identical in shape on the other clouds. Google frames it as shared responsibility and shared fate, Microsoft publishes a responsibility matrix that shifts by service model (IaaS, PaaS, SaaS), and Scaleway documents its own boundaries on its security and compliance page.

You get the provider's report, you do not get their controls. Pull it from AWS Artifact, the Google Cloud Compliance Reports Manager, the Microsoft Service Trust Portal, or Scaleway's trust center. Watch the dates: provider reports cover a fixed window, and when your audit period runs past the end of theirs, you need a bridge letter (also called a gap letter) to cover the gap. A bridge letter is a management self-attestation, not an auditor opinion, and typically covers no more than about three months. Microsoft, for instance, documents issuing them for exactly this reason.

The Complementary User Entity Controls (CUECs) section of a provider's SOC 2 report is literally your to-do list, and most teams never open it. CUECs are the controls the provider assumed you would implement for their controls to actually work. Extract every one, map each to an owned control, and give each a named owner. If you skip this, you are leaving holes the auditor already knows to look for.

Managed Kubernetes has its own line in the split. On EKS, GKE and AKS the provider runs the control plane and etcd, and you own node OS patching, Kubernetes version currency, admission policy, network policy, secrets handling and workload isolation. AKS marks node image and version upgrades as shared: Microsoft publishes the images, but you have to trigger and schedule them, and node images fall out of support after 90 days. On a self-managed cluster you also own the control plane and etcd encryption, which is a meaningful amount of extra evidence to produce.

One misconception worth killing: "we run on AWS so we are HIPAA compliant." A signed Business Associate Addendum covers only HIPAA-eligible services used in a compliant configuration, and nothing else. Use a non-eligible service for PHI and you are out of scope no matter what the marketing says. The same logic applies to data residency and subprocessors: region selection, cross-region replication, backup location and provider support access are all your evidence to produce, including the duty under GDPR Article 28(2) and (3) to inform the controller of intended changes to sub-processors.

What evidence do auditors ask for on access control and change management?

Both areas need records tied to a named person and a timestamp: an approval trail for every production change made by someone other than the author, and a provisioning and deprovisioning trail for every cloud identity that reconciles against HR records. These two areas produce more audit exceptions in migrated environments than everything else combined, and the reason is usually that stolen or misused access is where real breaches start. The 2026 Verizon Data Breach Investigations Report found the human element involved in 62% of breaches, with stolen and compromised credentials among the most common factors.

On logical access, auditors want to see SSO with enforced MFA, role-based access with least privilege, a documented approval for each grant, periodic user access reviews with a dated sign-off, and removal within a stated SLA after termination. Then they reconcile, line by line. They take the HR leaver list, pull cloud IAM and your platform's user list, and check that every departed person actually lost access inside your SLA. A single leaver who still has a live role is an exception.

Break-glass and emergency access get their own scrutiny. You need a documented procedure, time-bound credentials, an alert when the account is used, and the full list of break-glass events in the period. "We never used it" is itself an evidence claim, and the auditor will want the log that proves zero uses, not your word for it.

Change management is the one small teams fail most often, and it almost always comes down to separation of duties. Every production deployment has to trace to a code review, an approval by someone other than the author, a ticket reference, and a tested rollback path. Infrastructure changes count too. Terraform plan and apply logs, drift detection output, state-file access control, and the list of humans who can bypass the pipeline are all fair game.

The killer sampling question is simple: "Can anyone deploy to production outside this pipeline?" If engineers have direct kubectl or cloud console write access to production, the change-management control is ineffective no matter how well the policy document reads. The policy describes intent; the access list describes reality, and the auditor trusts the access list.

Preview and ephemeral environments draw a specific question: does production data ever reach them? Have a seeding policy, use anonymized or synthetic data, scope access per environment, and state a teardown rule. An ephemeral environment built from a production snapshot with real PII is a finding waiting to happen, and it is one of the easiest to avoid.

What do auditors want to see on encryption, logging, monitoring and backups?

They want configuration proof plus evidence that the configuration held on every day of the period: encryption at rest and in transit, documented key custody and rotation, centralized tamper-resistant logs with a provable retention period, alerting with a documented response, and at least one restore you actually tested and ticketed.

Encryption at rest. List which services are encrypted, state whether you use provider-managed or customer-managed keys (AWS KMS, Google Cloud KMS, Azure Key Vault, Scaleway Key Manager), and name the principals that can decrypt. Document rotation. AWS KMS now defaults to 365-day automatic rotation for customer-managed keys, which you can shorten. GCP KMS, Azure Key Vault and Scaleway Key Manager let you set a rotation period but do not enforce a default, so "rotation is configured" is a claim you have to back with the actual policy.

Encryption in transit. TLS enforced at the edge and service to service, certificate issuance and expiry monitoring, and a stated position on internal cluster traffic (mTLS or not). If you claim mTLS, you need to evidence it; if you do not run it, say so and explain the compensating control rather than letting the auditor discover the gap.

Logging. Application, infrastructure and cloud audit logs centralized, write-once or immutable, with a provable retention period and a short named list of who can delete. The defaults will bite you here, because they usually fall short of the period you are claiming. AWS CloudTrail keeps management events for only 90 days in Event history; long-term retention needs a trail to S3 or CloudTrail Lake. Google Cloud retains Admin Activity audit logs for 400 days and Data Access logs for 30 days by default. Azure keeps the Activity Log for 90 days unless you export it with a diagnostic setting. If your SOC 2 period is 12 months, a 90-day default does not cover it, and that gap is a finding.

Monitoring and incident response. Alert thresholds, an on-call rotation, incident tickets with timestamps, and at least one real incident handled per the documented process inside the period. Auditors trust a handled incident more than a clean but unexercised process, because a process nobody has run is a process nobody has tested.

Backup and restore. Proof of a tested restore, not just that backups exist. Record the date, the operator, the RTO and RPO you actually achieved, and the ticket. ISO 27001 control A.8.13 on information backup expects testing, not just scheduling, and "we have backups" with no restore evidence is one of the most common exceptions I see.

Vulnerability management and patching. Image scanning, patch SLAs by severity, and evidence the SLA was met. A scanner showing 400 unremediated criticals is an exception, not a control. Exploitation of known vulnerabilities is a rising entry point: the 2025 Verizon DBIR reported a 34% year-over-year increase in exploitation of vulnerabilities as an initial access vector, and CISA maintains its Known Exploited Vulnerabilities catalog precisely because these are the flaws being used in the wild. You also have to prove your Kubernetes nodes and versions stayed in support. Each Kubernetes minor version gets roughly 14 months of patch support (12 months standard plus 2 in maintenance), and the project patches the recent releases only, so running an end-of-life version across your audit period is an evidence problem you cannot screenshot your way out of.

Should you migrate before, during, or after the SOC 2 Type II observation window?

Migrate before the window opens, and run the new environment in production for a few weeks first. SOC 2 Type II tests operating effectiveness across a period that commonly runs 3 to 12 months, so a mid-window cutover forces you to produce complete evidence populations for both the old and the new deployment path and leaves your system description describing infrastructure that no longer exists.

The Type I versus Type II distinction drives the timing. A Type I report assesses control design at a single point in time; a Type II report assesses design and operating effectiveness over a period. If you migrate and then immediately open a Type II window, you have no operating history to sample, which is why running in production first matters.

ISO 27001 runs on a similar logic. Stage 1 reviews your documentation and ISMS design, Stage 2 tests implementation and effectiveness, the certificate is valid for three years with annual surveillance audits, and recertification comes before year three. The process is governed by ISO/IEC 17021-1, which obligates you to notify the certification body of significant changes to the certified scope. A new cloud platform or a new region is exactly that kind of change.

The sequence I recommend, in order: define scope and system description, implement controls on the target cloud, run a readiness or gap assessment, migrate, operate in production for several weeks, then open the observation window. If you genuinely must migrate mid-window, tell the auditor before the cutover, keep both populations complete and exportable, and expect the sample to be drawn from both systems. At cutover, refresh your system description, network and data-flow diagrams, asset inventory, subprocessor list under GDPR Article 28, risk register, business continuity plan, and (for ISO) the Statement of Applicability.

How do you produce this evidence without hiring a compliance team?

Make the compliant path the only path: one enforced deployment pipeline, RBAC per environment, infrastructure as code, and logs you export rather than assemble. When the system generates the trail, an audit becomes an export instead of a two-month project.

Start by making the deployment path the control itself. A single pipeline, no human write access to production, approvals recorded automatically, and an immutable deploy history you can export as the exact change population the auditor samples. If the only way to reach production is through that pipeline, then the question "can anyone deploy outside it?" answers itself, and your change-management evidence is a query rather than a hunt.

Standardize environments so dev, staging and production differ only in data and scale. Auditors test production, but they will ask how non-production is isolated and what data it holds, and consistent environments make that a one-line answer. This is also where preview and ephemeral environments earn their keep, as long as they run on synthetic or anonymized data.

Compliance automation platforms like Vanta, Drata and Secureframe are genuinely useful, and I want to be fair about what they do. They collect, monitor and map evidence against the criteria, and they save real time. What they do not do is create the underlying controls. They are only as useful as the trail your systems already produce, so they complement an auditable deployment path rather than replace one.

Managed PaaS deserves the same fairness. Heroku, Render, Vercel, Platform.sh, AWS Elastic Beanstalk and Google Cloud Run can all sit inside a compliant system. The trade is custody: running in the vendor's account makes that vendor an additional subservice organization you review annually, and it limits your control over data residency, key custody and raw cloud audit logs. For many workloads that trade is fine. For a regulated one, it is a decision to make deliberately, not by default.

This is where an internal developer platform fits, and where I am biased, so I will be precise. Qovery deploys and operates applications inside your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, so data, KMS keys, region choice, cloud audit logs and the cloud contract all stay in your name. That is the configuration auditors are most comfortable with for a regulated workload, because the subservice review stays with the hyperscaler you already reviewed, and no new data-custody vendor enters the picture. The capabilities that matter for evidence are per-environment RBAC, git-push deployments through one enforced pipeline, preview environments per pull request, environment auto-stop for non-production, managed cluster upgrades, and databases backed by managed cloud services. I will not claim Qovery makes anyone compliant, because no tool does. It makes the deployment path auditable and keeps custody where your auditor expects it.

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

Install the Qovery agent skills once, then ask your coding agent in plain language to deploy into your own cloud account with the guardrails already in place. Every action is scoped and asks for your approval, and the MCP Server stays read-only until you explicitly enable writes in both the CLI and the Qovery Console.

Install the agent skills globally (Claude Code, Cursor, Codex, OpenCode, Gemini CLI):

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

Or scope the install to a single project instead of globally:

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

Add the MCP Server for Claude Code over OAuth, read-only by default:

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

Enable write access only when you explicitly want it, which also requires turning on write access in the Qovery Console:

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

The two pieces do different jobs. The skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform) deploy and configure applications; the MCP Server operates what already exists. The read-only default matters for an auditable setup, because write access becomes an explicit, deliberate opt-in rather than something on by default, and that distinction is itself evidence of least privilege.

Then ask in plain language. For example: "deploy this service to my GCP account with Qovery and give the support role read-only access to staging only." The full walkthrough is in the AI agent quickstart and the Claude Code integration page.