ISO 27017 and 27018: the cloud extensions worth adding, and when they are not

A customer questionnaire arrives asking whether you hold ISO 27017 and ISO 27018. You have 27001. The question is whether the extensions are worth doing, and the answer depends almost entirely on which side of the cloud relationship you are on.

Neither is a standalone certification. Both are codes of practice that extend ISO 27002's guidance, and both are audited as an extension of an existing ISO 27001 certification — usually in the same audit, by the same body, with a modest incremental fee.

ISO 27017: cloud-specific controls

ISO 27017 adds implementation guidance for existing ISO 27002 controls in a cloud context, plus seven additional cloud-specific controls. It addresses both cloud service providers and cloud service customers, and states which party each piece of guidance is for — which is the genuinely useful part.

The additional controls cover:

• Shared roles and responsibilities within a cloud computing environment. The documented split of who does what, per service. This is the control most organisations discover they have never written down.
• Removal of cloud service customer assets on termination — data return and deletion, with timeframes.
• Segregation in virtual computing environments. Tenant isolation.
• Virtual machine hardening.
• Administrator's operational security. The privileged operations procedures.
• Monitoring of cloud services, including what the customer can observe about their own usage.
• Alignment of security management for virtual and physical networks.

If you are a cloud service provider — including a SaaS company, which most people forget counts — 27017 is directly relevant and its controls map to things your customers ask about in every security review. The exit and deletion control in particular answers a question that comes up in every enterprise negotiation.

If you are only a cloud customer, the standard is still useful as a checklist, but certifying against it says less. The certificate signals "we consume cloud responsibly", which is a weaker claim than customers usually want.

ISO 27018: personal data in public clouds

ISO 27018 is a code of practice for protecting personally identifiable information in public clouds, written for organisations acting as PII processors — processors, in GDPR language.

Its provisions cover consent and choice, purpose limitation, transparency about sub-processors and data locations, restrictions on using customer data for the provider's own purposes (notably advertising), obligations on disclosure to law enforcement, data return and deletion, and support for the customer's own obligations to data subjects.

The overlap with GDPR Article 28 is substantial, and that is the point: 27018 is a way of demonstrating to a controller that you, as their processor, have the processor-side controls in place, audited by a third party, without them having to audit you themselves.

Important caveat: ISO 27018 certification is not GDPR compliance and does not substitute for it. It covers the processor controls; it does not address lawful basis, data subject rights as a controller, international transfer mechanisms, or your DPA obligations. Claiming otherwise in marketing is a claim regulators have taken issue with. It is evidence supporting compliance, not compliance.

Who actually asks

In our experience the requests cluster:

• Enterprise procurement in Europe asks for 27001 and increasingly 27018 when personal data is involved.
• Public sector and regulated buyers ask for whatever their own framework maps to, which in Spain is more likely ENS than either extension.
• North American buyers ask for SOC 2 and rarely mention 27017 or 27018 at all.

So the honest test is: are you losing deals over this? If a specific customer or a specific tender asks, the extensions are cheap relative to the revenue. If nobody has asked, adding them because they sound thorough is spending audit budget on a certificate nobody reads.

What it costs to add

Because both extensions are audited alongside 27001, the incremental cost is the additional audit days plus the gap work. For a company that already has 27001 and runs on a hyperscaler, the gap is usually:

• Writing down the shared responsibility split per service — a real piece of work, and useful independently.
• Documenting the data deletion and return process with timeframes, and testing it.
• Formalising sub-processor disclosure and the notification process when it changes.
• Tenant isolation documentation, if you are multi-tenant.
• Evidence on administrator operational security: privileged access procedures, logging of administrative actions, and separation of duties.

Most of this exists in some form in a well-run SaaS company. Making it auditable is weeks, not months, and the artefacts — particularly the shared responsibility matrix and the deletion procedure — answer a large share of the security questionnaires you will receive anyway.

That is arguably the best reason to do them. The certificate is one line in a tender response; the documents you produce to get it shorten every customer security review that follows.