ISO 27017 and 27018,
the cloud add-ons

ISO/IEC 27017 and ISO/IEC 27018 are both codes of practice — control guidance, not certifiable standards in their own right. Each one takes the well-known control set described in ISO/IEC 27002 and extends it to the realities of cloud computing, where the line between who runs a control and who relies on it is no longer obvious.

ISO/IEC 27017 covers cloud security: how the generic ISO/IEC 27002 controls should be implemented when the service in question runs in the cloud, plus a small number of controls that only exist in a cloud context. ISO/IEC 27018 covers privacy in the cloud specifically: how a provider running a public cloud should protect the personally identifiable information (PII) its customers entrust to it.

The crucial thing to understand up front is that you do not certify against 27017 or 27018 by themselves. They are implemented and assessed as an extension to an ISO/IEC 27001 certification — you pull their controls into your management system and an accredited certification body checks them alongside the rest of your ISMS. If you already think in terms of ISO 27001, treat these two as additions to that scope, not separate projects.

Published in 2015, ISO/IEC 27017 is the code of practice for information security controls for cloud services. Most of it is implementation guidance: for the relevant controls already listed in ISO/IEC 27002, it explains what "doing the control" actually means once the system lives in someone else's cloud rather than in a server room you own.

On top of that guidance, 27017 adds a small set of controls that only make sense in a cloud context. These cover things like the shared roles and responsibilities between the cloud service provider and the cloud service customer, the removal and return of customer assets when a contract ends, hardening of virtual machines, the security of administrator operations on the cloud service, and the monitoring of the cloud service itself.

It is written for both sides of the relationship. A cloud service provider reads it to understand what it owes its customers; a cloud service customer reads it to understand what it must still do itself and what it can reasonably expect the provider to handle. That dual audience is exactly why the shared-responsibility model sits at the center of the standard.

ISO/IEC 27018, first published in 2014 and revised in 2019, is the code of practice for protecting personally identifiable information in public clouds that act as PII processors. Where 27017 is about security in the cloud generally, 27018 is narrowly about privacy: what a public-cloud provider must do when the data it holds belongs to its customers and identifies real people.

It adds privacy-focused controls and guidance on top of the ISO/IEC 27002 baseline. The themes will be familiar to anyone who has worked with modern privacy law: consent and choice over how PII is used, purpose limitation, transparency about sub-processors and about where data is stored, the ability to return or delete PII, and, as a defining provision, not using customer PII for the provider's own purposes such as advertising.

Because of that focus, 27018 connects naturally to privacy regulation. It does not replace the GDPR or the Swiss nFADP, and holding it is not the same as being compliant with either — but the controls it asks for line up closely with what those laws expect of a processor, which is why it is a common ask in privacy reviews from European and Swiss customers.

The single most important point about both standards is structural: they live inside an ISO/IEC 27001 certification, not beside it. There is no standalone "ISO 27017 certificate" or "ISO 27018 certificate" the way there is an ISO 27001 one. Instead you decide that the 27017 and/or 27018 controls are in scope for your information security management system, implement them, and let your certification body assess them as part of the same audit.

For a team that already holds, or is actively pursuing, ISO 27001, this is genuinely good news. You are not standing up a second management system, repeating a fresh risk assessment from scratch, or booking a separate audit cycle. You are extending the scope of the ISMS you already run, adding a defined set of cloud and privacy controls to the Statement of Applicability you already maintain.

Practically, that means the order of operations matters. ISO 27001 comes first; 27017 and 27018 are layered on once that foundation exists. Trying to chase the cloud extensions without the management system underneath them is putting the roof up before the walls.

Both standards are built on the same idea: in the cloud, no single party controls everything, so security and privacy are shared between the cloud service provider and the cloud service customer. The provider secures the parts it runs; the customer secures the parts it configures and the data it puts in. A control that is fully the provider's job in one arrangement can be partly or wholly the customer's job in another.

Most cloud incidents that make the news are not the provider failing its half — they are a customer assuming the provider had a control covered when responsibility for it actually sat with them. ISO/IEC 27017 spends real effort making this split explicit precisely because the ambiguity is where things go wrong.

For your own ISMS this means each in-scope control needs an owner, written down: ours, the provider's, or shared with a clear boundary. Doing that mapping honestly is most of the work of adopting 27017 and 27018 — and it is exactly the part teams skip when they treat the standards as a checklist rather than a division of labour.

These standards are mostly pursued by cloud service providers and SaaS vendors — teams whose product runs in the cloud and whose customers run their data through it. The trigger is almost always external: a prospect's security or privacy review asks, on top of ISO 27001, for cloud-specific security assurance (27017) or cloud PII protection (27018), and the deal stalls until you can point to them.

ISO 27017 tends to come up when a customer cares about how their workloads are secured in your cloud — the hardening, the administrator access, the clean return of their assets when they leave. ISO 27018 comes up when the customer is itself accountable for personal data and needs to show its own regulators that its processor handles PII responsibly. For a European or Swiss buyer weighing the GDPR or the Swiss nFADP, that 27018 line on your certificate scope is a shortcut through a long questionnaire.

If you are not a cloud provider, or your customers have never raised cloud-specific or PII-specific concerns, these may not be worth the added scope yet. The honest test is the same as for any framework: are these questions costing or slowing deals? If they are, extending your ISO 27001 scope to answer them cleanly is usually cheaper than answering them ad hoc forever.

Because 27017 and 27018 ride on an ISO 27001 certification, the mechanics follow the 27001 audit you already know. You add the cloud and privacy controls to your Statement of Applicability, implement them, gather the evidence that they operate, and the accredited certification body assesses them in the same Stage 1 and Stage 2 audits, and the same annual surveillance and three-year recertification cycle, as the rest of your ISMS.

There is no separate certificate to frame. What changes is the scope statement on your ISO 27001 certificate: it records that the 27017 and/or 27018 controls were included and assessed. That single line is what a customer's reviewer looks for, so it is worth getting the scope wording right rather than leaving the cloud extensions implicit.

Sequencing-wise, the cheapest path is to fold the extensions into a recertification or a planned surveillance audit rather than booking extra audit time mid-cycle — but if a deal is waiting on it, certification bodies can assess an added scope sooner. Either way the heavy lifting is the control work, not the audit logistics.

Cloud estates change faster than almost anything else in an ISMS. New services get adopted, sub-processors come and go, data moves between regions, and administrator access is granted and revoked weekly. The 27017 and 27018 controls are only as good as how current that picture is — a shared-responsibility split documented eighteen months ago, against an architecture that has since moved on, will not survive a surveillance audit.

The same maintenance discipline that keeps ISO 27001 alive keeps these current: the responsibility ownership accurate, the sub-processor and data-location records up to date, the evidence flowing rather than reconstructed before each audit. Because the cloud extensions sit inside the same management system, the upkeep is shared work, done once across the whole scope, rather than a second binder to keep alive on its own.