Does Moving to a Hyperscaler Put Your ISO 27001 Certification at Risk? A Control-by-Control Answer

Key Points:

• No. Moving from a managed PaaS to AWS, GCP, Azure, Scaleway, or your own Kubernetes cluster does not invalidate an ISO/IEC 27001 certificate and does not restart the three-year certification cycle. ISO/IEC 27001 certifies your information security management system and its declared scope, not your hosting vendor. You notify your certification body of the change, update the Statement of Applicability and risk assessment, and log the migration itself as a planned change under A.8.32.
• No cloud provider can make you ISO 27001 certified. AWS, Microsoft Azure, Google Cloud, Scaleway, OVHcloud and IONOS all hold ISO/IEC 27001 for their own infrastructure, and under the shared responsibility model everything above the hypervisor (IAM, change management, logging, environment separation, patching of your clusters and images) stays inside your audit scope.
• Roughly 10 of the 93 Annex A controls in ISO/IEC 27001:2022 are produced or broken at the deployment layer: A.5.15, A.5.16, A.5.18, A.8.2, A.8.8, A.8.9, A.8.15, A.8.16, A.8.31 and A.8.32. Your platform choice decides whether that evidence exists by default or gets reassembled by hand before every surveillance audit.
• The audit burden comes from the DIY glue layer, not from the cloud. Terraform modules, CI scripts, shared IAM roles and cluster-admin kubeconfigs mean nobody can answer "who changed production on March 3rd and who approved it" from one system, and A.8.32 requires exactly that answer on demand for any date the auditor samples.
• Four layers claim to help and they are not interchangeable: hyperscalers certify infrastructure, Vanta/Drata/Secureframe collect and monitor evidence, Wiz and Orca detect misconfiguration after it exists, and the deployment control plane prevents it at deploy time. Qovery sits in that fourth layer, running in your own cloud account (BYOC) with per-environment RBAC, enforced production and non-production separation, and a deployment audit trail. Qovery is not a certification and does not replace a compliance automation tool.
• Decide your control plane at least one quarter before the audit window opens. Auditors sample evidence of operation over a period, so a control switched on two weeks before stage 2 has no history to sample and gets written up as a nonconformity.

A VP of Engineering asked me this on a call last quarter, almost word for word: "We spent nine months getting ISO 27001. If we move off our PaaS onto AWS, do we lose it?" The fear is reasonable and the answer is no. But the reason the answer is no matters more than the no itself, because it tells you exactly what you now own, and that is where the audit pain lives.

I have watched teams make this move cleanly and I have watched teams turn a routine surveillance audit into a scramble of screenshots and Slack archaeology. The difference was never the cloud provider. It was whether one system could answer the auditor's questions, or whether four systems and three people had to be assembled to answer each one by hand.

So this is a control-by-control walk through what actually changes when you leave a managed PaaS, which Annex A controls your deployment platform decides, and how the layers of tooling on the market compare on the only metric that counts at audit time: how much evidence effort each one costs you. I will name where Qovery fits and, just as plainly, where it does not.

Does moving from a PaaS to a hyperscaler put our ISO 27001 certification at risk?

No. Changing infrastructure provider does not invalidate an ISO/IEC 27001 certificate and does not restart your three-year certification cycle, because certification covers your information security management system (ISMS) and its declared scope, not your vendor's data center. What changes is your Statement of Applicability: controls your PaaS operated silently on your behalf become yours to operate, document and evidence, and you must notify your certification body of the change before the next surveillance audit.

Here is the mechanism. ISO/IEC 27001 certifies a management system against the requirements in clauses 4 to 10 and the controls you selected in Annex A. The certificate names a scope: the parts of your organization, the services, and the locations covered. It does not name "runs on Heroku" or "runs on AWS." Swap the infrastructure under the same ISMS and the certificate is intact. The thing that has to change is your documentation of how the controls are met, because the party meeting some of them just changed from your PaaS to you.

The certification itself runs on a fixed clock under the accreditation rules in ISO/IEC 17021-1. You pass a stage 1 (documentation readiness) and stage 2 (implementation) initial audit, then your certification body runs a surveillance audit roughly once a year, and you recertify in year three. A migration does not reset that clock. What it can trigger is a notification obligation: certified organizations are required to tell their certification body, without undue delay, about significant changes to scope, organization, or the infrastructure that affects the ISMS. The body decides what to do with that, and the usual outcome is that the change is reviewed at your next surveillance audit, or at most through a short special or extended audit. A full recertification from zero is not the normal response to "we changed cloud provider."

What was your PaaS quietly doing for you? More than most teams realize until they leave:

• Patching the runtime and the host underneath your app.
• Isolating tenants from each other at the network level.
• Emitting a default deployment log you never had to build.
• Enforcing separation between apps by construction.
• Giving you a coarse but real set of platform access roles.

On AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster, those become your line items:

• IAM design and least privilege.
• Cluster and node patching, including the control plane and base images.
• Secrets handling and key management.
• Network segmentation between environments.
• A deployment audit trail that attributes every change.
• Separation of development, test and production.
• Backup and restore testing you can show evidence of.

Now the trap that catches people, stated the way an auditor would recognize it: auditors assess evidence of operation over a period, not a snapshot on the day they visit. A control you switched on 10 days before stage 2 has essentially no history to sample, and "we just turned it on" is a finding, not a pass. Give any new control at least a full quarter of real operation before the evidence window.

Five ISMS documents actually change when you migrate, and if you update all five proactively you have removed most of the audit friction before it starts:

1. The scope statement, if the migration changes what is in or out.
2. The Statement of Applicability (which controls apply and how).
3. The risk assessment and risk treatment plan.
4. The supplier register, under A.5.19 to A.5.22, to add the new cloud provider and drop or keep the old one.
5. The change record for the migration itself, under A.8.32, with a named approver.

For context on how routine this all is: the ISO Survey 2024 counted 96,709 valid ISO/IEC 27001 certificates worldwide across roughly 180,000 sites. That count jumped sharply from the prior year partly because the 2024 edition drew on the IAF CertSearch database rather than voluntary reporting, so read it as "very large and growing fast," not as a clean doubling. The point stands: tens of thousands of certified organizations change infrastructure every year without surrendering their certificates. You are on a well-worn path.

Does using AWS, Google Cloud, Azure, or Scaleway make you ISO 27001 compliant?

No. Every major cloud provider holds ISO/IEC 27001 for its own infrastructure, and that certificate covers the provider's controls, not yours. Under the shared responsibility model the provider secures the cloud and you secure what you run in it, which is where almost all of your audit evidence has to come from.

The providers say this themselves, in words worth quoting back to anyone on your team who thinks a cloud logo is a compliance shortcut. AWS splits the world into "security of the cloud" (theirs) and "security in the cloud" (yours) in its shared responsibility model, and holds ISO/IEC 27001 plus 27017, 27018 and 27701, with the evidence pack available through AWS Artifact. Microsoft publishes a shared responsibility matrix that shifts the line depending on whether you buy IaaS, PaaS or SaaS, documents its ISO/IEC 27001 offering, and distributes evidence through the Service Trust Portal. Google Cloud frames it as shared responsibility and shared fate, publishes an ISO/IEC 27001 certificate with a named list of in-scope services and regions, and leaves workload configuration to you.

A provider certificate is genuinely useful, and I want to be fair about that, because it saves real work. It does two things. First, it is most of your supplier due diligence under A.5.19 to A.5.22 done for you: you attach the provider's certificate and SOC 2 report to your supplier file instead of auditing a hyperscaler yourself. Second, it materially shrinks the physical and environmental controls (the A.7.x family: physical entry, equipment siting, secure disposal) that you have to operate, because the provider operates them in their data centers. That is a real saving. Take it.

Then check the one thing that quietly voids the saving: scope. A provider ISO 27001 certificate lists specific services and specific regions. If you are using a service or a region that is not in the certified scope, the certificate does not cover it, and leaning on it in your supplier assessment is a finding waiting to happen. Before you rely on a provider certificate, confirm that every service and every region you actually use appears inside its scope.

On residency, one correction to a common assumption: data residency is a region configuration choice on every major cloud, not a property that only European providers have. You can pin AWS, Azure or GCP workloads to an EU region. What Scaleway, OVHcloud and IONOS add on top is European sovereignty positioning and, in specific cases, state-recognized credentials beyond ISO 27001, which I cover in the posture table below.

And the reason the certificate is not the control that saves you: the failures happen on your side of the line. Gartner's widely cited prediction was that through 2025, 99% of cloud security failures would be the customer's fault, driven mostly by misconfiguration. The 2025 Verizon DBIR found the human element involved in roughly 60% of breaches, with compromised credentials the single most common initial access vector at 22%. The provider's ISO certificate does nothing about any of that. Your IAM design, your environment separation and your change records do.

Which ISO 27001:2022 Annex A controls does your deployment platform actually touch?

About 10 of the 93 Annex A controls in ISO/IEC 27001:2022 are produced or broken at the deployment layer: A.5.15, A.5.16, A.5.18, A.8.2, A.8.8, A.8.9, A.8.15, A.8.16, A.8.31 and A.8.32. For these controls the platform you pick decides whether the evidence exists automatically or has to be assembled by hand in the two weeks before every audit.

First, the structure, so the numbering means something. The 2022 revision of Annex A has 93 controls grouped into 4 themes: organizational, people, physical and technological. That is down from 114 controls across 14 domains in the 2013 version, which is why older guides do not match the current numbers. If your certificate was issued against the 2013 edition, note that the transition is over: under IAF MD 26, accredited 2013-version certificates expired or were withdrawn on 31 October 2025, regardless of the expiry date printed on them. Everyone is on the 2022 numbering now.

Here is what each of the 10 deployment-layer controls means in the plain language of what an auditor actually asks for:

• A.5.15 Access control - who could deploy to production in Q2, and on what basis.
• A.5.16 Identity management - how identities are created and tied to real people.
• A.5.18 Access rights - evidence that access is granted, reviewed and revoked, including at offboarding.
• A.8.2 Privileged access rights - who holds admin, and proof it is limited and reviewed.
• A.8.8 Management of technical vulnerabilities - your patch cadence for clusters and base images.
• A.8.9 Configuration management - that running config matches declared config, with drift controlled.
• A.8.15 Logging - that the events that matter are logged and retained.
• A.8.16 Monitoring activities - that someone and something watches those logs.
• A.8.31 Separation of development, test and production - that the boundary is real, not nominal.
• A.8.32 Change management - that changes are requested, approved, recorded and reversible.

Two of these are where teams fail most often right after a hyperscaler migration, and the reasons are specific. A.8.31 fails because a naming convention is not a boundary. Calling a namespace prod- and another dev- in the same cluster with the same credentials does not separate them; one kubeconfig reaches both. A.8.32 fails because a CI log is not an approval record. "The pipeline ran" tells the auditor a change happened, not that anyone with authority approved it before it hit production.

Be honest about the limits too: no platform covers your whole certificate. Your risk assessment, your policies, the people controls in the A.6.x family, physical security in A.7.x, supplier management across A.5.19 to A.5.22, your internal audit and your management review are all yours regardless of how good your tooling is. A deployment platform cannot write your risk assessment. Anyone who tells you otherwise is selling.

Picture the failed evidence request that makes all of this concrete. The auditor says: "Show me every production change in March, with the author and the approver." On a hand-wired hyperscaler setup, you answer that from CI logs (what ran), the cloud console (what exists now), and a Slack thread (who said "ship it"). You stitch those three together for one sampled week and it takes an afternoon. The auditor samples three weeks. Even if every change was legitimate and correct, you fail the sample test, because you cannot produce one authoritative, complete record on demand. That is the whole game, and the table below is the asset to bookmark for it.

Why does a hyperscaler migration create extra audit burden, and how do you avoid it?

The extra audit burden comes from the DIY glue layer, not from the cloud provider. Terraform modules, CI scripts, kubectl access and shared IAM roles mean no single system can answer an evidence request, so every auditor question turns into a manual investigation across three or four tools and two or three people.

Walk through the five ways this shows up, because each maps to a specific control you will be asked about:

The evidence problem (A.8.32). Deploys come from CI, from a laptop running kubectl apply, and occasionally from someone clicking in the console. There is no authoritative answer to "who changed production on March 3rd and who approved it," because the record is split across systems that were never meant to be one record. A.8.32 asks for exactly that answer, for any date the auditor picks.

The access problem (A.8.2). Broad cloud IAM roles and a shared cluster-admin kubeconfig make least privilege nearly impossible to prove. In a quarterly access review you are supposed to show that each person has only what they need. "Everyone on the platform team has cluster-admin because it was easier" is the honest answer and the losing one.

The separation problem (A.8.31). Dev and prod in one account or one cluster, divided only by naming, will not survive scrutiny. The auditor will ask what stops a dev credential from reaching prod, and "we are careful" is not a control.

The drift problem (A.8.9). One console change made outside Terraform, during an incident, at 2am, breaks configuration management. You find out when the auditor compares your declared state to your running state and they do not match.

The key-person problem. A two-person platform team holding all the glue knowledge is a continuity risk an auditor can and will write up. It is also why evidence collection stalls the week one of them is on holiday.

The time cost is real and measurable. Red Hat's State of Kubernetes Security report found that around two-thirds of organizations have delayed or slowed application rollouts over Kubernetes security concerns, and roughly 40% had detected a misconfiguration in their environment. Pair that with the detection lag: IBM's 2025 Cost of a Data Breach report put the average breach lifecycle at 241 days (181 to identify, 60 to contain) and the global average cost at USD 4.44 million. A long mean-time-to-identify is the reason detect-after-the-fact is not a control strategy. If your only safeguard notices the problem months later, it was never a safeguard.

The way out is not more process. It is fewer paths. Here is the mitigation checklist, each line standing on its own:

• Make one control plane the only path to production. Everything goes through it or it does not ship.
• Back RBAC with SSO groups, so access follows identity and offboarding is one action.
• Keep immutable deploy logs that record author, commit, timestamp and target environment.
• Use separate accounts or clusters per environment, with separate credentials.
• Forbid out-of-band changes. No ad-hoc console edits, no laptop kubectl to prod.
• Document a break-glass procedure that logs every use and is reviewed monthly.

Which platforms have strong ISO 27001-aligned security and access controls built in?

Four distinct layers claim to help with ISO 27001 and they do genuinely different jobs: hyperscalers certify the infrastructure, compliance automation tools collect and monitor evidence, CSPM tools detect misconfiguration after resources exist, and the deployment control plane is the only layer that prevents misconfiguration at the moment of deploy. Most teams buy the first three and hand-roll the fourth, which is exactly where audit evidence goes missing.

Layer 1, certified infrastructure. AWS, Microsoft Azure, Google Cloud, Scaleway, OVHcloud and IONOS. All hold ISO/IEC 27001 for their infrastructure. All of them stop at the hypervisor and leave the workload layer to you. Necessary, not sufficient.

Layer 2, compliance automation. Vanta, Drata, Secureframe. These are genuinely strong at what they do: policy templates, continuous evidence collection, control monitoring, and coordinating with your auditor. They observe your systems and report on them. What they do not do is enforce anything at deploy time. They will tell you production and dev share a cluster; they will not stop the deploy that put them there.

Layer 3, cloud security posture management. Wiz, Orca Security. They scan what exists and flag misconfiguration, exposure and vulnerabilities. This is valuable and I would run one. But it is detection after the resource exists, and given a 241-day average time to identify a breach, "we would have caught it eventually" is not the same as "it never happened."

Layer 4, the deployment control plane. Qovery, Humanitec, Northflank, managed PaaS options such as Heroku and Render, or a self-built Backstage plus Terraform plus Argo CD stack. This is the layer that decides whether least privilege, environment separation and change records exist by default or not at all. It is also the layer teams most often build themselves, which is the whole problem, because a hand-built control plane is maintained by the same two people who are the key-person risk in the control above.

Where Qovery differs inside layer 4: it runs BYOC, deploying into your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster. Your data residency, your cloud contract, and any committed-spend discounts stay in your name. On top of that account, the control plane enforces per-environment RBAC, records every deployment in an audit log with author, commit and timestamp, and (for teams that want policy-as-code on the API) supports OPA-backed API Policy Tokens.

Now the limits, plainly, because this is where overselling happens. Qovery is not a certification. It is not a CSPM. It does not replace Vanta, Drata or Secureframe; most teams run a compliance automation tool alongside it, and should. And a self-built Backstage stack delivers the same deployment controls if you have a platform team to build and maintain it indefinitely, which most companies in the 30-to-150-person range do not. That maintenance burden is the reason to buy layer 4 rather than build it: Gartner projects that 80% of large software engineering organizations will have platform engineering teams by 2026, up from 45% in 2022, which tells you both that this layer matters and that most teams are still figuring out how to staff it.

How does an internal developer platform reduce ISO 27001 audit evidence work?

An internal developer platform converts recurring evidence requests into standing platform features. A quarterly access review becomes an RBAC export. Change management becomes a queryable deployment log. Separation of environments becomes a structural property of the system instead of a team convention someone has to vouch for in the audit room. Here is the control-by-control version.

A.5.15 and A.5.18, access control and access rights. Production deploy rights are granted to a named SSO group and revoked in one place at offboarding. When the auditor asks for your access review, you export it, instead of taking screenshots from four consoles and hoping they are consistent.

A.8.32, change management. Every deploy is tied to a git commit, an author, a timestamp and a target environment, and it is queryable for any date range the auditor samples. The failed evidence request from section three becomes a two-minute filter.

A.8.31, separation of environments. Distinct clusters or namespaces with distinct credentials, enforced by the platform rather than by naming conventions. You can demonstrate the boundary instead of asserting it.

A.8.8, technical vulnerabilities. Managed Kubernetes cluster upgrades run on a schedule you can show the auditor, rather than a control plane nobody has upgraded in 14 months because touching it is scary.

A.8.9, configuration management. Environment configuration is declared and versioned, so drift is visible before the audit rather than discovered during it.

A.8.15 and A.8.16, logging and monitoring. Deployment and access logs are centralized and retained, so producing logging and monitoring evidence is a query, not an archaeology project across five services.

There is a scope-integrity argument auditors respond to as well. Preview environments per pull request and automatic environment stop mean developers get the speed they want without spinning up shadow infrastructure that lives outside your declared scope. Scope creep is a real audit problem; if resources exist that your ISMS does not know about, that is a finding. A platform that makes ephemeral environments the easy default keeps your real footprint inside your documented footprint.

On residency, relevant to A.5.31 (legal and regulatory requirements) and A.5.34 (privacy and protection of PII): with BYOC, workloads and customer data stay in your own cloud account and your chosen region. That is the concrete answer you need for an EU residency commitment or a GDPR-linked obligation, because you can point to the account and the region rather than to a vendor's assurance.

And the honest limits, as a list, because an internal developer platform is not a compliance program:

• It will not write your risk assessment.
• It will not run your internal audit.
• It will not manage your supplier relationships.
• It will not train your staff.

You still need an ISMS owner who runs the management system, and most teams still want a compliance automation tool alongside the platform. The platform's job is narrow and valuable: make the deployment-layer controls produce their own evidence.

Is a managed PaaS or a hyperscaler better for passing an ISO 27001 audit?

A managed PaaS is easier to audit on day one and harder to audit at scale. A hyperscaler is harder on day one and far more defensible once you have a control plane in front of it. The deciding factor is not the provider. It is whether exactly one system can answer who deployed what, where, and when.

Where a managed PaaS wins: fewer controls in your Statement of Applicability, platform-level separation and patching inherited for free, and a faster first certification because there is simply less that you operate. For a small team going for its first certificate, that head start is real.

Where a managed PaaS runs out: coarse role models that struggle against A.8.2, limited deployment audit exports when A.8.32 wants a complete record, data residency and region constraints, subprocessor chains you have to document under A.5.19 to A.5.22, and cost that climbs steeply as you scale.

Where a hyperscaler wins: full control over residency, network segmentation, key management and log retention, plus the cloud bill and any committed-spend discounts in your own name. These matter more the larger and more regulated you get.

Where a hyperscaler hurts: the glue layer, and the fact that nothing enforces least privilege or environment separation unless you build it or buy it.

The practical rule I give every team: the audit outcome tracks the number of paths to production, not the logo on the invoice. One path is auditable. Four paths are not, no matter how good each one is in isolation. And do not forget the third answer that is often the lowest-risk move mid-certification: keep your existing Kubernetes cluster and put a control plane in front of it. You change the least and you gain the single path.

What should you do in the 90 days before the ISO 27001 audit window opens?

Pick the deployment control plane before you pick the auditor. Auditors sample evidence of operation over a period, commonly at least three months, so a control enabled two weeks before stage 2 has no history to show and will be written up as a nonconformity. Run this order:

1. Define scope and write the Statement of Applicability against the target architecture, the one you are moving to, not the PaaS you are leaving. Documenting the system you are about to retire is wasted effort.
2. Choose the cloud on data residency and commercial terms, not on compliance badges. AWS, GCP, Azure, Scaleway, OVHcloud and IONOS are all certified, and keeping your existing Kubernetes cluster is a valid answer. The badge does not differentiate them for your audit; the terms and the region do.
3. Choose the deployment control plane and make it the only path to production. Remove ad-hoc kubectl and console access, and document a break-glass procedure that logs every use.
4. Wire SSO and groups, split production from non-production roles, and run one full access review before the evidence window starts, so you enter the window with a clean baseline.
5. Plug in a compliance automation tool such as Vanta, Drata or Secureframe for evidence collection, policy management and auditor coordination. The platform produces the evidence; the automation tool organizes and reports it.
6. Migrate non-critical services first, keep the old platform running in parallel, and log the migration as a planned change under A.8.32 with a named approver. The migration itself is auditable; treat it that way.
7. Let the system run for a full quarter before stage 2 so there is a history to sample, then run an internal audit against the same sample questions your auditor will ask. If you cannot pass your own sample test, you are not ready for theirs.

One timing note so you plan realistically: a first ISO 27001 certification for a mid-sized SaaS company typically takes several months of ISMS build-out before stage 1, plus the operating period before stage 2. Get the sizing from an accredited certification body (BSI, DNV, Schellman, A-LIGN) rather than from vendor marketing, because it depends heavily on your starting maturity. The one constant is that the operating period is not compressible: the control has to actually run for the auditor to sample it.

Change the cloud. Keep the certificate. The work is in making sure that after the move, one system can still answer the auditor's questions on the first ask.