ISO 27017: Cloud Security Controls Explained

ISO/IEC 27017 is an international code of practice that extends ISO/IEC 27002 with security guidance specific to cloud services. It adds seven cloud-only controls and provides cloud implementation guidance for many existing controls, clarifying which security duties belong to the cloud provider and which belong to the customer.

What ISO 27017 actually is

ISO 27017 sits on top of ISO 27002, the catalogue of information security controls. Where ISO 27002 describes controls for organisations in general, ISO 27017 reads those same controls through a cloud lens and tells both the cloud service provider and the cloud service customer how to apply them. It does two things: it provides cloud-specific implementation guidance for a large set of ISO 27002 controls, and it introduces seven brand-new controls that only make sense in a cloud context. If you want a deeper grounding in the underlying catalogue, our guide to ISO 27002 controls explains how the base set is structured.

A common point of confusion is certifiability. ISO 27017 is guidance, not a management-system standard in its own right. You do not get "ISO 27017 certified" the way you get certified to ISO 27001. Instead, organisations implement ISO 27017 alongside a certified ISO 27001 information security management system, and a certification body can assess conformity to ISO 27017 as an extension of that certified scope. In practice, the ISO 27001 certificate is the anchor, and ISO 27017 adds cloud assurance on top.

The shared responsibility split

The heart of ISO 27017 is the shared responsibility model. In cloud computing, security is never owned entirely by one party. The provider secures the underlying platform, and the customer secures what they build and store on it. The exact line moves depending on the service model. In Infrastructure as a Service, the customer handles operating systems, applications, and data, while the provider secures the hypervisor and physical layer. In Software as a Service, the provider handles far more of the stack, and the customer is mostly responsible for user access, configuration, and their own data.

ISO 27017 forces both parties to write this line down. The value is the elimination of the "security gap" where each side assumes the other is patching a server, rotating a key, or reviewing an audit log. By documenting who does what for encryption, logging, backup, and incident response, the standard removes the ambiguity that causes real breaches. For teams moving an ISMS into the cloud, our ISO 27001 for cloud services material walks through how this split feeds into the management system.

The 7 cloud-specific controls

ISO 27017 adds seven controls, each prefixed CLD to mark them as cloud-only. These address risks that simply do not exist in a traditional on-premises environment, such as multi-tenancy and virtual machine isolation. Consider a practical example: two competing companies may run workloads on the very same physical server inside a public cloud. Control CLD.9.5.1 exists precisely so that one tenant can never read, corrupt, or infer the data of another. Traditional ISO 27002 never had to worry about that scenario, which is why the cloud codes were written.

• CLD.6.3.1 Shared roles and responsibilities: define and document security duties between provider and customer.
• CLD.8.1.5 Removal of cloud service customer assets: securely return or delete customer data when a contract ends.
• CLD.9.5.1 Segregation in virtual computing environments: isolate one tenant from another in multi-tenant systems.
• CLD.9.5.2 Virtual machine hardening: apply baseline secure configurations to virtual machines.
• CLD.12.1.5 Administrator operational security: control and monitor privileged administrative actions.
• CLD.12.4.5 Monitoring of cloud services: give customers the logging and monitoring they need for oversight.
• CLD.13.1.4 Alignment of virtual and physical network security: keep virtual network controls consistent with physical ones.

How it relates to ISO 27001, 27002 and 27018

These standards form a family. ISO 27001 is the certifiable management-system standard that requires a risk-based ISMS. ISO 27002 is the control catalogue that the ISMS draws on. ISO 27017 layers cloud-specific guidance and controls over that catalogue. ISO 27018 is a sibling code of practice focused specifically on protecting personally identifiable information processed in public clouds. Many cloud providers implement ISO 27017 and ISO 27018 together, under a single ISO 27001 certificate, to demonstrate both general cloud security and privacy assurance.

How to use ISO 27017 in practice

Start by mapping your cloud services and identifying, per service, whether you are the provider, the customer, or both. Then work through the ISO 27017 implementation guidance for the relevant ISO 27002 controls and adopt the seven CLD controls where they apply. Feed the shared-responsibility decisions into your Statement of Applicability so the ISMS reflects reality. Because ISO 27017 is guidance rather than a separate certification, treat it as an enrichment of your ISO 27001 scope: it sharpens your controls, it does not replace the management system that governs them.

A practical adoption sequence helps. First, confirm your ISO 27001 ISMS is in place, because ISO 27017 has nothing to anchor to without it. Second, inventory every cloud relationship and label each one by service model, since an IaaS relationship pushes far more responsibility onto you than a SaaS one. Third, review your contracts and service agreements against the CLD.6.3.1 requirement to document shared roles. Many organisations discover here that their provider contract is silent on log retention or data deletion, which is exactly the gap the standard is designed to surface.

Common pitfalls when adopting ISO 27017

The most frequent mistake is assuming the cloud provider handles security end to end. Under the shared responsibility model, misconfigured storage buckets, weak identity settings, and unencrypted customer data are almost always the customer side of the line, not the provider side. A second pitfall is treating ISO 27017 as a checklist bolted on after go-live, rather than a design input. The controls are most effective when applied while you architect the environment, not retrofitted after an incident. A third is neglecting the exit: CLD.8.1.5 requires secure return or deletion of assets when a contract ends, and organisations often have no tested process for reclaiming data from a provider they are leaving.

Avoiding these traps comes down to discipline. Document the responsibility split before you deploy, verify that your provider gives you the logging and monitoring evidence CLD.12.4.5 expects, and rehearse your offboarding so data does not linger on someone else systems after the relationship ends. These are not exotic requirements; they are the basic hygiene that separates a mature cloud programme from a hopeful one.

Used well, ISO 27017 turns vague cloud contracts into a clear, auditable division of security labour. That clarity is what auditors, customers, and regulators increasingly expect from any organisation that runs meaningful workloads in the cloud. Paired with a certified ISO 27001 ISMS and, where personal data is involved, ISO 27018, it gives customers concrete assurance that cloud risk is understood and owned rather than quietly assumed away.