A PII processor in a public cloud is a provider that processes personally identifiable information on behalf of its customers and under their instructions — the position most SaaS, hosting and platform companies are in for most of the personal data they hold — and ISO/IEC 27018:2025 is the standard written for exactly that role. Its introduction is precise about the shape of the obligation: the processor “is protecting the information assets entrusted to it by its customers”, the controls of ISO/IEC 27002 are “both suitable for this purpose and necessary”, and the standard extends them in two ways — implementation guidance on existing controls, and an Annex A of additional controls “organized in line with the privacy principles of ISO/IEC 29100”. This guide sets out the nine obligations a cloud PII processor takes on under that structure, the ISO/IEC 29100 principle each one implements, how they line up with the processor duties in GDPR Article 28 and comparable laws, what the third edition changed, and the six artefacts a customer’s privacy review will ask to see.

The role, precisely
ISO/IEC 27018 applies where three conditions meet: a public cloud service, personally identifiable information, and the provider acting as PII processor — processing on behalf of and under the instructions of the customer, who is the PII controller. The standard notes that most of its controls “also apply to a PII controller”, but that the controller is “subject to additional obligations not specified here”. A provider that decides the purposes of processing for some data — its own product analytics on customer content, for example — is a controller for that data and must look elsewhere for it. Our guide to ISO 27018 covers the standard as a whole.
The nine PII processor obligations
| Obligation | ISO/IEC 29100 principle | What the processor does | What the customer can check |
|---|---|---|---|
| 1. Process only on documented instructions | Consent and choice; purpose legitimacy and specification | Processes PII only for the purposes the customer instructs; does not process for its own purposes | The contract’s instruction clause and the processor’s purpose-limitation procedure |
| 2. No marketing or advertising use without consent | Purpose legitimacy and specification | Does not use customer PII for marketing or advertising unless the PII principal has expressly consented; never makes such use a condition of service | A written commitment and the engineering standard that enforces it |
| 3. Disclose sub-contracted processing | Openness, transparency and notice | Names sub-processors and the processing they perform before use; gives notice of changes so the customer can object | The sub-processor register and the change-notice mechanism |
| 4. Handle legally binding disclosure requests | Use, retention and disclosure limitation | Rejects requests without a legal basis; notifies the customer of binding requests unless prohibited; records every disclosure | The disclosure-request log and the notification procedure |
| 5. Be transparent about location | Openness; privacy compliance | Discloses the countries where PII may be stored and processed, including by sub-processors, and the intended destination of transfers | The location statement per service and region |
| 6. Notify breaches and keep records | Accountability | Notifies the customer of a data breach involving PII promptly, with defined content, and records breaches and responses | The breach notification procedure with its timing, and the breach register |
| 7. Support PII principals’ rights | Individual participation and access | Provides the customer with the means to meet access, correction and erasure requests within the service | The data subject request support procedure and the product features behind it |
| 8. Return, transfer and dispose of PII | Use, retention and disclosure limitation; accountability | Returns, transfers or securely deletes PII at the end of the contract within a stated period, including from backups and temporary files, and confirms it | The disposal procedure, retention statement and certificate of deletion |
| 9. Confidentiality and access discipline | Information security | Binds staff with confidentiality agreements; restricts hardcopy; controls and logs data restoration; encrypts PII on portable media and over public networks; uses unique user IDs and keeps records of authorised users | The confidentiality standard, access records and encryption evidence |
The obligations are drawn from ISO 27018’s implementation guidance and Annex A; the numbering here is ours, and the principle column follows the ISO/IEC 29100 organisation the standard’s introduction describes. Read across the table and the pattern is contractual: every obligation produces a document or a record the customer can inspect, which is why the standard is more useful to a sales team than a security team. Our guide to ISO 27017 vs ISO 27018 sets these against the cloud security controls.
How the obligations map to processor law
| Legal duty (GDPR Article 28 and comparable regimes) | ISO 27018 obligation |
|---|---|
| Process only on documented instructions from the controller | 1 |
| Ensure persons authorised to process are bound by confidentiality | 9 |
| Engage sub-processors only with authorisation, with notice of changes and flow-down of terms | 3 |
| Assist the controller in responding to data subject requests | 7 |
| Assist with breach notification and security obligations | 6 and 9 |
| Delete or return all personal data at the end of the service | 8 |
| Make available the information necessary to demonstrate compliance and allow audits | 3, 5 and the ISO 27001 certificate scope naming ISO 27018 |
The standard does not discharge the law — the data processing agreement is still a contract and a transfer mechanism is still a legal instrument — but a PII processor holding the nine obligations as audited controls can answer an Article 28 review with evidence rather than assurance. Obligation 4, the handling of government and law-enforcement requests, has no direct Article 28 counterpart and is the one European customers most often ask about after transfer rulings; obligation 5 is what makes their transfer assessment possible.
What the 2025 edition changed
ISO/IEC 27018:2025, the third edition published August 2025, replaced the 2019 edition. Its foreword names two changes: the text was aligned with ISO/IEC 27002:2022, and Annex B was added. Annex A — the additional controls by ISO/IEC 29100 principle — remains. For a processor whose documentation maps to the 2019 edition, the work is a remapping of the implementation-guidance references to the 27002:2022 control numbers; the obligations themselves did not move. That contrasts with ISO 27017, whose 2026 edition removed its control identifiers altogether.
The six artefacts a privacy review asks for
- The sub-processor register, current, with the processing each performs and the notice mechanism for changes. The stale list is the failure customers find first.
- The location statement, per service and per region, including sub-processor locations.
- The disclosure-request log and procedure, even if the log is empty — an empty log with a procedure is evidence; no log is not.
- The breach notification procedure, with the hours and the content of the notice, and the register behind it.
- The return and deletion procedure, with the period, the backup treatment and the confirmation the customer receives.
- The ISO 27001 certificate with ISO 27018 in the scope statement, which is the only form in which “ISO 27018 certified” exists.
Where PII processor programmes fall short
- Analytics creep. A product team adds usage analytics on customer content; obligation 2 is breached by a feature nobody flagged. Write the restriction into the engineering standard.
- Restoration without a log. Backups are restored to investigate a problem and nobody records who saw what; obligation 9 expects data restoration to be controlled and logged.
- Deletion that stops at the primary store. Backups and temporary files are the copies the standard names explicitly.
- Location by assumption. A region promised to the customer, and a sub-processor in another one.
Frequently asked questions
What is a PII processor under ISO 27018?
A public cloud service provider that processes personally identifiable information on behalf of, and under the instructions of, its customer — the PII controller. ISO/IEC 27018:2025 gives implementation guidance on the ISO/IEC 27002 controls for that role and adds Annex A controls organised by the ISO/IEC 29100 privacy principles.
What are the main obligations?
Processing only on instruction, no marketing use without consent, sub-processor disclosure, handling of legally binding disclosure requests, transparency about location, breach notification and records, support for data subject rights, return and deletion at contract end, and confidentiality and access discipline.
Can a processor be certified to ISO 27018?
Not on its own. The controls are audited as an extension of an ISO 27001 certificate and named in its scope statement.
Does ISO 27018 replace a data processing agreement?
No. It supplies audited controls that map to processor duties under GDPR Article 28 and comparable laws; the agreement and any transfer mechanism remain legal instruments.
What changed in the 2025 edition?
Alignment with ISO/IEC 27002:2022 and a new Annex B; Annex A and the obligations themselves carried over from the 2019 edition.
Where this leaves you
Run the PII processor role as nine audited obligations with a document behind each: instruction-only processing, no marketing use, a live sub-processor register, a disclosure-request log, a location statement, a timed breach procedure, data subject request support, evidenced return and deletion, and confidentiality and access discipline — all inside an ISO 27001 scope that names ISO 27018. The customer’s privacy review is a request for those artefacts; the programme is having them ready.
References
- ISO/IEC 27018:2025 — Guidelines for protection of PII in public clouds acting as PII processors — Third edition, August 2025; introduction on the processor role and the Annex A structure; foreword on the changes from 2019.
- Regulation (EU) 2016/679 (GDPR), Article 28 — Processor obligations the ISO 27018 controls map to.
More on ISO 27017 and ISO 27018
- PII processor obligations — you are here
- ISO 27018: the cloud privacy rules
- ISO 27017 vs ISO 27018
- Cloud service agreement security clauses
- ISO 27701 controls
- Shared responsibility matrix
The PII Processor Policy for Public Cloud, the Purpose Limitation and Processing Instruction Procedure, the Sub-processor Register, the PII Disclosure Notification Procedure, the PII Breach Notification Procedure and the PII Return, Transfer and Disposal Procedure are in the ISO 27017 & ISO 27018 Cloud Toolkit, or start with the free templates.