What are the signs that a cloud provider may not be ready for ISO 27018 expectations?

A cloud provider may not be ready if it cannot clearly show where customer PII is stored, how it is scrubbed from reused space, or how retention obligations are documented. Weakness also shows up when privacy controls rely on vague language, missing contractual terms, or unsupported claims instead of evidence that procedures and logs are maintained.

What readiness looks like in practice

The clearest readiness signs are operational, not rhetorical. A provider should be able to show where customer PII is stored, which systems and tenants can touch it, how reused storage is scrubbed, and what retention and deletion rules apply. Under ISO 27018, privacy claims need to be backed by procedures, logs, and contract terms, not just policy language or sales assurances. ISO/IEC 27001:2022 Information Security Management remains the base reference for the ISMS controls that should support those privacy commitments.

Readiness also depends on whether the provider can distinguish between what it promises as a controller-facing obligation and what it actually executes as a cloud operator. If customer data handling is scattered across service descriptions, support notes, and vague privacy clauses, the provider may not yet have the process discipline needed for ISO 27018 expectations. That gap usually shows up first in weak evidence quality: missing retention records, incomplete deletion proof, or unclear responsibility for shared-environment sanitisation. For cloud control context, ISO/IEC 27002:2022 Information Security Controls provides the implementation guidance that should make those obligations testable.

For buyers, the question is not whether the provider says it protects privacy, but whether it can demonstrate repeatable handling of customer PII throughout the lifecycle. If staff cannot answer basic questions about location, retention, erasure, and reuse of storage without escalation or custom exceptions, that is a sign the provider is still relying on ad hoc controls rather than a mature privacy operating model. A provider that is ready for ISO 27018 should make those answers routine, documented, and auditable.

Where readiness usually breaks down

Most failures appear in three places: data location transparency, storage sanitisation, and contractual precision. If the provider cannot identify where PII resides, including backups or reused capacity, it cannot reliably prove that deletion and retention commitments are being met. If it cannot explain how residual data is removed from recycled infrastructure, the customer cannot judge whether exposure persists after a contract ends or a tenant is migrated.

Another common failure is control drift between legal language and technical practice. A provider may advertise privacy protections, yet its customer terms, subprocessors, and support processes do not clearly assign responsibilities for erasure, retention, or disclosure handling. That mismatch matters because ISO 27018 expects privacy commitments to be operationally credible, not merely commercially attractive. If the documentation is generic, outdated, or inconsistent across documents, the provider is probably not ready.

Finally, weak evidence handling is a practical warning sign. If the provider cannot produce logs, records, or internal procedures that corroborate privacy operations, the control may exist in name only. The same is true when privacy claims are described with broad assurances such as “industry standard” or “secure by design” but there is no traceable proof of how customer PII is isolated, retained, deleted, or audited.

What buyers should verify before relying on ISO 27018 claims

Buyers should verify the provider’s answers against specific operational artefacts, not just a certification badge or policy excerpt. The most useful checks are whether the provider can show data-location boundaries, retention schedules, deletion workflow evidence, and the contractual clauses that govern customer PII handling. If any of those are missing, treat the ISO 27018 claim as incomplete until the provider can close the gap.

It also helps to separate “can explain” from “can prove.” A mature provider can explain how its service handles PII and can also show the supporting records, such as audit logs, admin procedures, deletion tickets, or scrub records for reused infrastructure. When those artefacts are unavailable, the control posture is weaker than the marketing implies.

For a broader governance lens, Identity Security Regulatory Map is a useful reminder that privacy and security commitments often need to line up across multiple regulatory and control expectations, not just one standard. A provider that is serious about readiness should be able to map its obligations cleanly and show evidence that the mapped controls are actually operating.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

ISO/IEC 27001:2022 and SOC 2 (AICPA) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
ISO/IEC 27001:2022	A.5.15 — Access control	Access control underpins who can touch customer PII and supporting records.
	A.5.23 — Information security for use of cloud services	Cloud service use is central because the provider's privacy obligations are delivered through its cloud environment.
	A.8.10 — Information deletion	Retention and deletion proof are core signs of ISO 27018 readiness.
Recommendation — Verify access restrictions around customer PII and the systems that process it. Assess cloud-specific privacy controls for tenant isolation, retention, and deletion evidence. Require documented deletion procedures and evidence for customer PII and backups.
SOC 2 (AICPA)	CC6.1 — Logical and Physical Access Controls	Access control evidence is relevant when judging whether privacy handling is operationally enforced.
	CC8.1 — Change Management	Change control matters when privacy controls, retention settings, or deletion workflows can drift.
Recommendation — Confirm only authorised personnel and systems can access customer PII. Track changes to retention, sanitisation, and deletion processes with formal approval and evidence.

Practitioner Guidance

What to verify: Ask for a concrete walkthrough of one customer data set from ingestion to deletion, including storage locations, backup handling, reuse sanitisation, and retention triggers. If the provider cannot trace the full path, it is not ready to support ISO 27018-style assurance.

Common mistake: Do not accept policy language as proof of readiness. For this subject, the control question is whether privacy handling is operationally evidenced, contractually bound, and consistently executed across the service.

Decision rule: If a provider cannot show where customer PII lives and how it is removed from reused space, treat the issue as a control deficiency, not a documentation gap, and escalate before signing or renewing the contract.

Practitioner takeaway: ISO 27018 readiness is demonstrated by traceable privacy operations, not by privacy claims; if the provider cannot prove data location, sanitisation, retention, and deletion, it is not ready enough yet.