ISO 27018 is a code of practice for protecting personally identifiable information (PII) in public clouds when the cloud service provider acts as a PII processor. It adds privacy-focused guidance to the ISO security control ecosystem.
This guide covers:
- Where ISO 27018 fits in the ISO 27000 family
- Transparency, customer instructions, use limitation, return, and deletion
- Provider and customer responsibilities
- Evidence that makes privacy controls auditable
Related guides:
GIF via GIPHY
Key takeaways
- ISO 27018 focuses on public-cloud PII processing. The organization’s role and service scope determine applicability.
- Customer instructions shape processing. Providers should process PII for agreed purposes and handle conflicting requests through defined procedures.
- Transparency is operational. Subprocessors, locations, incidents, and service changes need accurate records and communication workflows.
- Return and deletion must reflect architecture. Active systems, replicas, backups, exports, and legal retention constraints should be addressed.
- ISO 27018 complements security and privacy programs. It does not replace applicable privacy law, contracts, ISO 27001, or broader privacy governance.
What is ISO 27018?
ISO/IEC 27018 provides implementation guidance for protecting PII in public cloud computing environments. Its perspective is especially relevant where a public cloud provider processes PII on behalf of a cloud customer.
The standard builds on ISO 27002 controls and adds privacy considerations derived from recognized PII protection principles. In practice, it helps providers translate statements such as “we only process customer data as instructed” into owned procedures, technical restrictions, contract terms, and evidence.
ISO 27018 is not a privacy law and does not determine every legal obligation. Applicable laws, data processing agreements, sector requirements, and customer instructions may impose additional or different duties. Legal and privacy teams should validate the organization’s role in each processing activity.
Record that role decision and revisit it whenever the service’s purposes, customers, or architecture materially change.
Core PII protection principles
Processing purpose and customer instructions
Document the purposes for which the service processes PII and restrict unrelated use. Product changes that introduce a new purpose should trigger privacy, security, and contractual review. Personnel should know how to escalate an instruction that is unclear, infeasible, or potentially unlawful.
Transparency
Customers commonly need understandable information about:
- Categories of PII and processing activities
- Relevant processing locations
- Subprocessors and material changes
- Security and privacy features
- Incident notification channels
- Return, export, retention, and deletion behavior
Transparency records must stay aligned. A subprocessor register, data flow, contract, trust material, and architecture inventory should not tell different stories.
Individual rights support
The customer may be responsible for responding to individuals, while the provider supplies tools or assistance. Define intake, identity verification dependencies, search/export/delete capabilities, response handoff, and evidence. Avoid promising direct action where the provider cannot verify authority.
Disclosure and access
Restrict personnel access to approved business needs and record disclosures where required. Government or third-party requests should follow validated procedures, legal review, and permitted customer notification.
Return, retention, and deletion
Customers should understand how to retrieve PII and what happens when service ends. Deletion workflows should account for primary storage, replicas, logs, backups, and legal holds. Where immediate deletion from backups is not technically feasible, document isolation and expiry controls.
Roles and customer control
| Decision | Cloud customer commonly owns | Provider commonly owns | Shared record |
|---|---|---|---|
| Processing purpose | Selects lawful business purpose | Limits processing to service/instructions | Processing agreement |
| User access | Approves tenant users | Secures platform administrators | Access model |
| Rights request | Validates requester and response | Provides service capability/assistance | Request ticket |
| Subprocessor use | Reviews terms and notices | Performs diligence and notification | Subprocessor register |
| Service termination | Requests export/deletion | Executes return and deletion workflow | Completion record |
“Commonly” matters: contracts, law, and service design may allocate duties differently. Assign one accountable internal owner for each provider obligation even when execution crosses privacy, legal, support, and engineering teams.
Operational controls and evidence
An auditable ISO 27018 program connects policy to normal operations:
- Data inventory: systems, PII categories, purposes, regions, retention, customers, and subprocessors.
- Agreement control: approved templates, deviations, customer instructions, and amendment history.
- Access control: role design, approvals, MFA, privileged logs, and recurring review.
- Encryption: approved requirements, key ownership, configuration evidence, and exception handling.
- Incident response: privacy triage, contract timers, decision logs, notices, and exercises.
- Rights support: sampled requests showing authorization, search, action, approval, and response.
- Deletion: tested runbooks, job records, backup treatment, and completion confirmation.
- Supplier governance: diligence, agreements, reassessment, and change notifications.
| Control claim | Weak evidence | Stronger operating evidence |
|---|---|---|
| Access is limited | Access policy | Current role export plus completed review |
| PII is deleted | Retention statement | Authorized request plus deletion job record |
| Subprocessors are governed | Vendor list | Diligence, agreement, review, and notice history |
| Incidents are reported | Response plan | Tabletop record and sampled decision log |
Privacy, security, engineering, legal, procurement, and support may own different workflows. A central control owner should verify that handoffs operate and exceptions close.
Follow PII through the service lifecycle
Privacy assurance becomes more concrete when teams trace a representative customer dataset. Start at tenant provisioning and record the agreed purpose and region. Follow the data through application storage, support access, logging, analytics, backups, subprocessors, export, and termination. At each step, ask who can act, what instruction permits processing, what security control applies, and what record remains.
This exercise commonly reveals derived data that a high-level inventory missed: support attachments, diagnostic logs, search indexes, temporary exports, or analytics events. These stores may require separate access, retention, and deletion decisions. Add them to the inventory and assign an owner rather than assuming the primary database workflow covers them.
Keep customer control usable
Customer control is not meaningful if a feature exists but customers cannot understand or invoke it. Product documentation should explain available privacy settings, export formats, retention options, responsibilities, and support channels in language appropriate to the service. Changes should pass a review that compares documentation, agreements, architecture, and support readiness.
For exceptional requests, create an intake that records authority, scope, deadline, decision, action, and response. Privacy or legal may interpret the request; engineering may execute a technical action; support may communicate. The workflow should preserve these handoffs without exposing more PII than necessary.
Treat transparency as a controlled output
Assign owners to subprocessor lists, location statements, security exhibits, and privacy documentation. Set change triggers from procurement and architecture processes, require review before publication, and retain prior versions. This lets the provider show what customers were told at a given time and whether required notices occurred.
Who should use ISO 27018?
ISO 27018 may be useful for SaaS, PaaS, and IaaS providers processing customer PII in public cloud environments; customers evaluating those providers; and organizations extending ISO 27001 or ISO 27701 controls into cloud processing.
Prioritize it when enterprise customers ask detailed privacy questions, PII processing is material, subprocessors are numerous, or deletion and location commitments are complex. If your organization determines purposes and means for its own processing, broader privacy-controller requirements may also apply.
Before describing the organization as “ISO 27018 certified,” confirm the assessment route and wording with the certification body. ISO 27018 is commonly evaluated alongside an ISO 27001-based management system rather than as an isolated program.
Operationalize ISO 27018
SecureSlate helps teams map privacy controls, assign owners, centralize processing and supplier evidence, track retention and deletion workflows, manage findings, and support efficient customer reviews.
Get started for free: Create your SecureSlate account
FAQ: ISO 27018
Does ISO 27018 apply to all personal data processing?
Its specific focus is protection of PII in public clouds where the provider acts as a PII processor. Other roles and environments may require additional frameworks and legal analysis.
Is ISO 27018 the same as ISO 27701?
No. ISO 27701 extends an ISMS into a privacy information management system. ISO 27018 gives public-cloud processor-focused control guidance.
Does ISO 27018 require deletion?
It addresses return, transfer, retention, and deletion expectations. Exact timing and methods depend on customer instructions, contracts, architecture, and applicable law.
Why do SaaS buyers ask for it?
It offers structured assurance around cloud PII use, access, subprocessors, incidents, customer control, and service termination.
Disclaimer (legal note)
SecureSlate is not a law firm, and this article does not constitute legal advice or create an attorney-client relationship. Consult qualified legal counsel, privacy professionals, and your certification body regarding roles, obligations, and claims.
Need compliance without the complexity?
SecureSlate automates ISO 27001, SOC 2, GDPR, HIPAA, and more. Built for growing teams. See it in action.
Find compliance gaps in 30 seconds
