ISO/IEC 27017:2015 has been revised. The new version, ISO/IEC 27017:2026, has been officially published since 27 July.

This is not a major overhaul so much as a structural adjustment, with four new controls that will affect how you evaluate your providers.

I covered the first edition in this 2022 article.

ISO/IEC 27017 is a complement to ISO/IEC 27002 (the information security controls catalogue) specific to cloud computing. It addresses both sides of the relationship: the CSC (cloud service customer) and the CSP (cloud service provider).

In my experience, the vast majority of SMBs are CSCs. They buy Microsoft 365, a hosted ERP, or a SaaS product — they do not sell cloud services. That is the lens I use here.

Why it was four years late

ISO/IEC 27001:2022 completely redesigned Annex A four years ago: a new structure in four themes (organizational, people, physical, technological), new controls, new terminology. ISO/IEC 27017 stayed tied to the 2013 structure and its fourteen domains. The new edition finally fixes that and aligns with ISO/IEC 27002:2022.

In practice, the standard reuses the same architecture as 27002:2022. For every control that needs cloud-specific detail, a “guidance for cloud services” section is added. Two formats exist: Type 1 separates recommendations for the CSC and the CSP; Type 2 gives shared guidance for both. When a standard control needs no cloud precision, there is simply a reference back to 27002:2022. The text is therefore lighter than the 2015 edition, which repeated a lot.

Four new cloud controls (CLD prefix)

This is the part that will actually require work. Four extended controls, labelled “CLD”, are added.

CLD 5.38 — Shared roles and responsibilities

Shared roles and responsibilities between you and your cloud provider must be defined: who handles security patches, who handles backups, who responds to incidents.

In many SaaS contracts I have reviewed, that split stays implicit or buried in 40 pages of terms of use.

To comply:

  • ask your provider for a written description of its security capabilities (authentication, encryption, backups, logging);
  • confirm you can fulfil your own share;
  • have that role split written into your service agreement — not only on a terms-of-use web page.

CLD 5.39 — Cloud service partner (CSN)

An agreement on the roles and responsibilities of the cloud service partner, which the standard calls a CSN. If your provider subcontracts part of the hosting or support to a third party, that chain must be covered, not only the first link.

A note on the CSN acronym, because I asked myself the same question the first time I read it: it means “cloud service partner”. The C and the S follow the CSC/CSP pattern, but P was already taken by the provider, so the standard chose CSN for the partner without explaining why that letter rather than another. ISO/IEC 22123-3 defines three possible roles for a CSN: cloud service developer, cloud auditor, and cloud service broker.

To comply:

  • ask your primary provider whether it uses partners or subcontractors to deliver the service;
  • make sure the agreement you have with it stays consistent with the role split in CLD 5.38 once that third party is in the picture.

CLD 8.35 — Segregation in virtual environments

Segregation in virtual computing environments: assurance that your data does not mix with another customer’s on the same shared infrastructure.

To comply:

  • you will not be able to test this yourself on a SaaS service;
  • ask your provider for existing attestations (ISO 27001 certification, SOC 2 report) as evidence that tenant separation is actually in place.

CLD 8.36 — Unauthorized use of cloud services

Detection and prevention of unauthorized use of cloud services. In my audits, I regularly see a team open a SaaS account with a corporate credit card without telling anyone. This control targets exactly that.

To comply:

  • monitor your users’ activity;
  • review periodically against your cloud-use policy;
  • detect anomalies — for example an unexplained spike in use of a service.

For an SMB, that starts with a simple inventory of the cloud services actually in use, reviewed from time to time rather than once and forgotten.

New vocabulary, broader scope

The standard now recognizes that an SMB rarely uses a single cloud provider. It names the possible setups (private, public, multi-provider, hybrid cloud) and describes three ways to manage them: you orchestrate your different services yourself, one provider combines several for you, or several providers associate to deliver the service. The practical takeaway: if you combine Microsoft 365, a cloud host, and a third-party SaaS product, the standard now explicitly covers that reality instead of assuming a single provider.

Scope also widens: the standard states that it applies to all deployment models, including private cloud, with a possible adjustment when the same department acts as both customer and provider internally. A new Clause 4 covers cloud supplier relationships and explicitly points to ISO/IEC 27036-4 for cloud supply-chain security — a topic the 2015 edition barely addressed.

Two annexes, not three

Some analyses published during the FDIS vote (Final Draft International Standard, the last step before publication) described a third annex dedicated to continuous monitoring of cloud services. Reading the final text published on 27 July, that is not what I find. The published standard contains two annexes, both informative: Annex A is the full correspondence table with the 2015 edition; Annex B covers monitoring of cloud services.

In practice, Annex B explains that your ability to monitor security events depends on the type of service you use. With a SaaS product such as Microsoft 365, your monitoring stays limited to what the software itself shows you: you depend on what your provider agrees to share, which ties directly back to the role split in CLD 5.38 above. With an IaaS (infrastructure) service, you get much broader monitoring tooling, including cloud security posture management tools. The annex also notes that manual monitoring becomes difficult at scale and pushes toward automated tools.

What that means for your reading: if you are mainly a SaaS customer, ask your providers which security reports or logs they make available and write that commitment into your service agreement. You will not install your own monitoring tools on their infrastructure — your only lever is contractual.

Migration timeline

In Japan, the certification standard based on the 2015 version is under revision, with publication expected in autumn 2026 and a three-year transition for already certified organizations. The same cadence generally applies elsewhere: the standard comes out first, national certification standards follow a few months later, and migration is then counted in years, not months.

In practice

Here is what I recommend to clients who use ISO/IEC 27017 in their ISMS, wherever they are in the cycle:

  • If 27017 is part of your Statement of Applicability (SoA), use the Annex A correspondence table to see which controls changed number or content, before your next surveillance audit.
  • Ask your main cloud providers (SaaS, hosting, infrastructure) again whether they have a transition plan to the 2026 version and on what timeline.
  • Work through the four “To comply” blocks above one by one with your current providers — that is what will actually take your time.
  • Do not delay an ongoing certification to wait for the new version. National certification standards take months to align, and the migration that follows is measured in years.

At minimum, this revision remains what it has always been: a tool to evaluate and document your relationships with cloud providers. Compliance remains your responsibility — not your cloud provider’s, and not your consultant’s. This update is an opportunity to review those relationships, not a task to delegate entirely.

In short: four concrete controls to integrate, and a text finally aligned with ISO/IEC 27002:2022. The real work will be going back to your current service contracts and checking whether the roles they describe still hold up.

An audit coming up and you are not sure you are ready on this point? Let’s talk.