PlaybookGLOBAL

ISO 27018 Compliance

An implementation playbook for public cloud PII processor privacy controls.

Built for cloud providers, SaaS teams, procurement reviewers, and privacy teams that need contract-ready evidence.

Author
Sorena AI
Published
Mar 4, 2026
Updated
Mar 4, 2026
Sections
8

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

Publication metadata
Sorena AI
Published Mar 4, 2026
Updated Mar 4, 2026
Overview

ISO/IEC 27018 is a code of practice for protecting personally identifiable information in public clouds acting as PII processors. In practice, strong implementation means you can show that personal data is processed only under customer instructions, that subprocessor use and storage countries are transparent, that disclosure requests are legally screened and logged, that breach notifications are prompt and evidence backed, and that deletion or return can be executed across production, backup, and business continuity environments.

Section 1

Status note: what to use today

The ISO standard listing now identifies ISO/IEC 27018:2025 as the current edition, and the ISO/IEC 27018:2019 page is marked withdrawn. The control themes in this playbook are grounded in the 2019 control model because that is the local source pack available for detailed implementation review.

Use this page to shape operating controls and evidence, then validate any final wording or certification claim against the current ISO listing and the edition you license internally.

  • Treat the current ISO listing as the lifecycle source of truth
  • Treat the 2019 control pack as detailed implementation guidance unless your licensed 2025 text requires a narrower interpretation
Section 2

Step 1: confirm you are acting as a public cloud PII processor

ISO 27018 applies when a public cloud service provider processes PII for and according to the instructions of a cloud service customer. The distinction holds only if the provider has no processing objectives of its own beyond what is necessary to deliver the customer service.

This boundary matters because the same provider can still act as a controller for separate data sets, such as billing, account ownership, fraud management, or its own HR records.

  • List each in-scope service and identify whether you act as processor, controller, or both in different workflows
  • Record the customer instructions that define purpose, timeframe, and processing outcomes
  • Document any provider-determined processing method and confirm it stays within the customer instruction boundary
Section 3

Step 2: lock down purpose limitation and marketing use

The core ISO 27018 rule is simple: PII processed under contract should not be used for any purpose independent of the customer instruction. This is the processor control that procurement teams, privacy counsel, and auditors look for first.

The standard also states that PII processed under contract should not be used for marketing or advertising without express consent, and that consent should not be a condition of receiving the service.

  • Write a processor purpose statement into the contract and the internal service standard
  • Block product analytics, machine learning reuse, or marketing workflows unless the legal basis and contract model clearly permit them
  • Maintain evidence that marketing or advertising use requires express consent and is not bundled into core service access
Section 4

Step 3: make subprocessor and country transparency operational

ISO 27018 expects subprocessor use to be disclosed before use, with the names of relevant subprocessors, the countries where they can process data, and the means by which they are required to meet or exceed the processor's obligations.

The contract should also support general authorization, timely notice of intended changes, and a customer ability to object or terminate.

  • Maintain a live subprocessor register with service, role, country, and flow-down obligation reference
  • Define a measurable customer notice window for changes and keep records of objections or approvals
  • Where public disclosure creates unacceptable risk, provide the information under NDA and make customers aware that it is available
Section 6

Step 5: make breach notification support fast and specific

ISO 27018 says the processor should promptly notify the relevant cloud service customer when unauthorized access to PII, or to processing equipment or facilities, results in loss, disclosure, or alteration of PII.

The contract should define the maximum notification delay and the information needed so the customer can assess its own legal notification duties.

  • Include event time, detection time, impact summary, data categories, likely consequences, containment actions, and customer contact path in the breach record
  • Retain evidence of whether the incident caused loss, disclosure, or alteration of PII
  • Where law requires direct regulator notice by the processor, document that obligation separately from the customer notice workflow
Section 7

Step 6: design deletion and return for the full service lifecycle

ISO 27018 requires a policy for return, transfer, or disposal of PII and says the processor should provide information necessary for the customer to ensure that PII is erased wherever stored, including backup and business continuity environments, once it is no longer needed for the customer's purpose.

Deletion is not credible if it only covers the primary environment. The contract and runbooks should specify the mechanism, timing, and verification method.

  • Cover export, transfer, secure deletion, destruction, anonymization, and archiving paths
  • State the retention period before destruction after contract end so accidental lapse does not destroy customer data unexpectedly
  • Flow the same disposal obligations to subprocessors, including backup storage providers
Section 8

Step 7: build an evidence model that can replace intrusive customer audits

ISO 27018 recognizes that individual customer audits in a multi-tenant cloud can be impractical or can increase security risk. In those cases, the processor should make independent evidence available before contract signature and during the contract term.

A strong evidence model shortens sales cycles and reduces repeated customer questionnaires.

  • Prepare an evidence index that maps each customer commitment to a control owner and evidence artifact
  • Keep prior policies and procedures for a documented retention period, with five years as the ISO 27018 recommended minimum when no stricter requirement applies
  • Use third-party assurance, transparency materials, procedure summaries, and sample records to support customer review without exposing multi-tenant risk
Recommended next step

Turn ISO 27018 Compliance into an operational assessment

Assessment Autopilot can take ISO 27018 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on ISO 27018 can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Primary sources

References and citations

eur-lex.europa.eu
Referenced sections
  • Primary legal source for processor contract duties, security of processing, and breach notification obligations that ISO 27018 often supports in practice.
Related guides

Explore more topics