ISO 27017: Cloud Security Controls and What the 2026 Edition Changes

Ask a cloud provider whether it is certified to ISO 27017 and you will often get a confident yes. That answer is wrong, and the confusion matters, because the way ISO 27017 is actually assessed determines how you scope the work, what your auditor looks at, and what you can honestly tell a customer. This guide covers what the standard contains, how it differs from ISO 27018, and what changed when ISO published a second edition in July 2026.

If you are still deciding which cloud assurance route fits your buyers at all, start with our comparison of cloud security certification options — ISO 27017 sits alongside those rather than replacing them.

ISO 27017, ISO 27018 and ISO 27001 compared

Why there is no ISO 27017 certificate

ISO 27001 is a management system standard: it states requirements an organisation must meet, which is what makes accredited certification possible. ISO/IEC 27017 is not built that way. It provides controls and implementation guidance for cloud services on top of ISO/IEC 27002, and guidance documents are not certified against.

What certification bodies do instead is extend the scope of an ISO 27001 audit to cover the cloud controls you have adopted. Your Statement of Applicability names them, your evidence supports them, and the resulting certificate refers to an ISMS that includes cloud services. Some certification bodies will annotate the scope statement to that effect. None will issue a standalone ISO 27017 certificate, and a supplier who shows you one is showing you something their certification body did not issue in the form they are implying.

The practical consequence: you cannot approach ISO 27017 as a separate project. It is an increment on an ISO 27001 system, and if that system does not exist yet, the cloud controls have nothing to attach to.

The seven cloud-specific controls

Most of ISO 27017 is additional guidance on controls you already operate — the first edition supplied cloud-specific implementation notes for around 37 of the ISO 27002 controls. What makes the standard distinctive is the small set of controls that exist only because computing became shared. In the 2015 edition these carried CLD identifiers:

• CLD.6.3.1 — Shared roles and responsibilities. Who does what between provider and customer, written down per service rather than assumed. Most cloud security failures trace back to a task both parties believed the other owned.
• CLD.8.1.5 — Removal of cloud service customer assets. When a contract ends, the customer’s data must actually leave — including the copies in backups, caches and support systems.
• CLD.9.5.1 — Segregation in virtual computing environments. One tenant’s compromise must not reach another’s. Separation at a single layer is not enough, and it has to be tested rather than asserted.
• CLD.9.5.2 — Virtual machine hardening. A virtual machine inherits the weaknesses of the image it was built from, multiplied by every deployment of that image.
• CLD.12.1.5 — Administrator’s operational security. Cloud administrators hold rights that reach across every tenant at once, so how those rights are exercised and recorded is itself a control.
• CLD.12.4.5 — Monitoring of cloud services. Customers need to be able to see what happens in their own tenancy, which means the provider has to make that telemetry available.
• CLD.13.1.4 — Alignment of virtual and physical network security. Virtual networks are configured by different people on a different cadence from the physical networks beneath them; where the two drift, traffic takes paths nobody designed.

Read them together and a theme emerges. Every one of the seven exists because responsibility in cloud computing is divided, and divided responsibility is where things get dropped.

ISO 27018: the privacy half

ISO/IEC 27018 applies in a narrower case: you process personal data in a public cloud on someone else’s behalf, as a processor rather than a controller. Its obligations are the ones a customer’s privacy team asks about — process only on documented instruction, do not use the data for your own purposes, disclose your sub-processors, tell the customer about government requests for their data where the law allows, notify breaches, support data subject requests, and return or delete everything at the end.

The current edition is ISO/IEC 27018:2025, the third, which aligned the text with ISO/IEC 27002:2022 and added a new Annex B. If you sell a SaaS product to enterprise buyers in Europe, this is usually the half of the pair that closes deals.

What the 2026 edition of ISO 27017 changes

In July 2026 ISO published ISO/IEC 27017:2026, the second edition, and withdrew the 2015 edition. It is a technical revision: the title and scope changed, the structure moved to a taxonomy with associated attributes built on ISO/IEC 27002:2022, and controls were merged, removed and added. The practical effect is that the CLD identifiers no longer exist — cloud controls now sit inside the 27002:2022 numbering.

Where the seven controls went

Two of the seven kept dedicated control status. The other five were absorbed as cloud guidance on controls you already operate — which is arguably where they always belonged, since they were never separate activities so much as cloud-specific ways of doing familiar ones.

Two controls that are genuinely new

5.39 — responsibilities with other cloud partners. The 2015 edition assumed two parties: a customer and a provider. Real cloud estates have resellers, managed service providers, integrators and their subcontractors, and security obligations get dropped in the gaps between them. This control asks you to allocate responsibility across everyone in the chain, not just the two names on the contract.

8.36 — detection and prevention of unauthorized use of cloud services. Shadow cloud, addressed explicitly for the first time. You are expected to be able to find cloud services adopted outside your process, assess what data they hold, and decide on each one. Worth saying: shadow cloud is a symptom, not a crime. A service appears because the approved route was too slow or did not exist, and blocking without fixing that reliably produces a replacement within weeks.

What this means for you

Because ISO 27017 is not certifiable in its own right, there is no formal transition period of the kind ISO 27001 had. The date that matters is whichever edition your certification body expects when it audits your cloud extension — ask before your next audit rather than during it.

The work itself is mostly re-referencing rather than re-implementing. A segregation test you ran last year is still evidence of segregation; what changes is the number your Statement of Applicability cites next to it. The two new controls are the exception: 5.39 and 8.36 are new obligations, and most organisations will find they have nothing formal in place for either.

How the extension is audited

Because there is no separate certificate, the audit evidence lives inside your ISO 27001 system:

• Your Statement of Applicability carries the cloud controls, with justifications, in the same form as everything else.
• The shared responsibility position is documented per service, and both parties recognise it.
• Controls the provider operates on your behalf are evidenced by assurance you obtained and assessed — a certificate on file is not an assessment.
• Segregation and boundary claims are backed by test results with dates, not design documents.
• Where ISO 27018 applies, the processing instruction records, breach notifications and deletion certificates are retained.

Auditors reach for the last two first, because they are the ones organisations most often cannot produce.

Where to start

Get the ISO 27001 system working before adding anything cloud-specific — if the ISO 27002:2022 controls are not yet operating, the cloud extension has no foundation. Then determine your role for each service, because a provider and a customer implement almost nothing the same way. Then document shared responsibility per service. Only then start on the technical controls.

Our ISO 27017 and ISO 27018 Cloud Toolkit covers that sequence with 67 editable templates — scope and role determination, shared responsibility matrices, virtualisation and tenant isolation standards, cloud monitoring and logging, the ISO 27018 processor obligations, and the mapping and audit-evidence documents the extension is assessed on. Every document states which edition its control references come from.

Frequently asked questions

Can you get ISO 27017 certified?

No. ISO 27017 is guidance rather than a management system standard, so no accredited body issues a certificate for it. It is assessed as an extension of your ISO 27001 certification scope, and some certification bodies will reflect that in the scope statement on the certificate.

What is the difference between ISO 27017 and ISO 27018?

ISO 27017 covers cloud security generally — tenant segregation, virtual machine hardening, administrator operations, monitoring and the division of responsibility between provider and customer. ISO 27018 is narrower and applies only when you process personal data in a public cloud on a customer’s behalf, covering processing instructions, sub-processors, disclosure requests, breach notification and deletion.

Do I need ISO 27001 before ISO 27017?

In practice yes. ISO 27017 supplies cloud-specific controls that attach to an information security management system; without that system there is nothing for them to extend and no audit in which they would be examined.

Is ISO 27017:2015 still valid?

ISO withdrew it when ISO/IEC 27017:2026 was published in July 2026. Documents written to the 2015 edition are not wrong in substance — the controls do the same thing — but the CLD identifiers they cite belong to a withdrawn edition, and two controls in the second edition (5.39 and 8.36) have no 2015 equivalent at all. Confirm with your certification body which edition it audits your cloud extension against.

How long does an ISO 27017 implementation take?

For an organisation with a working ISO 27001 system, the cloud extension is usually a matter of weeks to a few months, depending on how many cloud services are in scope and whether you are acting as a provider, a customer, or both. Starting from no ISMS at all, the ISO 27001 work dominates the timeline.