ISO 27018: PII Protection in Public Clouds Explained

ISO/IEC 27018 (first published 2014, current edition 2019) is a code of practice targeting one precisely drawn role: the public cloud service provider acting as a PII processor, processing personally identifiable information on behalf of and per the instructions of its customers (the PII controllers or their processors). Structurally it does two things: augments relevant ISO 27002 controls with PII-in-the-cloud implementation guidance, and adds an annex of additional controls derived from the privacy principles of ISO/IEC 29100 (consent and choice, purpose legitimacy, data minimization, use limitation, transparency, accountability, and the rest), covering ground ordinary security standards never reach. It is deliberately not for controllers (their cloud privacy obligations run through ISO 27701's controller controls and the underlying law), not a management-system standard (ISO 27001 supplies that), and not a legal-compliance certificate (it standardizes processor conduct, not GDPR conformity). Who actually uses it: IaaS, PaaS, and SaaS providers processing customer personal data, which is functionally the entire cloud industry, as a way to implement and demonstrate processor discipline; and their customers, who read a provider's 27018 attestation as evidence the provider has institutionalized the commitments every data protection regime demands of processors. The 2019 edition is a minor revision of the 2014 original; its concepts fed directly into ISO 27701, which absorbed and extended the same processor-control territory into a certifiable management system.

The annex controls read like a well-negotiated DPA rendered as engineering requirements. Instructions-only processing: the provider processes PII only per documented customer instructions, with contract terms capturing them. No advertising or marketing use: customer PII must not be used for advertising, marketing, or profiling purposes without the customer's (and where required the data subject's) explicit consent, and such consent cannot be a condition of service, the control that historically differentiated enterprise cloud offerings from consumer services that mined hosted data. Transparency about locations and subprocessors: disclose the countries where PII may be stored or processed and the subcontractors involved, with advance notice of changes, giving customers the information their transfer assessments and Article 28(2) approvals require. Data subject assistance: provide the customer the means to fulfill access, correction, and deletion obligations toward data subjects. Disclosure requests: notify the customer of any legally binding request for disclosure of PII (law enforcement demands) unless prohibited, reject non-binding requests, and record all disclosures, the government-access transparency machinery. Breach support: notify the customer promptly of unauthorized access or PII incidents with enough detail to meet the customer's own notification clocks, and document incident response. Return, transfer, and disposal: defined mechanics for returning or securely erasing PII at contract end, including temporary files and backups on defined schedules. Personnel: confidentiality undertakings and PII-specific training for staff with access. Encryption and hardening guidance runs through the augmented 27002 controls. Each maps to a clause your DPA should contain; the standard's practical gift is that providers implementing it have pre-built the operational machinery those clauses promise.

Article 28 requires controllers to use only processors providing sufficient guarantees of appropriate technical and organizational measures, and to bind them with contracts containing specific terms: documented instructions, confidentiality, security, subprocessor authorization and flow-down, data subject assistance, breach assistance, deletion or return, and audit rights. ISO 27018 maps onto this almost clause for clause, instructions-only processing, personnel confidentiality, the augmented security controls, subprocessor transparency, data-subject-assistance machinery, breach notification support, and return-or-erase mechanics, which is why a current 27018 attestation (within a 27001 certificate whose scope covers the relevant services) has become conventional evidence in the 'sufficient guarantees' file: it shows an accredited third party audited the processor's implementation of exactly the capabilities Article 28 contracts promise. Precision matters though: the attestation is evidence, not conformity, Article 28's contract must still exist with its mandatory terms (the certificate does not substitute for the DPA); audit rights still need contractual grounding (27018 does not grant them); international-transfer compliance (Chapter V mechanisms, transfer impact assessments) is a separate analysis the location-transparency controls merely feed; and scope checking is essential, a certificate covering the provider's core platform may not cover the acquired product line your data actually sits in. Used correctly, in a vendor-diligence workflow: collect the certificate and scope statement, verify accreditation and dates, map the annex commitments against your DPA's clauses, flag gaps for negotiation, and file the package as the due-diligence record your accountability obligations require, refreshed at recertification.

The mechanism mirrors ISO 27017's: 27018 is a code of practice rather than a requirements standard, so there is no freestanding accredited 27018 certificate; providers incorporate the 27018 controls into their ISO 27001 ISMS, the Statement of Applicability includes the annex controls, the certification body audits them within the ISMS audit, and the certificate references 27018 in scope, this is what AWS, Microsoft, Google, and the major SaaS platforms publish in their trust portals. Reading one in diligence: verify the certification body's accreditation (IAF-member accreditation bodies); read the scope statement service by service, hyperscaler certificates enumerate covered services, and the newest offerings often trail the list by a cycle; check currency (three-year certificate cycle, annual surveillance); and calibrate what it proves, the provider's management system addresses PII-processor controls; it does not prove your specific configuration inherits them (your key management, your access design, your retention settings remain your responsibility per the shared-responsibility allocation), does not prove GDPR compliance, and does not cover controller obligations (purposes, bases, notices) that never belonged to the processor. For providers pursuing attestation: the work concentrates in productizing customer-facing machinery, instruction capture, subprocessor registries with notification workflows, disclosure-request handling with logging, per-service data-location documentation, deletion pipelines that actually reach backups, because auditors test the machinery, and customers increasingly test it harder than auditors do.

The three occupy one architecture with different centers of gravity. ISO 27017 secures cloud services generally, any data, both provider and customer perspectives, with its CLD controls on responsibility allocation, segregation, and monitoring; ISO 27018 governs one data category (PII) in one role (public-cloud processor), adding the privacy-principle controls security standards omit; ISO 27701 is the full privacy information management system, a certifiable requirements standard (not just a code of practice) with controller and processor control sets, absorbing 27018's territory and extending it into governance, and since its 2025 edition certifiable standalone as well as atop ISO 27001. Sequencing for a cloud provider: 27001 first, always, it is the chassis everything else rides; then 27017 and 27018 together in the next surveillance or recertification cycle, they share the audit and answer complementary questionnaires (CISO and DPO respectively); then 27701 when privacy certification demand justifies a management-system commitment beyond codes of practice, typically when enterprise customers or EU market positioning start asking for certified privacy governance rather than control attestations. Sequencing for a cloud customer doing diligence: require 27001 as baseline, treat 27017/27018 references in scope as the cloud- and PII-specific evidence layers, and treat a vendor's 27701 certificate as the strongest generic signal of institutionalized privacy governance, while remembering the invariant that no vendor certificate covers your own controller obligations or your configuration of their platform. The economical summary: 27017 answers 'is the cloud service secure and is responsibility allocated,' 27018 answers 'will they treat the PII we entrust properly,' 27701 answers 'is privacy managed as a system,' and 27001 is why any of the answers can be audited at all.