ISO 27018 for Cloud Providers: PII Protection in Public Cloud

Two layers. First, cloud-processor implementation guidance on existing 27002 controls: how policies, access control, cryptography, operations security, incident management, and compliance controls apply when the organization is a public cloud PII processor, for example, guidance that customer PII in diagnostic logs is still PII, and that returning media to vendors requires PII-erasure procedures. Second, an annex of additional controls derived from the ISO/IEC 29100 privacy principles, the substance most contracts cite: processing only on documented customer instructions; refusing to use PII for advertising, marketing, or profiling without explicit customer consent (and not making such consent a condition of service); providing means for customers to fulfill data-subject access, correction, and deletion obligations; transparency about subprocessors and the countries where PII may be processed, before contract and on change; prompt notification of unauthorized PII access; secure disposal and time-bounded deletion of temporary files; PII-specific confidentiality agreements for personnel; and records of PII disclosures. The philosophy: the customer is the controller, the provider a processor whose commercial temptations (data monetization, opaque subcontracting) the annex controls specifically foreclose.

Not as a freestanding certificate, 27018 is a code of practice (guidance), not a management-system requirements standard, so accredited certification against it alone does not exist in the way 27001 certification does. The standard practice: incorporate 27018's controls into the ISO 27001 ISMS (via the risk treatment and statement of applicability), and have the certification body audit them within the 27001 audit, with the certificate's scope statement then referencing 27018, this is what providers mean by being 'certified to' 27018, and buyers should read the actual scope wording. Alternatives seen in the market: independent third-party assessment reports against the 27018 control set; inclusion in SOC 2 examinations as mapped criteria; and self-attestation in trust documentation (the weakest form). Diligence questions that separate substance from branding: is 27018 named in the certificate scope, which entities and services are covered, does the SoA include the annex controls or only the guidance layer, and does the provider's DPA actually promise the annex commitments (instructions-only processing, no-advertising, subprocessor transparency) as contract terms? A scope statement without matching contract language delivers audit theater; the contract is where the standard's promises become enforceable.

27018 predates 27701 and covers a subset of its territory: 27018 is cloud-processor-specific guidance bolted to 27002; 27701 is a full privacy management system with controller and processor control sets, now standalone-certifiable. Overlap: 27701's processor controls address the same duties (instructions, subprocessors, customer assistance, disclosure records, return/deletion). What 27018 retains that 27701 lacks: cloud-specific granularity, the annex speaks directly to public-cloud mechanics (tenant isolation implications, temporary-file deletion, media handling, customer-controlled encryption options) where 27701 stays generic. What 27701 adds: the management-system wrapper (risk, audit, review, improvement), controller-side controls for the provider's own corporate processing, and a certificate with independent standing. Market reality: hyperscaler procurement baselines still name 27018 (it entered contract templates a decade ago), while enterprise privacy diligence increasingly asks for 27701. The efficient posture for a cloud provider: implement 27701 as the management system, fold 27018's annex controls into the SoA (they slot in cleanly), and carry both references on the 27001-family certificate, satisfying both the legacy contract language and the current diligence expectations with one program.

Article 28 requires processors to act only on documented instructions, ensure personnel confidentiality, secure processing, respect subprocessor authorization rules with flow-down, assist controllers with data-subject rights and breach duties, delete or return data at termination, and support audits. The 27018 annex maps onto this almost clause by clause: instructions-only processing (28(3)(a)), confidentiality undertakings (28(3)(b)), 27002 security controls (28(3)(c) and 32), subprocessor disclosure and objection opportunity (28(2) and 28(4)), customer-assistance controls (28(3)(e) and (f)), deletion and return (28(3)(g)), and disclosure records supporting audit rights (28(3)(h)). So a provider evidencing 27018 within a certified ISMS hands controllers a diligence artifact that answers most Article 28 questions with third-party-audited substance, and controllers can (and do) reference 27018 conformance in DPA security exhibits. The gaps to close contractually: Article 28's legal formalities (the DPA itself, authorization mechanics, liability allocation) and GDPR-specific timing (breach notification 'without undue delay' to the controller) need contract terms; the standard cannot supply them. For EU-facing cloud sales, the combination that works is a 27018-scoped certificate plus a DPA whose exhibits mirror the annex commitments verbatim.

Five checks. Scope: pull the actual 27001 certificate and read whether 27018 appears in the scope statement, and whether the services you buy are within the named scope, providers certify specific platforms and regions, and marketing pages blur this. Currency: certificate validity dates and the certification body's accreditation (look up the CB in the accreditation body's registry; unaccredited certificates exist). Contract mirroring: does the DPA promise the annex substance, instructions-only processing, no advertising use, subprocessor lists with change notification, deletion timelines, breach notification, as terms, not aspirations? Subprocessor transparency in practice: is the current subprocessor list published, is there a change-notification mechanism you can actually subscribe to, and do the listed processing countries match your transfer analysis? Evidence access: will the provider share the SoA excerpt, assessment reports, or audit summaries under NDA, and what audit rights does the DPA grant? A sixth, for regulated buyers: check how the claim composes with your own obligations, 27018 conformance does not make the provider's cloud HIPAA-eligible, PCI-compliant, or localization-compliant; those are separate analyses. Providers comfortable with all five checks are typically the ones whose conformance is real.