FAQGlobalISO/IEC 27018

ISO/IEC 27018 FAQ PII Return and Deletion

Plan return, transfer, deletion, , or archival for customer PII across live systems, logs, temporary files, backups, and subcontractors, and distinguish ISO guidance from legal retention exceptions.

The current edition is ISO/IEC 27018:2025; the detailed control explanations here use the prior 2019 edition and should be checked against the edition named in a contract or assurance report. ISO/IEC 27018 is voluntary guidance, while applicable law and contracts can impose separate or stricter duties.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Overview

Under ISO/IEC 27018:2019, the processor should maintain a customer-visible policy for . The processor should provide enough information for the customer to determine that PII, including subprocessor, backup, and continuity copies, is erased when it is no longer needed for the customer's purposes. Contract terms and applicable law determine whether return, transfer, deletion, , archival, or a documented retention exception is the required outcome.

Search this module

Find a question or answer quickly

4 of 4 questions
Question 1

What should the return and deletion outcome cover?

Start with the trigger and authorized outcome: a customer instruction, purpose expiry, retention-schedule event, contract termination, or valid legal requirement. Then define the export format and verification, timing, contract-end recovery buffer, erasure method, live systems, temporary files, logs, backups and continuity copies, subprocessor copies, archives, legal holds, and completion notice.

ISO/IEC 27018 recognizes return, transfer to another processor or controller, secure deletion or destruction, , and archival as possible dispositions. Return or transfer requires a usable export and confirmed recipient; deletion or destruction requires a defined mechanism; anonymization requires evidence that the result is no longer identifiable by reasonably likely means; archival requires a valid purpose, restricted access, and a retention end. None should be used to avoid a required return or deletion.

  • State the retention period after contract termination that protects against accidental lapse without turning the buffer into indefinite retention.
  • Specify the disposition mechanism in the contract, such as de-linking, overwriting, demagnetization, physical destruction, or another applicable commercial standard.
  • Apply a documented age limit and periodic cleanup to unused temporary files.
Question 2

Which evidence should prove disposition?

Keep the authorized instruction, purpose and retention trigger, inventory and system scope, export manifest and receipt, deletion jobs and logs, temporary-file cleanup result, backup expiry schedule, subprocessor confirmations, legal-hold record, verification sample, exceptions, and completion notice.

For backups that cannot be selectively erased without harming integrity, document the technical constraint, access restriction, fixed expiry, restoration procedure, and rule that returns restored data to the deletion queue before normal use. ISO/IEC 27018 does not set one universal deletion period; the policy and contract should state the applicable period.

  • Reconcile the disposition inventory to actual storage, backup, logging, continuity, and subprocessor architecture rather than relying on a policy statement alone.
  • Record each completed, pending, failed, or excepted copy with its system owner, expected completion date, and verification result.
  • Retain customer authorization, export receipt, deletion evidence, subprocessor confirmations, and the final completion or exception notice.
Recommended next step

Test return, deletion, backup expiry, and exceptions

Assign the customer instruction, export, active-store deletion, temporary-file cleanup, backup expiry, subprocessor confirmation, legal exception, and final verification.

Question 3

Who approves retention exceptions?

Cloud operations performs disposition; privacy and records owners validate the inventory and retention schedule; legal confirms a legal hold or statutory retention basis; supplier management obtains subprocessor results; the service owner confirms the customer outcome and unresolved copies.

A retention exception should identify the specific data, authority, owner, access restriction, end condition, and review date. Keep excepted data isolated from ordinary processing and delete it when the exception ends.

  • Name owners for the customer instruction, export, active-store deletion, backup expiry, subprocessor completion, legal holds, and customer confirmation.
  • Require legal or records approval for a retention exception and technical verification for the affected copy; neither substitutes for the other.
  • Keep the authority, scope, end condition, review, and final deletion evidence with the disposition record.
Question 4

When should disposal controls be retested?

Retest for platform, backup, storage, logging, subprocessor, contract, retention, legal-hold, or termination-workflow changes and after a failed or partial deletion.

Test the complete path: customer authorization, export if requested, deletion from active stores and temporary files, backup expiry, subprocessor completion, exception handling, verification, and customer confirmation.

  • Set a recurring end-to-end test and retest after storage, backup, logging, subprocessor, contract, retention, or legal-hold changes.
  • Use results to update the system inventory, deletion jobs, restoration controls, supplier terms, customer instructions, and evidence checklist.
  • Assign every missing, failed, or delayed disposition step to corrective action, a documented exception, or management review.
Primary sources

References and citations

eur-lex.europa.eu2 citations
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"
More quoted passages
"at the choice of the controller, deletes or returns all the personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies unless Union or Member State law requires storage of the 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"
Show all related guides (20)

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 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 Privacy Control Checklist

A public-cloud PII processor checklist using ISO/IEC 27018:2019 control examples, with owners, evidence, exceptions, and checks against the 2025 edition.

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 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.