ISO/IEC 27018.

What ISO/IEC 27018 adds on top of ISO 27001

ISO/IEC 27018 is a code of practice, not a standalone management system. It assumes you already run an information security management system certified to ISO/IEC 27001, and it bolts a privacy layer onto that base. Specifically, it targets one role: a public cloud service provider acting as a processor of personally identifiable information (PII) on behalf of its customers. The standard takes the generic controls of ISO/IEC 27002 and reinterprets them for that processor context, then adds a set of cloud-specific privacy controls that ISO 27001 alone does not require.

The practical consequence is that ISO 27018 does not certify on its own. A provider is certified to ISO 27001 with ISO 27018 as the applicable control set inside the scope. That is why you see it expressed as "ISO 27001 certified, audited against ISO 27018" rather than as a separate certificate. The controls concern things a cloud customer cannot easily verify for themselves: whether the provider will use customer PII for its own advertising, whether subcontractors are disclosed before they are engaged, how data is handled at the end of a contract, and what happens when law enforcement asks for data.

Where it sits between ISO 27001, ISO 27017 and the GDPR

Three neighbouring references get confused with ISO 27018, and the distinctions matter when you are scoping an audit or filling a vendor questionnaire. ISO 27001 is the management system that governs information security generally. ISO 27017 is the cloud security code of practice, broader than privacy and concerned with the security of cloud services for both provider and customer. ISO 27018 is narrower than both: it is privacy, in public cloud, for the processor role only.

ISO 27018 is a useful bridge toward GDPR processor obligations because it operationalises ideas the regulation expresses in legal terms: purpose limitation, transparency over subcontracting, assistance to the controller, and return or deletion of data. But it is not a substitute. A certificate against ISO 27018 is evidence of good processor practice, not a finding of legal compliance. The GDPR allocates obligations through binding law and contracts between controller and processor; a standard cannot do that for you.

What practitioners actually do with it

For most organisations, ISO 27018 is something you consume rather than something you hold. When you select a cloud service and your data protection impact assessment or third-party risk process asks "is this processor trustworthy", the provider's ISO 27018 audit is one of the artefacts you collect, alongside ISO 27001 scope statements, SOC reports and the processing agreement.

• Confirm the certificate is current and that the cloud service you actually use falls inside the audited scope, not just the corporate ISMS.
• Read it together with ISO 27001 and ISO 27017, since the three are designed to be layered and a provider that holds all three has covered security and privacy in cloud more completely.
• Map the ISO 27018 controls to your own GDPR obligations rather than assuming overlap, because the standard supports the processor relationship but does not discharge the controller's legal duties.
• Keep the processing contract as the binding document. The standard signals intent; the data processing agreement is what you enforce.