ISO/IEC 27018: PII processor controls for public cloud — not a GDPR certificate

ISO/IEC 27018 gives privacy control guidance for public cloud service providers acting as PII processors. It is commonly used in enterprise procurement because customers want evidence that cloud providers use customer data only under instructions and handle return, deletion, and subprocessors responsibly.

The checklist is useful for execution, but the guide explains the judgment behind it: whether the provider is really acting as a processor, where customer PII appears, how backups and tickets are handled, and whether product analytics or model training contradict customer commitments.

In 2026, cloud privacy assurance is tested through contracts, support workflows, AI features, observability platforms, and retention systems. A privacy statement is not enough if customer PII leaks into tickets, logs, training sets, or unmanaged backups. For ISO 27018, the guide should follow customer PII into the less obvious places. Production databases are only one store. Observability events, support tickets, exported reports, AI evaluation datasets, abuse investigations, backups, and subprocessor tools may all contain customer information. Each path needs a purpose, access rule, retention expectation, and deletion story. The processor promise is also tested by product improvement and training uses: if the provider benefits from customer PII beyond instructions, contracts and controls need to say so clearly or stop it. The paired checklist should help privacy, support, SRE, ML, and legal teams agree on what customer data is used for and where it can persist. A useful way to read the rest of this guide is to separate evidence from judgment. Evidence shows that an activity happened: a review, record, test, approval, training, scan, exercise, assessment, or decision. Judgment explains why the activity was scoped that way, why the risk treatment is proportionate, why an exception is acceptable, and what would cause the decision to change. The paired checklist should collect evidence and owners, while the guide should help teams avoid false certainty. For each topic, ask what a knowledgeable reviewer would challenge after seeing the first answer. They may ask whether the scope matches production, whether suppliers are included, whether recurring work is current, whether leadership approved trade-offs, and whether public or customer-facing claims match operations. That second layer is where preparation becomes credible. It also keeps teams from overclaiming, because a documented limitation with a plan is usually stronger than a broad statement no one can support. Keep a dated rationale beside the evidence so reviewers can see what changed, who approved the interpretation, and which operating signal would trigger a fresh review. Keep the reviewer-facing story specific enough that another team can repeat the analysis without guessing.