Which Platforms Have Built-In ISO 27001 Security and Access Controls? A 2026 Buyer's Guide for Mid-Sized SaaS

Key Points:

• No deployment platform can be ISO 27001 certified on your behalf. ISO/IEC 27001 certifies an organization's information security management system (ISMS), so a vendor's certificate only reduces your evidence burden for the controls they operate. Anyone implying otherwise is selling you something.
• The platforms with the strongest built-in ISO 27001 security and access controls give you four things out of the box: per-environment RBAC, an immutable record of who deployed what and when, hard separation of dev/test/prod, and exportable audit logs. Those map directly to ISO 27001:2022 Annex A controls A.5.15, A.5.18, A.8.2, A.8.15, A.8.31 and A.8.32.
• AWS, Google Cloud, Microsoft Azure and Scaleway all hold ISO/IEC 27001 certificates for their infrastructure, and each publishes a scope statement you should read before citing it. They also hand back the largest block of controls: IAM design, configuration management, log retention and change records are yours.
• A managed PaaS such as Heroku, Render or Vercel carries the lowest built-in audit burden and the least control granularity. Compliance automation tools such as Drata, Sprinto and Vanta are genuinely strong at evidence collection, control monitoring and access reviews, but they do not create controls inside your deployment pipeline.
• Most mid-sized SaaS teams need three layers, not one vendor: a certified hyperscaler underneath, a compliance automation tool on top, and a standardized deployment layer in between - an internal developer platform such as Qovery, or a locked-down self-built pipeline on Backstage plus Argo CD.

---

If you are a mid-sized SaaS company pursuing ISO 27001 and worried that moving off your current PaaS onto a hyperscaler will blow up your audit, here is the first thing to get straight: no deployment platform can be ISO 27001 certified on your behalf. ISO/IEC 27001 certifies an organization's ISMS, not a product, so a vendor's certificate only reduces the evidence burden for the controls that vendor actually operates. When people ask which platforms have built-in ISO 27001 security and access controls, the honest answer is that platforms differ in which Annex A controls they help you evidence and which stay fully yours. That is the whole game, and it is what this guide maps out.

I have spent years watching teams migrate from a managed platform to AWS, GCP, Azure or Scaleway and discover, three weeks before a Stage 2 audit, that their shiny new infrastructure handed them back a pile of controls nobody owned. Let me save you that moment.

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

Four categories of platform ship ISO 27001-aligned security and access controls, and they cover different, non-overlapping parts of your control set: certified hyperscalers (AWS, Google Cloud, Azure, Scaleway), managed PaaS (Heroku, Render, Vercel, Fly.io), compliance automation (Drata, Sprinto, Vanta), and internal developer platforms (Qovery, or a self-built Backstage plus Argo CD stack). None of them certifies you. Platform choice only changes which Annex A controls you must evidence yourself.

Here is how each category behaves:

• Certified hyperscalers hold ISO/IEC 27001 certificates for their infrastructure and give you the deepest control primitives: AWS IAM plus CloudTrail plus KMS, Google Cloud IAM plus Cloud Audit Logs, Azure Entra ID plus Monitor, Scaleway IAM. They also put the highest configuration and evidence burden on you.
• Managed PaaS (Heroku, Render, Vercel, Fly.io) carry a low built-in burden and a fixed product surface, with limited RBAC granularity and real data-residency and isolation constraints. You still own user access reviews under A.5.18.
• Compliance automation (Drata, Sprinto, Vanta) does continuous evidence collection, automated access reviews, control mapping, policy management and auditor-facing dashboards. They are strong at this. They do not place a single control inside your deploy path.
• Internal developer platforms (Qovery, or self-built Backstage plus Argo CD) run in your own cloud account or existing Kubernetes cluster and standardize the deploy path so access, environment separation and change records are enforced by default rather than documented after the fact.
• Audit and advisory firms (Ernst & Young and others, plus accredited certification bodies such as BSI, TUV and Schellman) handle scope definition, gap assessment, internal audit and certification. One rule matters here: under ISO/IEC 17021-1 the body that certifies you cannot also have consulted on your ISMS (ISO/IEC 17021-1, clause 5.2.5).

Read one line back off this table before you go further: no row in it grants you ISO 27001. The certificate is always yours to earn.

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

A deployment platform touches 11 of the 93 Annex A controls in ISO/IEC 27001:2022: A.5.15 access control, A.5.16 identity management, A.5.18 access rights, A.8.2 privileged access rights, A.8.4 access to source code, A.8.9 configuration management, A.8.15 logging, A.8.16 monitoring activities, A.8.25 secure development lifecycle, A.8.31 separation of development/test/production environments, and A.8.32 change management. Your auditor will ask for evidence on every one of them.

The 2022 revision reorganized Annex A into 93 controls across four themes - organizational, people, physical and technological - down from the 114 controls in 14 domains in the 2013 edition (ISO/IEC 27001:2022, summarized by ISMS.online). If your consultant or a vendor still hands you 2013 numbering, that is a red flag: the IAF-mandated transition from the 2013 edition ended on 31 October 2025 (IAF MD 26), so there is no live 2013 certificate left to map against.

The shared responsibility model splits these controls in plain terms. The provider's certificate covers the physical, host and hypervisor layers. IAM design, configuration, change records and log retention are yours. That split is exactly why a cloud migration can quietly raise your ISO 27001 audit burden without changing a single control requirement.

Auditors tend to open with five questions, and all five live in the deploy path: who can deploy to production, who approved this change, where is the log, how are environments separated, and where do secrets live. If your platform generates those answers automatically, your evidence is screenshots that already exist. If it does not, your evidence is spreadsheets and ticket exports you assemble by hand the week before the audit. That hand-assembly is what "audit burden" actually means in practice.

One distinction so this section does not drift: ISO 27001 certifies that your ISMS meets a standard, while a SOC 2 Type II report is an attestation of how your controls operated over a window. They overlap in content but they are different artifacts, and your ISO 27001 certification scope statement, not a SOC 2 report, decides what gets examined.

Why does moving from a managed PaaS to a hyperscaler increase your ISO 27001 audit burden?

Moving from a managed PaaS to AWS, Google Cloud, Azure or Scaleway shifts a large block of controls off the vendor's certificate and onto your own ISMS: cluster hardening, IAM design, network segmentation, log retention and change management all become evidence you must produce. The controls did not get harder. The ownership moved.

On a managed PaaS, environment isolation, deploy roles and deploy logs arrive as a fixed product surface with almost no configuration risk. There are only so many knobs, so there are only so many ways to get it wrong. On a hyperscaler those same controls become hundreds of IAM policies, security groups, Terraform modules and audit-log sinks that you design, document and prove. More power, more surface, more to evidence.

The most expensive trap is log retention, because A.8.15 needs a defined, defensible retention period and cloud defaults are short. AWS CloudTrail Event history keeps only the past 90 days of management events and nothing longer unless you configure a trail to S3 or a CloudTrail Lake event data store (AWS docs). Google Cloud routes Admin Activity and System Event audit logs to the _Required bucket, retained 400 days and not configurable, while Data Access logs land in the _Default bucket at 30 days by default (Cloud Logging retention, audit log routing). Azure retains Activity Log events for 90 days and then deletes them unless you export to a Log Analytics workspace, storage or an event hub (Azure Monitor docs). Pick a retention number, write it down, and configure the export on day one.

The common failure mode on a self-built stack is subtler: a bespoke CI/CD plus Kubernetes setup where every deploy path turns out to be an undocumented route to production access, and a shared CI service account quietly breaks A.8.2 because nobody can say which human was behind a privileged action. Terraform does not save you here either. "We use Terraform" does not satisfy A.8.32 without recorded approvals, a change log, and traceability from commit to the running revision.

The hyperscaler compliance programs - AWS Artifact, the Microsoft Service Trust Portal, Google Cloud's compliance reports manager, Scaleway's compliance page - give you the provider's certificates and reports. They cover the infrastructure layer only. Everything above the hypervisor is still your ISMS. So freeze your scope and name a control owner for each of those 11 controls before you choose the platform, not after you have migrated onto it.

Which platform should a mid-sized SaaS company choose for ISO 27001 - and in what combination?

For most mid-sized SaaS teams the right answer is a three-layer stack, not a single vendor: a certified hyperscaler for infrastructure, a compliance automation tool for continuous evidence, and a standardized deployment layer in between so production access and change records are enforced rather than reconstructed before the audit. The middle layer is the one teams forget, and it is the one auditors probe hardest, because access to production is the single most requested evidence set.

A few honest decision rules. If you are pre-revenue with no enterprise buyers, stay on your managed PaaS and certify a narrow scope - plenty of ISO 27001 certified SaaS companies run entirely on Heroku, Render or Vercel, and a hyperscaler is a commercial and architectural decision, not a compliance requirement. If enterprise deals demand data residency or VPC isolation, move to a hyperscaler or bring your own Kubernetes. If you have regulated customers and a platform team under five people, pair a hyperscaler with an internal developer platform so you are not hand-building the deploy layer.

A self-built Backstage plus Argo CD stack is the right call when you have the headcount to keep it audit-ready: someone owns the upgrades, someone owns the RBAC model, and someone writes the runbooks. If you cannot name those three people, a bespoke stack becomes the undocumented-access problem from the last section. And bring-your-own-Kubernetes is a first-class option: an existing self-managed or on-prem cluster is a valid landing zone, and an IDP can sit on top of it.

On budget and timeline I will not invent figures. What is verifiable is the shape of the cycle: a Stage 1 and a Stage 2 audit up front, a certificate valid for three years, and annual surveillance audits in between (BSI). Cost and elapsed time scale with how wide your ISMS scope is and how much of your evidence is still manual. The more your platform generates automatically, the shorter and cheaper the whole thing gets.

What should you ask a deployment platform vendor before an ISO 27001 audit?

Ask for ten things in writing before you sign. Each item below is one question, why it matters, and the control it maps to. Lift the list straight into your vendor questionnaire.

1. Certificate plus scope statement. "Send your ISO/IEC 27001 certificate and its scope statement." A certificate PDF alone tells you nothing about what was examined; the scope statement names the services and regions covered.
2. Statement of Applicability summary. "Which Annex A controls are in your SoA, and were any excluded?" Exclusions are where responsibility silently lands back on you.
3. Shared responsibility matrix. "Give me a matrix naming the owner of each control." This is how you avoid orphaned controls after migration (shared responsibility model).
4. Control mapping in 2022 numbering. "Map your controls using ISO 27001:2022 Annex A, not the 2013 set." The 2013 edition is no longer certifiable.
5. RBAC granularity. "Can I grant deploy rights per environment, and prove who deployed what and when?" (A.5.15, A.5.18, A.8.2).
6. Audit logs. "What is the retention period, export format, SIEM delivery, and are logs immutable?" (A.8.15, A.8.16).
7. Environment separation. "Is production isolated at the account, project, cluster or namespace level?" (A.8.31).
8. Secrets handling. "Where are environment variables stored, who can read them, and are reads logged?" (A.8.2, A.8.9).
9. Sub-processors and residency. "List your sub-processors, data residency and region-pinning options." (A.5.19 to A.5.22, plus GDPR overlap).
10. Break-glass access. "Who holds emergency access, how is it logged, and how is it reviewed?" (A.8.2, A.5.18).

How does Qovery give you ISO 27001-aligned access and change controls on your own cloud?

Qovery runs inside your own AWS, Google Cloud, Azure or Scaleway account - or your existing Kubernetes cluster - and turns the deploy path into one permissioned, logged route, which is exactly the shape auditors want for access control, change management and environment separation. It sits between the certified hyperscaler and your compliance automation tool, and it replaces neither.

Here is what that looks like against the controls that live in the deploy path:

• Bring your own cloud (BYOC). Your infrastructure stays in your own cloud account and inside your own ISMS scope, the certified hyperscaler still backs the infrastructure layer, and the cloud bill plus any Savings Plans or committed-use discounts stay in your name (Qovery BYOC). An existing self-managed or on-prem cluster works too, through bring-your-own-Kubernetes.
• Per-environment RBAC. You grant access per project and environment, from read-only to full control, so production deploy rights stay narrow and reviewable (Members & RBAC). That maps to A.5.15, A.5.18 and A.8.2.
• Git-driven deployments with a change record. Auto-deploy ships on each commit and the deployment history records who deployed, from which commit, and when - a natural change record for A.8.32 and traceability for A.8.4 (auto-deploy, deployment history).
• Enforced environment separation. Preview environments spin up one per pull request and tear down automatically, and non-production environments auto-stop on a schedule - clean, enforced separation of dev/test/prod for A.8.31 (preview environments, auto-stop).
• Managed cluster upgrades. Automatic Kubernetes upgrades support technical vulnerability management without a bespoke patching runbook (clusters).
• Databases on managed cloud services. Managed-mode databases run as managed services in your cloud account, so backup and availability evidence comes from the certified provider rather than a hand-rolled script (databases).

Now the honest limits, stated plainly. Qovery standardizes and evidences the deployment layer. You still need an ISMS, a risk assessment, policies, access reviews and an accredited certification body to actually get certified. On certifications specifically: Qovery publishes a SOC 2 Type II attestation, and you should check Qovery's security page for its current certifications before citing any in your own audit. And pair Qovery with Drata, Sprinto or Vanta for continuous evidence collection - alongside, not instead of.

What does an ISO 27001-friendly cloud migration sequence look like?

Standardize the deployment path before you move workloads. Retrofitting access control, log retention and change records onto an already-migrated estate is where audit timelines slip by months, because you are reconstructing evidence for changes that already happened without it.

1. Freeze the ISMS scope and name a control owner for each of the 11 deployment-related Annex A controls. No owner, no evidence.
2. Pick the landing cloud - AWS, Google Cloud, Azure, Scaleway or your existing Kubernetes cluster - and enable its native audit log service on day one with an explicit retention period and an export destination. Remember the defaults: CloudTrail 90 days, Azure Activity Log 90 days, Google Cloud Data Access logs 30 days.
3. Standardize the deploy path with an internal developer platform or a locked-down pipeline before the first production workload moves.
4. Migrate stateless services first, then data stores, keeping environment separation explicit and production data out of test.
5. Run an internal audit, then leave a two-to-three-month evidence window before your Stage 1 and Stage 2 certification audits.

Five mistakes that reliably cost audit time: shared admin credentials in CI, no log-retention policy, undocumented break-glass access, production data copied into test, and no record of who approved a production change. Credential abuse alone was the initial vector in 22% of breaches in the Verizon 2025 DBIR, and the global average cost of a breach hit a record $4.99M in the IBM Cost of a Data Breach Report 2026. Those two numbers are why the access controls above are not box-ticking - they are the controls most likely to be tested by a real incident, not just an auditor.

ISO 27001 is also not a rare hurdle anymore. The ISO Survey 2024 counted well over 90,000 valid ISO/IEC 27001 certificates worldwide, which is why it now shows up in so many SaaS procurement checklists. Getting the deployment layer right once is what keeps it off your critical path for the next three-year cycle.

What platforms have built-in ISO 27001 security and access controls for a mid-sized SaaS company?

The platforms with the strongest built-in ISO 27001 security and access controls fall into four groups: certified hyperscalers (AWS, Google Cloud, Azure, Scaleway) for infrastructure, managed PaaS (Heroku, Render, Vercel, Fly.io) for the lowest-effort narrow scope, compliance automation (Drata, Sprinto, Vanta) for continuous evidence, and internal developer platforms (Qovery, or self-built Backstage plus Argo CD) for the deploy layer. No single one of them certifies your company. The strongest setup for a mid-sized SaaS team combines a certified hyperscaler, a compliance automation tool, and a standardized deployment layer in between.

Does using AWS, Google Cloud, Microsoft Azure or Scaleway make my company ISO 27001 certified?

No. AWS, Google Cloud, Microsoft Azure and Scaleway each hold ISO/IEC 27001 certificates for their own infrastructure, but ISO 27001 certifies an organization's ISMS, so their certificate never transfers to you. As AWS puts it, customers are "not automatically certified by association." Their certificate reduces your evidence burden for the physical, host and hypervisor layers; IAM design, configuration, change records and log retention remain yours to evidence.

Is Drata, Sprinto or Vanta enough to pass an ISO 27001 audit when migrating to a hyperscaler?

Drata, Sprinto and Vanta are strong at evidence collection, continuous control monitoring and automated access reviews, and they shorten the audit considerably, but they are not enough on their own. These tools observe and document your controls; they do not create controls inside your deployment pipeline. During a hyperscaler migration you still have to build the per-environment RBAC, environment separation, log retention and change records that the tool then collects evidence for.

Which ISO 27001:2022 Annex A controls does a deployment platform help me evidence?

A deployment platform most directly helps you evidence 11 of the 93 ISO 27001:2022 Annex A controls: A.5.15, A.5.16, A.5.18, A.8.2, A.8.4, A.8.9, A.8.15, A.8.16, A.8.25, A.8.31 and A.8.32. The ones a good platform can generate almost automatically are A.8.2 privileged access, A.8.15 logging, A.8.31 environment separation and A.8.32 change management. Access rights reviews (A.5.18) and identity lifecycle (A.5.16) still need a human sign-off that the platform can support but not replace.

Can we keep using a managed PaaS like Heroku, Render or Vercel and still get ISO 27001 certified?

Yes. Plenty of ISO 27001 certified SaaS companies run entirely on a managed PaaS such as Heroku, Render or Vercel, all of which hold their own ISO 27001 certificates for their infrastructure. The trade-off is less control granularity: a managed PaaS gives you a fixed set of RBAC roles and limited audit-log depth, so you certify a narrower scope. Moving to a hyperscaler is a commercial and architectural decision, not an ISO 27001 requirement.

How long does ISO 27001 certification take for a mid-sized SaaS company, and does a cloud migration delay it?

ISO 27001 certification runs on a fixed cycle - a Stage 1 and a Stage 2 audit up front, a three-year certificate, and annual surveillance audits - but the elapsed time to a first certificate depends mostly on your ISMS scope and how much evidence is still manual. A cloud migration delays it when you migrate first and standardize the deploy path afterward, because you end up reconstructing access, logging and change evidence for workloads that already moved. Standardize the deployment layer before the first production workload moves and the migration stops being a delay.