ISO/IEC 27017: ISO/IEC 27017 – Tutorial (about 60 minutes)

ISO/IEC 27017 is the international code of practice for information security in cloud computing. It takes the general security controls of ISO/IEC 27002 and explains, control by control, what a cloud service customer and a cloud service provider should each do, and it adds a small set of controls that only make sense in the cloud. Cloud providers, software-as-a-service companies, and the security and compliance teams of organisations that buy cloud services use it. After this tutorial you will be able to explain how the standard is organised, divide security responsibilities between customer and provider with confidence, build its guidance into an ISO/IEC 27001 management system, and explain what an ISO/IEC 27017 claim on a supplier's website does and does not prove.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is ISO/IEC 27017:2026, the second edition, published by ISO and IEC through their joint subcommittee ISO/IEC JTC 1/SC 27 (Information security, cybersecurity and privacy protection) and recorded as published (stage 60.60) on 27 July 2026. Its full title is "Information security, cybersecurity and privacy protection – Information security controls based on ISO/IEC 27002 for cloud services". It replaces and withdraws ISO/IEC 27017:2015, which was based on the 2013 edition of ISO/IEC 27002. The new edition is aligned with ISO/IEC 27002:2022 and is published in parallel by the International Telecommunication Union as Recommendation ITU-T X.1631 (12/2025); a European adoption (EN ISO/IEC 27017:2026) is also appearing in national catalogues. The 2026 edition is current and not under revision. At the time of writing, many provider certificates and compliance pages still refer to the 2015 edition, and no transition deadline for such certificates had been published. Verified 2026-10-29.

Who this is for: cloud and platform engineers, security architects, DevOps and site reliability staff, product owners of software-as-a-service (SaaS) products, procurement and vendor-risk analysts, and compliance or audit people who have to judge cloud suppliers. It is equally useful on both sides of the contract: if you buy cloud services, it shows what you must still do yourself; if you sell them, it shows what your customers will expect from you.

Prerequisites: none. It helps to know roughly what an ISO/IEC 27001 information security management system is and what a security control is (for example, access rights, backups or logging), but every term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why ISO/IEC 27017 exists and how it relates to ISO/IEC 27001 and ISO/IEC 27002.
You will be able to use the core cloud vocabulary correctly: customer, provider, partner, user, tenant, multi-tenancy and the main categories of cloud data.
You will be able to describe the structure of the 2026 edition, the side-by-side customer and provider guidance, and the four additional cloud controls.
You will be able to plan a practical implementation, from inventory of cloud services to a documented split of responsibilities.
You will be able to explain how ISO/IEC 27017 is assessed, and why it is not certified on its own.
You will be able to apply the guidance to a realistic organisation that is both a cloud customer and a cloud provider.
You will be able to compare ISO/IEC 27017 with ISO/IEC 27018, the CSA Cloud Controls Matrix and SOC 2 reports.

Lesson 1 – Origins, purpose and scope

Why a cloud-specific code of practice?

Traditional security thinking assumes that the organisation owns, or at least directly controls, its servers, networks and data centres. When it decides to encrypt a disk, patch an operating system or review an administrator's access, it can simply do it. Cloud computing breaks that assumption. A company that runs its payroll in a SaaS product does not see the servers, cannot install agents on them and usually cannot visit the data centre. A company that rents virtual machines from an infrastructure provider controls the operating system but not the hypervisor or the physical network. Security is still needed at every layer, but the work is now split between two or more organisations that are bound together only by a contract and a set of published service descriptions.

This split creates three recurring problems. First, gaps: each party assumes the other is handling something, such as backups of customer data, and nobody does. Second, overlaps and confusion: both parties try to do the same thing in incompatible ways, for example two sets of incident procedures that never connect. Third, lack of visibility: the customer has to trust controls it cannot inspect, so it needs evidence such as documentation, logs and independent audit reports. ISO/IEC 27017 was written to address exactly these problems.

Where it came from

The first edition, ISO/IEC 27017:2015, was developed jointly by ISO/IEC JTC 1/SC 27 and ITU-T Study Group 17, so the same text was also published as ITU-T X.1631. It was built on ISO/IEC 27002:2013, the well-known catalogue of information security controls, and followed that edition's clause numbering. For each relevant control it added implementation guidance for the cloud customer and the cloud provider, and in an annex it introduced seven extra cloud controls, identified with the prefix CLD. Major public cloud providers adopted it quickly and still publish certificates or attestations that mention it.

When ISO/IEC 27002 was completely reorganised in 2022 into 93 controls under four themes, the 2015 cloud guidance no longer lined up with the controls it was meant to extend. The second edition, ISO/IEC 27017:2026, was produced to restore that alignment, refresh the guidance for modern cloud practice and simplify the set of cloud-only controls. The ITU-T twin, X.1631, was revised at the same time.

What it covers

The standard gives guidance on information security controls for providing and for using cloud services. It does two things: it adds cloud-specific guidance to the relevant ISO/IEC 27002:2022 controls, and it defines a few additional controls, each with its own guidance, for issues that only arise in cloud computing. The guidance is written for both cloud service customers and cloud service providers. It applies to every deployment model, including private clouds, although an organisation running a private cloud for its own departments will need to translate "customer" and "provider" into internal roles.

Three points about scope are worth fixing in your mind from the start:

It is guidance, not a list of requirements. Its statements say what an organisation should consider doing. The requirements an organisation can be certified against are in ISO/IEC 27001.
It is about information security in general. Protection of personal data processed by public cloud providers is the subject of a sister document, ISO/IEC 27018.
It is horizontal: it applies to any cloud service, whether infrastructure, platform or application, rather than to one industry or one technology.

Lesson 2 – Key concepts and vocabulary

ISO/IEC 27017 relies on the cloud computing vocabulary maintained by SC 38, now published as ISO/IEC 22123-1 (current edition 2023); its first edition replaced the older ISO/IEC 17788:2014. Using these terms precisely matters, because most cloud security disputes start with two people meaning different things by "customer" or "data".

Cloud computing – a way of providing network access to a scalable, elastic pool of shared computing resources that can be provisioned on demand and largely self-service, with use usually measured.
Cloud service – one or more capabilities offered through cloud computing and invoked through a defined interface, for example a managed database, a storage bucket or a complete email application.
Cloud service customer (CSC) – the party that has a business relationship with a provider for the purpose of using its cloud services. The customer is usually an organisation, not an individual person.
Cloud service user – a natural person, or a system acting for one, that actually uses the service on behalf of a customer, such as an employee logging in to a SaaS tool.
Cloud service provider (CSP) – the party that makes cloud services available. A provider can itself be the customer of another provider; a SaaS company running on rented infrastructure is both.
Cloud service partner (CSN) – a party that supports the activities of a customer or provider without being either, such as a cloud auditor, a systems integrator, a managed security service or a broker.
Tenant – a group of cloud service users that share access to a set of physical and virtual resources, typically one customer's environment.
Multi-tenancy – allocation of physical or virtual resources so that several tenants share them while their computations and data stay isolated from and inaccessible to one another. Isolation between tenants is one of the central security concerns of the standard.
Cloud service customer data – data under the customer's control that the customer puts into the service, or that is created by the service on the customer's instruction. Example: the documents an employee uploads.
Cloud service derived data – data under the provider's control that results from the customer's use of the service, such as usage logs, metrics and records of who did what.
Account data and provider data – account data is what the provider needs to manage the customer relationship (contacts, billing details); provider data relates to the provider's own operation of the service (configuration of its infrastructure, its own staff accounts).
Cloud capabilities and service categories – the classic categories are infrastructure as a service (IaaS), platform as a service (PaaS) and software as a service (SaaS). The higher the category, the more the provider does and the fewer controls the customer operates directly.
Deployment models – public, private, community and hybrid cloud, describing who can use the shared resources and who controls them.
Virtualisation – the use of software, typically a hypervisor or container runtime, to present many logical machines or environments on shared physical hardware. Weak segregation here is what makes multi-tenancy risky.
Shared responsibility – the principle, central to ISO/IEC 27017, that each security activity for a cloud service is assigned to the customer, the provider or both, and that the assignment must be explicit, documented and understood.
Service agreement – the documented terms between customer and provider, including the contract, service level agreement and acceptable use rules. Much of what the standard asks providers to "document" ends up here or in customer-facing documentation.
Code of practice – a document that offers recommended practices rather than auditable requirements. ISO/IEC 27002 and ISO/IEC 27017 are both codes of practice.

Two of these distinctions deserve extra attention. The first is customer versus user: the customer signs the contract and carries accountability; users are the people doing the clicking. Security guidance about, say, user registration applies to the customer's process for giving its people access, even though the provider supplies the tools. The second is the categories of data. Customer data generally belongs to the customer and must be handled according to its instructions, while derived data is held by the provider but may still reveal sensitive facts about the customer, so the standard expects providers to be transparent about what they collect and why.

Lesson 3 – Structure of the standard

To read ISO/IEC 27017 you need to hold two documents in your head at once, because it is a set of additions to ISO/IEC 27002 rather than a self-contained catalogue. Figure 1 shows where it sits in the ISO/IEC 27000 family.

Figure 1 – ISO/IEC 27017 sits on top of the ISO/IEC 27002 control set, adds customer and provider guidance plus four cloud-only controls, and borrows its terms from the cloud vocabulary standard.

The clause layout of the 2026 edition

Like other sector documents in the family, the 2026 edition follows the layout of the document it extends. Published descriptions of the new edition summarise it as follows (paraphrased):

Clauses 1 to 3 – scope, normative references and terms. The terms are mostly taken from the cloud vocabulary standard and from the ISO/IEC 27000 overview.
Clause 4 – general concepts and guidance for cloud security, which set the scene for the control clauses (for example, the relationship between customer and provider).
Clause 5 – organizational controls, matching theme 5 of ISO/IEC 27002 (policies, roles, asset management, supplier relationships, incident management, legal requirements and so on).
Clause 6 – people controls (screening, awareness, responsibilities after leaving).
Clause 7 – physical controls (secure areas, equipment, disposal of media).
Clause 8 – technological controls (identity and access, logging and monitoring, configuration, backup, network security, secure development, data deletion and similar).
Annex A – a mapping between the first and second editions, so that an organisation that implemented the 2015 version can find where each item went.
Annex B – additional guidance on monitoring the security of cloud services.

The official abstract describes the cloud guidance as added to the relevant ISO/IEC 27002:2022 controls, so not every control receives cloud-specific text; in the first edition, controls without it were simply marked as covered by the general guidance. Where a control does need cloud advice, the extra guidance is often presented in a two-column form, one column for the customer and one for the provider, so the reader can see both halves of the shared responsibility side by side. A control can have guidance for only one party, for both, or a statement that the general guidance is enough. Figure 2 shows how one control is extended.

Figure 2 – For each ISO/IEC 27002 control the standard either confirms the general guidance or adds separate customer and provider guidance that together describe one shared responsibility.

The additional cloud controls

Some cloud issues have no natural home in ISO/IEC 27002, so the standard adds controls of its own. In the 2015 edition there were seven, numbered like the 2013 controls with a CLD prefix. Their topics were: shared roles and responsibilities, removal and return of customer assets when a contract ends, segregation in virtual environments, hardening of virtual machines, operational security for administrators, monitoring of cloud services by the customer, and alignment of security for virtual and physical networks.

The 2026 edition reduces this to four additional controls and places them at the end of the corresponding ISO/IEC 27002 themes, so their numbers continue the 27002 sequence. National catalogues and specialist summaries describe them as follows (titles paraphrased):

5.38 CLD – shared roles and responsibilities within a cloud computing environment: both parties should agree and document who does which security activity.
5.39 CLD – roles and responsibilities of the cloud service partner: when an integrator, managed service or other partner is involved, its security duties should be agreed too. This is new in the second edition.
8.35 CLD – segregation in virtual computing environments: one tenant's virtual resources should be isolated from those of other tenants and from the provider's own management environment.
8.36 CLD – detection and prevention of unauthorised use of cloud services: mainly a customer concern, it addresses "shadow" cloud services adopted by staff without approval. This is also new.

What about the other first-edition topics, such as virtual machine hardening, administrator procedures, customer monitoring and asset return? ISO/IEC 27002:2022 already contains general controls for configuration management, monitoring, privileged access, return of assets and the use of cloud services, which are the natural places for that material, and Annex B adds guidance on monitoring cloud services. Published summaries do not spell out where each old item went, so treat Annex A as the authoritative mapping and use it rather than guessing when you migrate an older control set.

How this fits ISO/IEC 27002:2022

Remember the shape of ISO/IEC 27002:2022: 93 controls in four themes, organizational (5.1 to 5.37), people (6.1 to 6.8), physical (7.1 to 7.14) and technological (8.1 to 8.34). The 2022 edition already introduced a general control on information security for the use of cloud services (5.23), which asks an organisation to set up processes to acquire, use, manage and exit cloud services. ISO/IEC 27017 can be seen as a detailed expansion of what that one general control implies across the whole catalogue.

Lesson 4 – How it works in practice

Start from your role

The first practical question is which role you play for the service in question. A bank that uses a SaaS customer relationship tool is a customer. A company that sells hosted software is a provider to its own customers and, very often, a customer of an infrastructure provider. A consultancy that configures cloud tenants for clients is a partner. One organisation can hold all three roles for different services, and the standard's guidance is applied per role, per service.

The shared responsibility map

The heart of any implementation is a written split of responsibilities. The split depends heavily on the service category. With IaaS, the provider is responsible for physical security, the hardware and the virtualisation layer, while the customer handles the guest operating system, applications, data and most access control. With PaaS, the provider also runs the operating system and middleware. With SaaS, the provider runs almost everything except the customer's own users, data, configuration choices and use of the service. In every category some duties stay with the customer: deciding who may access the service, classifying and protecting its own data, configuring the security options the service offers, and meeting its own legal obligations.

Providers are expected to publish this split clearly, in documentation that customers can read before they buy. Customers are expected to read it, compare it with their own needs and fill any gaps with their own controls or with contract terms. The map is typically maintained as a responsibility table (sometimes called a RACI or responsibility matrix) listing each control area and marking it customer, provider or shared.

Figure 3 – The roles around a cloud service: users act for the customer, the customer contracts with the provider, the provider may rely on a peer provider, and partners and auditors support or assure the parties.

Typical guidance for each side

Reading through the standard, the same patterns appear again and again. For the customer, the guidance usually says: understand what the provider does; check that it meets your requirements; configure the security functions that are offered; and keep your own processes connected to the provider's. For the provider, it usually says: build the capability; document it for customers; give customers the information and tools they need; and tell them about changes. Some examples, described in general terms:

Policies – the customer's security policy should cover its use of cloud services, and the provider's policy should cover the risks of multi-tenancy and of its own staff accessing customer data.
Asset inventory – the customer should include the cloud services it uses and the data it stores in them in its inventory; the provider should be clear about which assets belong to whom.
Access management – the provider should offer adequate user registration, strong authentication and privileged-access functions; the customer should actually use them and manage its users' lifecycle.
Cryptography – the provider should describe where encryption is applied and how keys are handled; the customer decides whether that is sufficient or whether it should manage its own keys.
Logging and monitoring – the provider should give customers logs or monitoring capabilities about their own tenant; the customer should collect and review them.
Change management – the provider should inform customers of changes that might affect their security; the customer should have a way to receive and assess such notices.
Backup – the provider should state what is backed up, how often and how restoration works; the customer must not assume backups exist if the documentation does not say so.
Incident management – the parties should agree how incidents are reported in both directions, how quickly and through which channels, and what evidence can be provided.
Legal and regulatory requirements – the customer should consider that the provider may store data in other countries, and the provider should disclose the locations and jurisdictions involved.
Exit – the provider should explain how customer data is returned and securely removed when the service ends; the customer should plan for that event from the start.

Implementation steps

ISO/IEC 27017 does not prescribe a project plan, but organisations usually implement it inside an existing or planned ISO/IEC 27001 information security management system (ISMS). The steps in Figure 4 are a common, practical sequence.

Figure 4 – A typical implementation cycle: scope, inventory, classification, risk assessment, responsibility split, control selection, documentation, implementation and ongoing review.

A few comments on the steps:

Scope and roles. Decide which services are covered and in which role. A provider usually scopes the service it sells; a customer scopes the business processes that depend on cloud services.
Inventory. List every cloud service, including small SaaS tools bought on credit cards. This is where the new control on unauthorised cloud use pays off: you cannot secure a service you do not know about.
Risk assessment. Cloud risks include tenant isolation failure, provider insider access, loss of control over data location, provider outage or insolvency, misconfiguration by the customer and lock-in that makes exit hard. Assess them like any other risk under ISO/IEC 27001.
Responsibility matrix and control selection. For each relevant control, read the ISO/IEC 27002 guidance, then the ISO/IEC 27017 additions for your role, and decide what you will do.
Statement of Applicability (SoA). ISO/IEC 27001 requires an SoA: the document listing the necessary controls, why they are included, whether they are implemented, and why any ISO/IEC 27001 Annex A controls are excluded. Organisations that adopt ISO/IEC 27017 normally add the cloud controls to it.
Contracts and documentation. Make sure commitments are written down: in the service agreement, in customer-facing security documentation, or in both.
Monitoring and review. Providers change their services frequently. Re-check the responsibility split when a provider announces a significant change, when you adopt a new service or feature, and at least during each ISMS review.

Artefacts you will typically produce

A cloud security policy or a cloud section in the main security policy.
An inventory of cloud services, with owners and data classifications.
A shared responsibility matrix for each significant service.
For providers: customer-facing security documentation, a description of isolation and encryption, incident notification terms and an exit description.
For customers: supplier assessment records, configuration baselines for each service and records of reviewing provider assurance reports.
An SoA that includes the ISO/IEC 27017 controls you have adopted.

Lesson 5 – Assessment, certification and compliance

Why there is no stand-alone certificate

Certification audits check conformity with requirements, the "shall" statements of a standard. ISO/IEC 27017 contains guidance, not requirements, so it cannot by itself be the basis of a management system certificate. The requirements live in ISO/IEC 27001. What happens in practice is that an organisation with an ISO/IEC 27001 ISMS adds the ISO/IEC 27017 controls and guidance to its control set and its SoA, and the certification body checks them during the ISO/IEC 27001 audit. ISO/IEC 27001 explicitly allows controls from any source to be included, as long as the result is compared with its own Annex A.

Certification bodies then report the result in different ways. Some add a reference to ISO/IEC 27017 on the ISO/IEC 27001 certificate; others issue a separate certificate or statement that is valid only together with the underlying ISO/IEC 27001 certificate. Practice varies between certification and accreditation bodies, so read the actual document rather than relying on a logo. Large public cloud providers publish such certificates on their compliance pages, normally listing the services and regions covered.

How the audit works

Adding ISO/IEC 27017 to a certification usually follows the familiar ISO/IEC 27001 pattern:

Stage 1 (documentation review) – the auditor checks that the scope covers the cloud services, that the risk assessment considers cloud risks, and that the SoA includes the cloud controls with justifications.
Stage 2 (implementation audit) – the auditor samples evidence: the responsibility matrix, customer-facing documentation, isolation testing results, logs offered to customers, incident notification records, exit procedures, and interviews with the people who run them.
Surveillance and recertification – the cloud controls are revisited in the normal surveillance cycle, and the extension lapses if the ISO/IEC 27001 certificate lapses.

Most organisations add the cloud scope either at initial certification or at a surveillance audit; the extra audit time depends on the certification body and the complexity of the services.

What a provider's certificate does and does not tell a customer

For a customer, a provider's ISO/IEC 27017 certificate is useful evidence that the provider has thought about its half of the shared responsibility and has been audited on it. But it has clear limits:

It covers only the scope stated on the certificate: particular services, locations and sometimes legal entities. A service launched last month may not be included.
It says nothing about the customer's own half. Using a certified provider does not make the customer's environment compliant; the customer must still configure and operate its own controls.
It is a point-in-time assurance with periodic surveillance, not continuous monitoring.
It may still refer to the 2015 edition. That is not wrong in itself while no transition deadline applies, but the customer should know which edition the controls were audited against.

Editions and transition

Because the 2026 edition is new, certification bodies and accreditation bodies will decide how and when audits move to it. Organisations already using the 2015 edition should use Annex A to map their controls to the new numbering, update their SoA, and ask their certification body about its plans. Do not assume any particular deadline until one is published.

Compliance with laws and contracts

ISO/IEC 27017 is voluntary. Regulators and customers sometimes reference it, for example in public-sector cloud procurement or in contracts with security schedules, and in those cases it becomes a contractual expectation. It does not by itself demonstrate compliance with data protection law; for personal data, organisations also look at ISO/IEC 27018 and ISO/IEC 27701 and at the law that applies to them.

Lesson 6 – Worked example

The organisation. "Ledgerline" (fictional) is a 120-person company that sells a payroll and expense SaaS product to mid-sized employers in several countries. Its application runs on virtual machines, managed databases and object storage rented from a large public IaaS provider. A managed security service provider runs its 24-hour security monitoring. Internally, staff also use a SaaS office suite, a ticketing tool and a code repository service. Ledgerline already holds ISO/IEC 27001 certification for its corporate IT, and two large prospective customers now ask for evidence of cloud-specific controls.

Step 1 – Clarify roles and scope

The security lead lists Ledgerline's roles. For the payroll product, Ledgerline is a provider to employers. For the IaaS platform and the office tools, it is a customer. The monitoring company is a partner. The ISMS scope is extended to the payroll service and to the cloud services that support it.

Step 2 – Inventory and classification

A finance report of card payments reveals eleven SaaS subscriptions nobody had registered, including a file-sharing tool used by sales to send payroll exports to prospects. Each service is added to the inventory with an owner and the most sensitive data it holds. The file-sharing tool is replaced by the approved office suite, and a simple approval process for new SaaS tools is introduced, together with alerts from the web proxy when staff sign up for unknown cloud services. This is the new control on unauthorised cloud use in action.

Step 3 – Risk assessment

The team adds cloud risks to the register: a misconfigured storage bucket exposing payslips; a failure of tenant isolation inside Ledgerline's own multi-tenant application, letting one employer see another's staff; provider staff accessing data; loss of the IaaS region; and difficulty returning data to a customer that leaves. The highest risks are the misconfigured storage and the application-level isolation, both of which are Ledgerline's own responsibility even though the infrastructure belongs to someone else.

Step 4 – Responsibility matrices

Two matrices are drawn up. The first, "Ledgerline as customer", is based on the IaaS provider's published shared-responsibility documentation: the provider handles data centres, hardware and the hypervisor; Ledgerline handles operating systems, network rules, identities, encryption settings and its data. The second, "Ledgerline as provider", is new and will be shared with customers: Ledgerline runs the application, its security and its backups; each employer manages its own user accounts, approves which of its staff may run payroll, and is responsible for the accuracy of the data it uploads.

A third, short agreement is written with the monitoring partner, setting out which logs it receives, what it must escalate and how quickly, and that it may not export customer data. This reflects the partner control added in the second edition.

Step 5 – Select controls and update the SoA

Working through the ISO/IEC 27002:2022 themes, the team reads the ISO/IEC 27017 guidance for both columns, because Ledgerline is customer and provider at once. Some resulting decisions:

Segregation: as provider, Ledgerline enforces tenant isolation in the application with a tenant identifier on every query, automated tests that try cross-tenant access, and separate encryption keys per tenant for stored files.
Configuration: as customer of the IaaS, it applies hardened machine images and policy-as-code checks that block public storage buckets.
Logging for customers: it adds an audit log that each employer can view and export, showing logins and payroll approvals in its own tenant.
Change notification: it commits to giving customers advance notice of changes that affect security features.
Exit: it documents how a departing customer receives a full export and how data is then deleted, including backups after their retention period.

The four additional cloud controls and the cloud-specific guidance are added to the SoA, each with a reason and an implementation status.

Step 6 – Document for customers

Ledgerline publishes a customer security guide: the responsibility split, where data is stored, how encryption and keys are handled, the backup and restore approach, incident notification times, and the exit process. Sales and legal align the standard contract with the guide so that the two never contradict each other.

Step 7 – Audit and improve

An internal audit samples the evidence and finds one weakness: the cross-tenant tests run only before major releases. The fix is to run them on every build. At the next surveillance audit, the certification body reviews the extended scope and confirms the ISO/IEC 27017 controls. Ledgerline now gives prospective customers its certificate, its customer security guide and a clear explanation of what remains the customer's job.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 27017 is rarely used alone. It extends a management system, complements privacy guidance and overlaps with industry frameworks that customers often ask for. Knowing the differences helps you avoid duplicated work and answer customer questionnaires efficiently.

Standard or framework	Type	Main focus	Relationship to ISO/IEC 27017
ISO/IEC 27001:2022	Requirements standard, certifiable	Information security management system	Provides the management system and certification route; ISO/IEC 27017 controls are added to its SoA.
ISO/IEC 27002:2022	Code of practice	93 general security controls in four themes	The base catalogue; ISO/IEC 27017 adds cloud guidance to its controls and four cloud-only controls.
ISO/IEC 27018:2025	Code of practice	Protection of personal data by public cloud providers acting as processors	Sister document for privacy; often implemented together with ISO/IEC 27017 by providers.
ISO/IEC 27701:2025	Requirements standard, certifiable	Privacy information management system	Manages privacy overall; ISO/IEC 27017 addresses security of the cloud service itself.
CSA Cloud Controls Matrix v4.1 and STAR	Industry framework and assurance programme	Cloud-specific control objectives in 17 domains	Overlaps strongly; CSA maps the matrix to ISO standards, and STAR certification builds on ISO/IEC 27001.
SOC 2 (AICPA Trust Services Criteria)	Attestation report	Independent auditor's opinion on a service organisation's controls	Different assurance format, common in North America; many providers offer both.
ISO/IEC 22123-1:2023	Vocabulary	Cloud computing terms	Supplies the definitions of customer, provider, partner and other terms.

A useful way to remember the relationships: ISO/IEC 27001 says run a management system; ISO/IEC 27002 says here are the controls to consider; ISO/IEC 27017 says here is how those controls change in the cloud and who does what; ISO/IEC 27018 says here is what a public cloud processor should add to protect personal data. Industry frameworks such as the CSA matrix and SOC 2 reports offer alternative or complementary ways of expressing and assuring similar controls.

Supplier management standards are also relevant. The ISO/IEC 27036 series covers information security in supplier relationships, and a part of it deals with cloud services; the ISO/IEC 19086 series covers cloud service level agreements. They help a customer write better contracts, while ISO/IEC 27017 gives the security content those contracts should cover.

Common pitfalls and best practices

Pitfalls

Treating the provider's certificate as your own. A customer that relies on its provider's certificate and does nothing about access, configuration and data classification is exposed exactly where most cloud breaches happen.
An implicit responsibility split. Leaving the split to assumptions ("surely they back that up") creates gaps that surface only during an incident.
Ignoring shadow cloud services. Unregistered SaaS tools hold sensitive data outside every control, and nobody knows to remove it when staff leave.
Using the 2015 numbering after the change. Keeping old CLD identifiers in the SoA without mapping them to the 2026 edition causes confusion in audits and questionnaires.
Documentation that contradicts the contract. A security guide promising 24-hour incident notice while the contract says 72 hours undermines trust and creates legal risk.
Forgetting exit. Without a planned way to get data back and deleted, a customer is locked in and a provider cannot prove deletion.
Checking scope only once. Providers add services and regions constantly; a supplier assessment done three years ago may not cover what is used today.

Best practices

Write a responsibility matrix for every significant service and review it whenever the service or your use of it changes.
Read both columns. Even if you are only a customer, the provider guidance tells you what evidence to request.
Integrate with the ISMS. Put cloud risks in the normal risk register and cloud controls in the normal SoA instead of running a separate "cloud compliance" project.
Automate configuration checks (policy as code, continuous posture monitoring) so that baselines do not depend on manual reviews.
Give customers usable evidence: tenant-level logs, clear security documentation, and certificates with an understandable scope.
Plan the exit at the start and test data export and deletion before you need them.
Bring partners into the agreement, with written security duties for integrators, managed services and brokers.

Summary and key takeaways

ISO/IEC 27017:2026 is the current, second edition of the cloud security code of practice, aligned with ISO/IEC 27002:2022 and published in parallel as ITU-T X.1631.
It adds cloud-specific guidance to general controls, usually split into what the customer should do and what the provider should do.
It defines four additional cloud controls: shared roles, partner roles, segregation in virtual environments, and detection and prevention of unauthorised cloud use.
Shared responsibility must be explicit, documented and agreed; most failures come from gaps or assumptions.
The split depends on the service category: the customer always keeps responsibility for its users, its data and its configuration choices.
It is guidance, so it is assessed as part of an ISO/IEC 27001 certification rather than certified on its own.
A provider's certificate supports, but never replaces, the customer's own controls; always check its scope and edition.
It works best alongside ISO/IEC 27018 for personal data and alongside industry frameworks such as the CSA matrix.

Reflection questions

List the cloud services your team relies on. For which of them are you a customer, a provider or a partner, and is that written down anywhere?
Pick one SaaS service you use. Which security activities remain yours, and where would you find the provider's description of its half?
If your main cloud provider announced tomorrow that it would end a service in six months, what would you need to do to get your data back and confirm it was deleted?
How would you detect a new, unapproved cloud service being adopted by a department in your organisation, without blocking legitimate innovation?
A customer asks you for "proof of ISO/IEC 27017". Which documents would you give them, and how would you explain what they do and do not cover?