We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Practical toolGlobalISO/IEC 27018

ISO/IEC 27018 Privacy Control Checklist

Use this checklist to verify a control set from scope through operation. Give each item an owner, evidence, an exception path, and a review trigger.

ISO/IEC 27018:2025 is the current edition. ISO published it in August 2025, aligned it with ISO/IEC 27002:2022, and added Annex B. Detailed checklist items drawn from the withdrawn 2019 edition are identified as historical guidance and must be reconciled to the 2025 text.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
5 sections3 primary sources
Overview

Complete the checklist for a defined provider entity and service, not for a cloud brand in general. Confirm the role first, then mark each item implemented, not applicable with a reason, or open with an owner and due date. ISO/IEC 27018 is voluntary guidance unless a contract or other binding requirement makes specified controls mandatory. A policy alone does not show that a control operated.

Section 1

Confirm scope, roles, instructions, and applicable requirements

The service is in scope only where the provider supplies processing through the public-cloud model and processes PII on behalf of and according to a customer's instructions. Assess provider-controlled purposes separately. The same organization can be a processor for hosted customer content and a controller for another activity.

Record the ISO/IEC 27018 edition used. ISO published edition 3 on 26 August 2025 and withdrew the 2019 edition the same day. The current edition is aligned with ISO/IEC 27002:2022; the withdrawn edition was based on ISO/IEC 27002:2013. Reconcile older mappings rather than carrying clause numbers forward unchanged.

  • Scope owner - Record the provider entity, customer, service and deployment model, processing activities, responsibility split, known PII, processing countries, and subprocessors. Evidence: approved scope and data-flow record.
  • Privacy or legal owner - Separate processing on customer instructions from processing for provider purposes. Evidence: role assessment tied to each purpose and data flow.
  • Contract owner - Record the customer's documented instructions, purpose and duration, service limits, required assistance, and any applicable legal or contractual duties. Evidence: executed contract and instruction-change record.
  • Information security management system (ISMS) owner - Name the ISO/IEC 27018, ISO/IEC 27002, and ISO/IEC 27001 editions used in the mapping. Evidence: approved crosswalk and Statement of Applicability where relevant.
  • Control owner - For every not-applicable item, record the service fact or risk decision that supports omission, the approver, and the next review trigger.
Section 2

Check purpose limits, transparency, and customer enablement

The 2019 edition said contract PII should not be processed for a purpose independent of the customer's instructions and should not be used for marketing or advertising without express consent that is not a condition of service. It also called for contractual specification of the information or technical measures the customer needs to support PII principal rights. Verify the corresponding 2025 controls before claiming current-edition conformance.

  • Product owner - Confirm every use of customer PII maps to a documented customer purpose or a separately assessed provider purpose. Evidence: purpose-to-data-flow map and approved instruction.
  • Marketing owner - Confirm customer PII is not used for marketing or advertising without the required express consent, and that consent is not required to receive the underlying service. Evidence: feature configuration, consent record, and test result.
  • Privacy operations owner - Provide the information and technical functions agreed for access, correction, erasure, export, or restriction requests. Evidence: contract clause, runbook, sample request, and response record.
  • Service owner - Disclose material PII-protection capabilities and limitations before contracting and when they change. Evidence: current service description, security schedule, and change notice.
  • Reviewer - Sample actual instructions, purpose changes, marketing settings, and rights-support tickets; do not close the item from policy wording alone.
Section 3

Check security, subcontracting, disclosure, and incident controls

Allocate each security control to the party that can operate it in the actual SaaS, PaaS, or IaaS model. The 2019 edition covered customer access administration, cryptography information, event logs, subprocessor notice and flow-down, processing countries, legally binding disclosures, and customer incident notification. Applicable law and the 2025 edition may require additional or different controls.

  • Security owner - Test access provisioning, deprovisioning, unique IDs, authorized-user records, log protection and review, encryption in transit, restoration logging, and storage reassignment. Evidence: configurations and sampled records.
  • Customer success or product owner - Give the customer accurate information about encryption, backup and restoration, log availability, and the controls the customer must operate. Evidence: service documentation and responsibility matrix.
  • Supplier owner - Disclose relevant subprocessors before use, applicable processing countries, change notice and objection or termination mechanism, and contractual control flow-down. Evidence: register, notice, response, and subprocessor clause.
  • Legal owner - Validate disclosure requests, reject requests that are not legally binding, consult or notify the customer where legally permitted, and record the PII, recipient, time, authority, and source. Evidence: disclosure register and legal decision.
  • Incident owner - Define the incident-notification route and maximum contractual delay, provide the information the customer needs, and record the event, affected PII, consequences, response, recovery, and notifications. Evidence: tested plan and incident record.
  • Exception owner - When public subprocessor detail would create an unacceptable security risk, document the basis and provide the information through the permitted restricted channel described to the customer.
Section 4

Check return, deletion, retention, and operating evidence

Define the outcome for live data, temporary files, logs, replicas, backups, business-continuity copies, support systems, and subprocessor copies. The 2019 edition allowed return, transfer, secure deletion or destruction, anonymization, or archival depending on the agreed purpose and contract; it also called for a documented period for erasing unused temporary files.

A deletion statement is incomplete if it omits backups, retention exceptions, the disposal mechanism, or the period after service termination. Where law requires continued storage, document the legal basis, access restriction, owner, location, and final disposition trigger.

  • Data lifecycle owner - Map each storage location and copy type to its retention trigger, disposal method, responsible party, and evidence source.
  • Engineering owner - Run the documented age-based deletion process for unused temporary files. Evidence: configuration, job result, exception log, and sample.
  • Service owner - Make the return, transfer, disposal, and post-termination retention policy available to the customer. Evidence: contract schedule, policy version, and customer notice.
  • Supplier owner - Confirm that end-of-service instructions and deletion evidence cover subprocessors and their backup copies. Evidence: downstream instruction and completion record.
  • Reviewer - Sample deletion, return, restoration, disclosure, incident, and rights-support records from the assessment period and trace exceptions to closure.
Recommended next step

Assign each ISO/IEC 27018 check

Give every applicable control an owner, evidence location, exception path, and review trigger.

Assessment workflow
Open Assessment Autopilot for ISO/IEC 27018

Convert the checklist into tasks, evidence requests, exception decisions, and review checkpoints.

Explore next step
Talk to Sorena
Talk through implementation

Review your current scope, evidence gaps, and next implementation steps.

Explore next step
Section 5

Close gaps and verify the assurance claim

Close the checklist only when every item has evidence or an approved not-applicable rationale. A gap stays open when the team has a policy but cannot show operation, when the evidence covers a different service or period, or when a 2019 mapping has not been reconciled to the 2025 edition.

Match the external claim to the assurance obtained. State the provider entity, service, locations if relevant, ISO/IEC 27018 edition, assessment criteria, period or date, assessor, exceptions, and relationship to any ISO/IEC 27001 certificate. Do not turn a control mapping into a legal-compliance or certification claim.

  • Control owner - Correct failed items or document the approved risk treatment, compensating control, due date, and evidence needed for closure.
  • Assurance owner - Verify the report or certificate covers the named entity and service and expressly identifies the relevant criteria.
  • Claim owner - Compare website, sales, procurement, and contract language with the final evidence before publication or renewal.
  • Review owner - Reopen affected items when purposes, instructions, architecture, subprocessors, countries, incidents, law, contract terms, or standard editions change.
Primary sources

References and citations

ISO/IEC 27018:2019 standard page
iso.org6 citations
Referenced sections
  • Withdrawn edition used for the detailed historical control checks, each of which requires reconciliation to ISO/IEC 27018:2025.
  • The withdrawn 2019 scope and structure support the historical checklist details but must be reconciled when the assessment criterion is ISO/IEC 27018:2025.
  • Annex A.2 and A.3 of the 2019 edition support the historical checklist items for rights assistance, independent-purpose limits, and marketing consent.
Show 3 more
  • The 2019 sector guidance and Annex A support the listed historical checks for access, cryptography information, logs, subprocessors, countries, disclosures, incidents, and security measures.
  • Annex A.5 and A.10.3 of the 2019 edition support the detailed historical checks for temporary-file erasure and PII return, transfer, disposal, backups, and post-termination retention.
  • The 2019 edition said independent evidence can address customer audit interests when individual audits are impractical, provided sufficient transparency is available.
"Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors"
More quoted passages
"PII to be processed under a contract should not be processed for any purpose independent of the instructions of the cloud service customer."
"The use of sub-contractors by the public cloud PII processor to process PII should be disclosed to the relevant cloud service customers before their use."
"Temporary files and documents should be erased or destroyed within a specified, documented period."
"provided sufficient transparency is provided"
ISO/IEC 27018:2025 standard page
iso.org4 citations
Referenced sections
  • Current edition, scope, ISO/IEC 27002:2022 alignment, and Annex B information used to frame the checklist.
  • ISO identifies edition 3, its public-cloud PII processor scope, alignment with ISO/IEC 27002:2022, and the new Annex B.
  • The current edition remains the assessment reference; verify how its 2025 controls address the lifecycle items described from the prior edition.
Show 1 more
  • ISO's lifecycle listing shows that 2025 replaced the withdrawn 2019 edition, so the claim and mapping must identify the edition assessed.
"Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors"
More quoted passages
"including collection, storage, processing, transmission, and deletion"
"Edition 3"
ISO/IEC 27002:2022 standard page
iso.org
Referenced sections
  • Current information-security control guidance to which ISO says ISO/IEC 27018:2025 is aligned.
"Information security controls"

Related guides

ISO/IEC 27018 Cloud Privacy FAQ

ISO/IEC 27018 FAQ on public-cloud PII processor scope, customer instructions, subprocessors, disclosures, breaches, deletion, audit evidence, and GDPR.

ISO/IEC 27018 DPA Clause Review Workflow

Review cloud data-processing terms for instructions, purpose limits, controls, subprocessors, disclosures, incidents, rights support, and deletion.

ISO/IEC 27018 Government Access Evidence Guide

Build a controlled government-access case record showing request authentication, legal review, notice, approval, minimized disclosure, transfer, and closure.

ISO/IEC 27018 Government Access Evidence Workflow

Triage a government request for customer PII, validate authority, decide notice and challenge options, minimize disclosure, and preserve the decision record.

ISO/IEC 27018 Public Cloud PII Processor Scope Guide

Decide whether a service fits ISO/IEC 27018's public-cloud PII processor scope, separate processor and controller activities, and document the boundary.

ISO/IEC 27018 Subprocessor Evidence Guide

Build subprocessor evidence that proves who processed customer PII, where, under which terms and controls, after which notice and approval, and with what exit result.

Show all related guides (20)

ISO/IEC 27018 Subprocessor Evidence Workflow

Assess and approve a cloud subprocessor, disclose its use and countries before processing, handle customer objections, and retain operating and exit evidence.

ISO/IEC 27018 Vendor Contract Requirements Guide

Contract guide for ISO/IEC 27018 public-cloud PII processing: scope, instructions, security, subprocessors, disclosures, incidents, rights support, audits, and exit.

ISO/IEC 27018 vs GDPR Comparison

Compare ISO/IEC 27018 cloud-processor guidance with GDPR legal duties, including scope, Article 28 contracts, breaches, transfers, evidence, and assurance limits.

ISO/IEC 27018 vs ISO/IEC 27701 Comparison

Compare ISO/IEC 27018:2025 cloud-processor guidance with the independent ISO/IEC 27701:2025 privacy management system, including scope, evidence, and assurance.

ISO/IEC 27018 vs SOC 2 Privacy Comparison

Compare ISO/IEC 27018 cloud-processor guidance with a SOC 2 examination that includes Privacy, including scope, Type 1 vs Type 2, evidence, and limits.

Using ISO/IEC 27018 for Public-Cloud PII Processing

Decide whether ISO/IEC 27018:2025 applies to a public-cloud PII processor, how it fits an ISMS, what evidence to keep, and which claims the evidence supports.

ISO/IEC 27018 Audit Evidence FAQ

How to assess ISO/IEC 27018 audit evidence by edition, service scope, criteria, audit period, exceptions, and independent assurance.

ISO/IEC 27018 Breach Support FAQ

ISO/IEC 27018 breach support: when a cloud PII processor should notify a customer, what the contract should define, and what incident records to keep.

ISO/IEC 27018 Customer Instructions FAQ

What counts as a customer instruction under ISO/IEC 27018, how a cloud PII processor should validate it, and what evidence shows it was followed.

ISO/IEC 27018 GDPR Overlap FAQ

How ISO/IEC 27018 can support GDPR processor controls without replacing Article 28 terms, controller accountability, transfers, or breach duties.

ISO/IEC 27018 Government Access FAQ

How ISO/IEC 27018 addresses legally binding law-enforcement requests: validation, customer consultation or notice, limited disclosure, and records.

ISO/IEC 27018 PII Return and Deletion FAQ

How to plan and prove PII return, transfer, deletion, anonymization, or archival across live systems, backups, temporary files, and subprocessors.

ISO/IEC 27018 Processor Duties FAQ

What ISO/IEC 27018 expects from a public-cloud PII processor: customer instructions, purpose limits, security, transparency, incident support, and disposal.

ISO/IEC 27018 Subprocessor Notice FAQ

What an ISO/IEC 27018 subprocessor notice should disclose, when customers should receive it, and what evidence should support consent and objections.