Practical toolGlobalISO/IEC 27018

ISO/IEC 27018 Subprocessor Evidence Workflow

Control subprocessor onboarding and changes with prior disclosure, timely customer notice, objection handling, responsibility flow-down, and evidence.

The detailed steps use withdrawn ISO/IEC 27018:2019. Check them against ISO/IEC 27018:2025, the customer contract, and applicable processor and transfer law; those sources can require different consent, notice, objection, or flow-down terms.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

A should open this workflow before a proposed downstream provider receives production PII. Identify the provider and countries, assess controls and terms, complete any required customer authorization and notice, resolve objections, approve or reject the change, and retain operating and exit evidence.

Section 1

Identify the subprocessor, processing, and countries

Open the workflow before the proposed provider receives production PII. Record its legal entity, service, role, processing purpose and operations, PII categories, access type, affected customer services, possible storage and access countries, onward providers, and planned start date.

Confirm that the customer contract permits the appointment and states whether consent is specific or general. Identify the promised notice period, objection or termination route, transfer terms, security schedule, and the ISO/IEC 27018 edition used as a review criterion.

Treat a downstream provider as a for this workflow when it processes customer PII on the public-cloud provider's behalf while the provider performs the customer's instructions. Include backup, support, monitoring, content-delivery, and disaster-recovery providers when they meet that test. A vendor label or lack of routine human access does not decide the role; a provider with no PII access or one used only for a separate provider-controlled purpose needs its own documented classification.

  • Procurement owner: supplier identity, commercial scope, contract, renewal, and exit.
  • Privacy and legal owners: role, instructions, customer authority, notice, objection, countries, transfer terms, disclosures, and legal exceptions.
  • Security and service owners: architecture, access, controls, integration, monitoring, incident route, deletion, and technical exit.
  • Gate: no production PII until due diligence, flow-down terms, customer process, risk decision, and implementation approval are complete.
Section 2

Assess controls and contract responsibility flow-down

Compare the supplier's controls and contract with the obligations the public-cloud provider owes its customers. Under the 2019 guidance, the contract should specify minimum technical and organizational measures that meet the provider's information-security and PII-protection obligations and should prevent unilateral reduction by the subprocessor.

Resolve gaps before approval or record a time-limited exception with the affected obligation, compensating measure, owner, approver, expiry, and customer impact. An assurance report supports due diligence only for the entities, services, locations, controls, and period it actually covers.

  • Control review: access, confidentiality, logging, encryption, tenant separation, secure development, vulnerability handling, resilience, restoration, and disposal.
  • Privacy review: purpose limits, customer instructions, rights support, government requests, PII breaches, countries, onward processing, retention, and deletion.
  • Contract review: required flow-down, audit or assurance access, notice and cooperation deadlines, control-change limits, remediation, return or deletion, and termination.
  • Decision: approve, approve with a dated condition, seek customer-specific approval, choose another provider, or reject.
Section 3

Notify customers before use and manage objections

The 2019 guidance says relevant customers should be told about sub-contracted PII processing before use. It calls for the fact of subcontracting, relevant names, possible processing countries, and how the is bound to meet or exceed the provider's obligations.

Send notice through the contractually valid channel early enough for the promised objection or termination process. Preserve the notice version, recipient population, send and effective dates, delivery result, objections, responses, exceptions, withdrawals, and termination outcomes.

If public disclosure would create unacceptable security risk, the 2019 guidance permits controlled disclosure under a non-disclosure agreement or on request, while making customers aware that the information is available. Do not use that exception merely to avoid notice.

  • No objection by the deadline: confirm every other approval gate, then schedule activation.
  • Objection received: pause the affected activation where the contract requires, assess the stated ground, and record the agreed remedy, alternative service, exemption, or termination path.
  • Customer-specific restriction: prevent that customer's PII from reaching the unless and until the restriction is resolved.
  • Notice failure: do not backdate evidence; record the failure, affected customers, containment, correction, and legal review.
Section 4

Approve onboarding and update operational records

After the notice and objection window, an authorized approver checks the due-diligence report, signed terms, control mapping, country and transfer review, customer outcomes, unresolved conditions, and production safeguards. Record the approval and actual activation date.

Update the register, data-flow map, processing inventory, customer-facing list, country list, access groups, monitoring, incident contacts, retention schedule, backup map, and exit plan. Evidence must identify the supplier and service version actually approved.

  • Do not activate on the strength of a vendor policy page alone.
  • Do not assume a signed contract proves the integration uses the approved region, account, access route, or retention setting.
  • Do not close objections without recording the response and outcome for the affected customer.
  • Do not present ISO/IEC 27018 guidance as the source of a statutory consent or transfer requirement.
Section 5

Monitor, change, and offboard the subprocessor

Monitor material control changes, assurance coverage, incidents, complaints, country changes, acquisitions, onward providers, and contract renewals. Reopen due diligence and customer notice before a change takes effect when the contract or applicable rule requires it.

On exit, stop new transfers, revoke accounts and keys, remove integrations, reconcile stored PII and backups, obtain return or deletion evidence, update registers and notices, and record any legally required retention with access restrictions and a disposal date.

  • Sample actual access, country, incident, restoration, and deletion records rather than relying only on annual questionnaires.
  • Reassess an assurance report when its period ends or its scope, exceptions, or subservice organizations no longer match the approved service.
  • Close the supplier record only after access is removed, PII disposition is evidenced, customer-facing information is updated, and open findings have owners.
Primary sources

References and citations

eur-lex.europa.eu
Referenced sections
  • Binding EU data protection regulation used for ISO/IEC 27018 comparison.
"protection of natural persons with regard to the processing of personal data"
iso.org
Referenced sections
  • ISO's withdrawn 2019 listing identifies the prior edition; its detailed clauses remain relevant only when that edition is the stated criterion.
"Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors"
iso.org
Referenced sections
  • Primary ISO listing for the 2025 edition of ISO/IEC 27018.
"Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors"
Related guides

Explore more topics

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 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 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 DPA Clause Review Workflow
Review cloud data-processing terms for instructions, purpose limits, controls, subprocessors, disclosures, incidents, rights support, and deletion.
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 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 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 Privacy Control Checklist
A practical ISO/IEC 27018:2025 checklist for public-cloud PII processors, with verifiable conditions, owners, evidence, exceptions, and edition controls.
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 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.
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.
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.