ISO/IEC 27018 Cloud PII Protection Guide

When personal data moves into a public cloud, the controller stays accountable for it while the provider does the processing, and contracts alone rarely show whether the provider handles that data properly. ISO/IEC 27018 is the ISO code of practice for public cloud providers acting as processors of personally identifiable information (PII): it builds on ISO/IEC 27002 and adds controls for consent, disclosure, sub-processors, data location, return and deletion. This guide covers the current 2025 edition, what the standard asks of providers, how customers should use a provider's ISO/IEC 27018 certificate, how it relates to ISO/IEC 27701 and GDPR processor duties, and where identities and access fit. It is for privacy and security leads, cloud and SaaS providers preparing for certification, and procurement teams assessing cloud processors.

Key takeaways

It is written for the processor, not the controller. ISO/IEC 27018 targets public cloud providers that process PII under contract; controllers can use it but carry additional obligations it does not cover.
The current edition is ISO/IEC 27018:2025. Published on 26 August 2025, it replaced the 2019 edition, is aligned with ISO/IEC 27002:2022 and adds a new Annex B with extended implementation guidance.
Its value is in specific promises. Providers describe concrete commitments: no advertising use of customer data without consent, disclosure of sub-processors, notice of law enforcement requests where lawful, and return or deletion at the end of the contract.
It is certified inside an ISMS. Providers are audited against ISO/IEC 27018 alongside ISO/IEC 27001; Microsoft states its cloud services are audited at least once a year.
Access to PII is mostly machine access. Support tooling, pipelines and service accounts touch customer PII far more often than people, so the provider's access controls and logs for non-human identities are central evidence.

What it is and who it applies to

ISO/IEC 27018 comes from joint technical committee ISO/IEC JTC 1/SC 27. The ISO catalogue summary of the 2019 edition describes commonly accepted control objectives, controls and guidelines for implementing measures to protect PII in line with the privacy principles of ISO/IEC 29100 for the public cloud computing environment, building on ISO/IEC 27002 and taking into account regulatory requirements for PII protection. It applies to organisations of all sizes that provide information processing services as PII processors via cloud computing under contract.

Edition	Published	Status (ISO catalogue)	Notes
ISO/IEC 27018:2014 (edition 1)	2014	Withdrawn, replaced by 2019 edition	First edition; many provider pages still refer to it
ISO/IEC 27018:2019 (edition 2, 23 pages)	15 January 2019	Withdrawn 26 August 2025	Built on ISO/IEC 27002 and ISO/IEC 29100
ISO/IEC 27018:2025 (edition 3, 35 pages)	26 August 2025	Published, stage 60.60	Aligned with ISO/IEC 27002:2022; new Annex B with extended implementation guidance

Public cloud providers: IaaS, PaaS and SaaS providers that hold customer PII. AWS lists certification to the 2019 edition, Google Cloud to the 2025 edition, and Microsoft publishes ISO/IEC 27018 offering details for Azure, Microsoft 365 and Dynamics 365.
SaaS vendors: any SaaS company processing its customers' personal data is a PII processor and can scope ISO/IEC 27018 into its ISO/IEC 27001 certification.
Controllers buying cloud: use it to set expectations and to evidence due diligence on processors. See the GDPR Compliance Guide for Security Teams.
Out of scope: the controller's own lawful basis, transparency and data subject management. ISO/IEC 27701 is the management system for those. See the ISO/IEC 27701 Privacy Information Management Guide.

Structure and key requirements

ISO/IEC 27018 has two layers: PII-specific implementation guidance added to existing ISO/IEC 27002 controls, and an extended control set for public cloud PII processors derived from the ISO/IEC 29100 privacy principles. The 2025 edition realigns the first layer to the ISO/IEC 27002:2022 control set and adds Annex B. This guide does not reproduce clause text or numbering. The table summarises the commitments as cloud providers themselves describe them, which is how most customers meet the standard in practice.

Area	What providers commit to (as published)	What the customer should verify
Purpose and consent	Customer data not used for marketing or advertising without explicit consent, and consent not a condition of the service (Microsoft)	Data processing terms limit use to the customer's instructions; any secondary use is opt-in
Law enforcement disclosure	Disclose only on legally binding requests and notify the customer unless prohibited by law (Microsoft)	Disclosure policy, transparency reporting, contract notice clause
Return, transfer and deletion	Policy for return, transfer and secure disposal within a reasonable period (Microsoft)	Deletion timelines, backup expiry, deletion confirmation on request
Sub-processors	Proactive disclosure of sub-processors that need access to customer data (Microsoft)	Current sub-processor list, change notification, right to object
Data location	Inform customers of countries or regions where data may be stored (Microsoft)	Region selection, residency settings, transfer mechanisms. See the Data Sovereignty and Residency Guide.
Scope of protection	AWS states it applies its privacy controls to all customer content, not only PII	Whether service data and telemetry about your users are also covered (Google limits some Workspace scope to where it acts as a processor of Service Data)
Security of processing	ISO/IEC 27002 controls with PII-specific guidance, under an accredited certification	Certificate scope, encryption, key ownership, access logging

How it relates to GDPR processor contracts

ISO/IEC 27018 does not make a provider GDPR compliant, but its commitments line up with the processor contract terms the UK ICO lists under Article 28(3): processing only on documented instructions, confidentiality of authorised personnel, security measures meeting Article 32, sub-processor authorisation and flow-down, assistance with data subject rights, assistance with security, breach notification and DPIAs, deletion or return at the end of the contract, and information and audits to demonstrate compliance. The ICO notes this guidance is under review following the Data (Use and Access) Act. A certificate is useful evidence for the audit and information duty, not a replacement for the contract. See the DPIA Guide.

Identity and NHI requirements

The question a controller most wants answered is who, or what, can read its customers' personal data inside the provider. In modern platforms that is mostly automation: support tooling, backup jobs, analytics pipelines, AI features and service accounts acting across tenants.

Access path to PII	Provider control to look for	Customer control
Provider staff and support access	Just-in-time, approved, logged access; customer approval workflows where offered	Enable approval features where available and review the logs
Provider service accounts and pipelines	Scoped per function, no standing cross-tenant access, credentials not long-lived	Ask for this in due diligence; it sits under the security of processing commitment
Customer workload identities	Fine-grained roles and conditional access features	Least privilege roles on PII stores, owner per identity, rotation or federation
Integrations and sub-processors	Disclosed sub-processors with equivalent obligations	Inventory OAuth grants and API keys that let third parties read PII
Sharing links and tokens	Expiry and scope options on shared access mechanisms	Policies banning non-expiring, broad-scope tokens on PII stores

Map these to NIST SP 800-53 AC-6 (least privilege) and AU-2 (event logging), and to CSF PR.AA-05. See the Service Account Security Guide and the Secrets Management Guide.

Implementation steps

For a provider seeking certification

Confirm you are a PII processor. Identify the services where you process customer PII under contract; where you also act as a controller (for example your own marketing), handle that separately under ISO/IEC 27701 or your privacy programme.
Buy ISO/IEC 27018:2025 and run a gap assessment against your ISO/IEC 27001 ISMS, using the 2022 control set as the base.
Write the customer-facing commitments. Data processing terms covering purpose limitation, disclosure requests, sub-processors, location, return and deletion, and breach notification.
Engineer deletion and export. Define retention for primary data, backups and logs; prove deletion works within the stated period.
Lock down internal access to PII. Inventory every human and non-human identity with access to customer data, remove standing access, and log every access.
Update the Statement of Applicability and agree with your certification body to add ISO/IEC 27018 to scope at the next surveillance or recertification audit.
Pilot first: certify one product line or Region, then extend. Keep the prior commitments in force until new processes are proven, so you can fall back without breaching contracts.

For a customer (controller)

Classify which cloud services hold personal data and of what sensitivity. See the Data Classification Guide.
Collect each provider's ISO/IEC 27018 certificate and check the edition, services, Regions and dates.
Map certificate commitments to your Article 28 contract terms and record gaps.
Configure customer-side controls: region selection, encryption with keys you control where justified, access reviews, logging.
Test a deletion and an export request end to end at least annually.

Decision guidance

Situation	Recommended route
Small SaaS selling to EU enterprises	ISO/IEC 27001 with ISO/IEC 27018 controls in scope gives a recognised answer to processor due diligence
Organisation acting as both controller and processor	ISO/IEC 27701:2025, now a standalone management system standard, for the PIMS; ISO/IEC 27018 for cloud processor controls
Customer choosing between providers	Treat ISO/IEC 27018 as a baseline; differentiate on scope, deletion timelines, sub-processor transparency and key control
Highly sensitive data	Add customer-managed keys or confidential computing on top of certificate assurance. See the Confidential Computing Guide.

Evidence and assessment

Who audits: accredited certification bodies, as part of ISO/IEC 27001 audits. AWS names EY CertifyPoint; Microsoft's FAQ names BSI for Office 365; Google states an independent third party audited its ISMS.
Where to get evidence: AWS publishes certificate PDFs and its ISO Certified services list; Microsoft uses the Service Trust Portal; Google uses Compliance Reports Manager.
Provider audit evidence: Statement of Applicability, data processing terms, sub-processor register, disclosure request log and policy, deletion records, access logs for PII stores, breach notification procedure and tests.
Customer evidence: processor register with certificate details, Article 28 contract review, records of deletion and export tests, and access reviews of your own identities on PII stores.
Limit of inheritance: Microsoft states customers may use its attestation in their own assessments but must engage their own assessor for their own controls.

Detection and measurement

Processor coverage: percentage of cloud processors of personal data with a current ISO/IEC 27018 certificate or equivalent evidence.
Deletion assurance: deletion requests completed within the contractual period, as a percentage.
Sub-processor change response: share of sub-processor change notices reviewed before the objection window closes.
Standing access to PII: number of human and non-human identities with standing read access to PII stores, trending down.
Access logging coverage: percentage of PII stores with data access logging enabled and reviewed.

Mapping to other frameworks

ISO/IEC 27018 area	ISO/IEC 27001:2022 Annex A	NIST SP 800-53 Rev. 5	NIST CSF 2.0	GDPR
Purpose limitation and consent	5.34 privacy and protection of PII	PT-2, PT-3	GV.OC-03	Art. 28(3) documented instructions
Sub-processors and supplier terms	5.19 to 5.23	SA-9	GV.SC-05, GV.SC-07	Art. 28(2) and 28(4)
Data location	5.23	SA-9(5)	GV.SC-05	Chapter V transfers
Return and deletion	8.10 information deletion	MP-6, SI-12	GV.SC-10	Art. 28(3)(g)
Security of processing	8.24 cryptography, 8.11 data masking	SC-12, SC-28	PR.DS-01	Art. 32
Access to PII	8.2, 8.15	AC-6, AU-2	PR.AA-05	Art. 32

For the provider's general cloud security controls see the ISO/IEC 27017 Cloud Security Controls Guide; for the ISMS see the ISO 27001 Certification Guide; for masking techniques see the Tokenisation and Data Masking Guide.

Common pitfalls

Assuming the processor certificate covers the controller's configuration. In the Snowflake breach, personal data of about 100 million people was taken from customer accounts that lacked MFA, credential rotation and network allow lists; Snowflake found no flaw in its own platform. Processor assurance does not secure the customer's identities.
Uncontrolled sharing of stored data. The Microsoft SAS token exposure showed how one broad, long-lived token on a storage account can expose far more than intended, including internal messages and secrets.
Relying on an outdated edition. Provider pages cite 2014, 2019 and 2025 editions side by side; check what the certificate actually says.
Ignoring backups and logs in deletion. Deleting the primary record while copies persist in backups, analytics stores or logs beyond the stated period.
Sub-processor lists nobody reads. Change notifications arrive, the objection window lapses, and a new sub-processor with PII access goes unassessed.
Using ISO/IEC 27018 for controller duties. Lawful basis, transparency and rights handling need ISO/IEC 27701 or a privacy programme. See the Privacy Programme Guide for Security Teams.

Practitioner checklist

Record every cloud processor of personal data, with certificate edition, scope, Regions and expiry.
Map each provider's ISO/IEC 27018 commitments to your Article 28 contract terms.
Subscribe to and review sub-processor change notifications within the objection window.
Confirm data location settings and transfer mechanisms per service.
Test export and deletion, including backups, at least annually.
Inventory human and non-human identities with access to PII stores and remove standing access.
Ban non-expiring, broad-scope sharing tokens on PII stores.
Providers: add ISO/IEC 27018:2025 to the ISO/IEC 27001 Statement of Applicability and publish customer commitments.

ISO/IEC 27018 Cloud PII Protection Guide: Controls for Public Cloud Processors