ISO/IEC 27018 for Cloud Privacy: Scope, Evidence and Due Diligence

ISO/IEC 27018:2025 gives public cloud providers privacy-focused guidance when they process personally identifiable information (PII) for customers. It can strengthen a provider’s ISO/IEC 27001-based management system, but it does not transfer the customer’s legal accountability or turn a broad assurance claim into proof for every service.

The useful way to apply ISO 27018 is to connect its scope to a real cloud service, clarify provider and customer responsibilities, and test evidence across the PII lifecycle. A logo or sales statement is only the beginning of that work.

Use the current edition and the correct role

ISO/IEC 27018:2025 is the current third edition. ISO published it in August 2025 and aligned it with ISO/IEC 27002:2022. It provides guidance for protecting PII in public cloud services where the cloud provider acts as a PII processor. It complements an ISO/IEC 27001 ISMS and adapts ISO/IEC 27002 guidance to this processing context.

That scope contains three gates:

• the service is a public cloud service;
• the information is PII; and
• the provider processes it on behalf of a customer.

A provider can occupy more than one role. It may process customer content under instructions while independently deciding purposes for billing, fraud detection or product analytics. Those activities require separate analysis. Customers also retain responsibilities for configuration, identities, data classification, lawful use and user requests.

What ISO 27018 adds to cloud assurance

ISO 27001 establishes the management system: context, leadership, risk, resources, operation, evaluation and improvement. ISO 27002 supplies general information-security control guidance. ISO 27018 focuses that foundation on public-cloud PII processing and privacy principles.

For an assurance review, group the useful outcomes into five areas rather than trying to recite controls.

Processing purpose and instructions

The provider should be able to explain how it receives and follows customer instructions, how incompatible uses are prevented and how service personnel learn the boundaries of authorised processing. Evidence may include contract terms, service descriptions, internal role definitions, approval workflows for new uses and training records.

The customer should compare those materials with actual use. Optional telemetry, support access and artificial-intelligence features can change the data flow. A contractual purpose statement that no longer matches production is weak evidence.

Transparency and location

Customers need enough information to understand where processing occurs, which subprocessors participate and how material changes are communicated. Useful evidence includes a current subprocessor register, region architecture, change-notice history and the service’s responsibility model.

Transparency does not mean a provider must expose other customers’ data or sensitive defensive details. It means the customer can make informed risk and legal decisions using accurate service-specific information.

Access, disclosure and requests

Provider access should be limited, authorised, monitored and reviewed. The service should also support the customer’s handling of access, correction, deletion or export obligations where applicable. Examine administrative access populations, just-in-time approvals, session records, request handling, escalation paths and service limitations.

Government or legal disclosure requests need controlled intake, validation, approval and recording. Contractual and legal restrictions affect what can be notified, so avoid absolute promises that cannot be supported.

Retention, return and deletion

Cloud deletion is a lifecycle, not a button. Customers should understand active-data deletion, replicas, backups, temporary files, logs, support copies and post-termination handling. Evidence may include retention specifications, deletion workflows, test results and exception records.

The provider should define what the service can do; the customer must configure retention and trigger deletion appropriately. If deletion from immutable backups occurs through expiry rather than immediate removal, that behavior should be explicit and risk-assessed.

Incidents and accountability

Cloud incident processes should connect technical detection to customer notification and assistance. Review how the provider determines affected tenants, preserves evidence, approves messages and supplies facts needed for the customer’s own regulatory assessment.

The incident-management evidence guide helps distinguish process documents from records demonstrating actual response. Contractual notice periods and channels should be tested during exercises, not discovered during a breach.

Evaluate assurance claims precisely

ISO 27018 is guidance that can be incorporated into an ISMS and assessed in different ways. Do not assume every statement such as “aligned with ISO 27018” has the same assurance value.

Ask the provider for:

1. the exact service, legal entity, locations and activities covered;
2. the edition used, including whether it is ISO/IEC 27018:2025;
3. the relationship between the claim and its ISO 27001 scope;
4. the form of assessment and the competent party that performed it;
5. relevant exclusions, shared responsibilities and unresolved findings; and
6. the period for which operating evidence was examined.

A certificate or independent report can reduce duplicated work, but the customer must still test whether its tenant, configuration, data and obligations fit the scope. The CISPE and ISO 27001 comparison provides another example of why a code, standard and service-specific control model must be separated.

Build a customer-side evidence pack

Customers should preserve their own decision trail instead of relying on provider materials alone. A practical evidence pack contains:

• service owner and privacy owner;
• PII categories, purposes, data subjects and legal roles;
• approved regions and data flows;
• provider and customer responsibility assignments;
• risk assessment and treatment decisions;
• contract, processing terms and subprocessor conditions;
• provider assurance reviewed and scope limitations;
• tenant configuration records;
• incident and exit procedures; and
• monitoring, change review and renewal decisions.

Use the supplier-audit guide when deeper verification is justified. The Annex A control lookup can help locate supporting control themes, but it does not determine privacy-law applicability.

Sample across the service lifecycle

A point-in-time architecture review cannot demonstrate continuing protection. Select samples from different stages:

Stage	Provider evidence	Customer evidence
Selection	Service scope, locations, subprocessors, assurance	Risk classification and approval
Configuration	Security options and responsibility model	Tenant settings and exceptions
Operation	Access reviews, monitoring, changes, support activity	User reviews, log review, service oversight
Incident	Detection, tenant impact analysis, notification process	Escalation, legal assessment and exercises
Exit	Export and deletion capabilities	Exit test, retention decision and closure

For administrative access, sample both routine and emergency events. For deletion, trace one completed request through primary storage and documented downstream behavior. For subprocessors, choose a provider material to the service and verify that notice and review occurred.

Pass, partial and fail examples

Pass: The current assurance scope names the service and role, responsibilities reconcile with tenant controls, samples show restricted provider access, and tested deletion and incident processes match contractual commitments.

Partial: The provider presents current ISO 27018-aligned assurance, but one major subprocessor was added without evidence of the customer’s required review. Core controls may operate while customer governance remains incomplete.

Fail: Marketing claims reference a withdrawn edition, the service scope is unclear, and neither party can explain PII locations, provider access or post-termination deletion.

Avoid common interpretation errors

Several conclusions are unsafe:

• “The provider uses ISO 27018, so our processing is lawful.” Legal basis and controller duties remain separate.
• “ISO 27018 replaces ISO 27001.” It is complementary guidance, not an ISMS substitute.
• “The customer has no security work.” Shared responsibility leaves configuration, identities and use with the customer.
• “All provider services are covered.” Scope must be verified.
• “Deletion is immediate everywhere.” Architecture and retention design determine actual behavior.

Make the standard useful

ISO 27018 is most valuable when it improves decisions and evidence at the cloud boundary. Define roles, verify the current edition, reconcile assurance scope to the purchased service and test responsibilities over time.

Providers should integrate privacy controls into risk management, engineering and operations. Customers should retain their own processing, configuration and oversight evidence. Together, those practices turn an abstract standard reference into defensible cloud assurance.