PII return, transfer and disposal

To meet the ISO/IEC 27018 Annex A.10.3 PII return, transfer and disposal requirement, you must maintain a written policy that explains how customers can get their PII back, move it to another provider, and/or have it securely disposed of, and you must make that policy available to the customer. Then you operationalize it through contract language, offboarding runbooks, secure deletion methods, and proof-ready records.

Key takeaways:

• Publish a customer-available policy that covers PII return, transfer, and secure disposal events, including end-of-service and migration.
• Turn the policy into an executable offboarding process with clear roles, verified deletion, and controlled transfer methods.
• Retain evidence that proves what happened to customer PII, when, by whom, and under which approval.

“PII return, transfer and disposal” is a lifecycle requirement that gets tested when relationships change: contract termination, non-renewal, partial service wind-down, customer migration, subprocessor swaps, or major platform changes. If you are a public cloud provider acting as a PII processor, auditors and customers expect more than a general retention policy. They expect a customer-facing statement of what you will do with customer PII and an operational process that reliably produces the outcomes your policy promises.

This requirement is straightforward on paper but easy to fail in practice because the work spans functions: legal drafts commitments, product teams control export tooling, infrastructure teams control deletion, security sets verification expectations, and support teams execute customer requests. The fastest path to compliance is to write one policy that is customer-readable, map it to your technical reality (where PII actually lives), and build an offboarding runbook that produces repeatable evidence.

This page translates the requirement into a practical implementation checklist you can assign, track, and audit.

Regulatory text

Requirement (verbatim): “The public cloud PII processor shall have a policy regarding the return, transfer and/or secure disposal of PII and shall make this policy available to the cloud service customer.” ¹

Operator meaning:
You need (1) a written policy that addresses three outcomes for customer PII (return, transfer, secure disposal) and (2) a delivery mechanism so the customer can access it (contract packet, trust center, DPA exhibit, customer portal, or similar). The policy must be credible: it should reflect what you can actually execute across primary systems, backups, logs, support tooling, and subprocessors.

Plain-English interpretation (what the requirement expects)

If a customer asks “How do I get my PII out, move it, or make sure you delete it?”, you must be able to hand them a clear, current policy and then follow it.

Your policy should answer:

• Return: What PII will you provide back to the customer, in what format, through which mechanism, and under what authentication/authorization checks?
• Transfer: How you support migration to another provider (data portability, secure transfer methods, custody controls, and customer responsibilities).
• Secure disposal: How you securely delete PII across systems (including derived copies and operational replicas), how you handle backups, what exceptions exist, and how you confirm completion.

Who it applies to (entity and operational context)

Applies to: Public cloud service providers acting as PII processors for customer workloads. ¹

Operational contexts where this gets tested:

• Contract termination or non-renewal
• Customer offboarding from a multi-tenant service
• Migration between regions, environments, or product editions
• Customer request to export data for compliance or portability
• Incident response and service discontinuation scenarios (customers often ask for data extracts or deletion attestations)
• Subprocessor changes where data must move or be re-homed

What you actually need to do (step-by-step)

Step 1: Inventory where customer PII exists (so the policy is real)

Build a “PII location map” that covers:

• Primary production stores (databases, object storage, search indexes)
• Analytics/telemetry (event streams, warehouses, APM traces where identifiers appear)
• Logs (application logs, security logs, audit logs)
• Caches and queues
• Backups and snapshots
• Support tooling (ticket attachments, call recordings, screen shares)
• Subprocessors and managed services

Deliverable: a scoped list of systems that must be included in return/transfer/disposal actions.

Step 2: Write the customer-facing policy (short, specific, testable)

Your policy should be readable by a customer’s security/compliance team and should include:

A. Triggers

• End of contract / account closure
• Customer request for export/transfer
• Customer request for deletion/disposal (if supported contractually)

B. Return and export

• What data categories are included (customer content, account data, audit records you provide)
• Supported export formats and delivery channels (customer portal download, secure file exchange, API export)
• Identity verification and authorization steps (who can request, approvals, admin roles)
• Any constraints (rate limits, time windows, encryption requirements)

C. Transfer

• Supported migration methods (customer-initiated exports, provider-assisted transfer where offered)
• Chain-of-custody controls (encryption in transit, key management responsibilities, checksum/verification)
• Subprocessor involvement (if data passes through third parties during transfer)

D. Secure disposal

• What “secure disposal” means in your environment (deletion methods appropriate to the medium and service model)
• Scope: production, replicas, and other copies under your control
• Backup handling approach (e.g., backups expire via lifecycle controls; describe how deleted data is addressed in backup media in a truthful, non-absolute way)
• Exceptions (legal holds, security investigations, billing disputes, regulatory retention duties where applicable)
• Customer-facing confirmation method (ticket closure statement, deletion report, or attestation where you offer it)

E. Where the policy is available

• Trust center page, contract exhibit, or customer portal location

Tie every promise to something you can prove.

Step 3: Put the policy into contracts and customer workflows

Operationalize “make it available to the customer” by:

• Linking the policy in your DPA/MSA package or security addendum
• Publishing it in a trust center with version control and change history
• Adding a customer portal entry for data export and closure workflows
• Ensuring Customer Success and Support have a standard response template pointing to the policy

Step 4: Build an offboarding runbook (your execution engine)

Create a runbook that support and operations can execute consistently:

1. Intake & authorization

• Confirm requester identity and admin authority for the tenant/account
• Capture request type: return, transfer, disposal, or combination
• Confirm scope: which environments, regions, and time ranges

2. Data return/export

• Generate export from approved tooling
• Encrypt exported data and deliver via approved channel
• Record hashes/checksums if your process supports integrity verification

3. Transfer (if applicable)

• Validate destination details provided by customer
• Use secure transport methods approved by security
• Maintain chain-of-custody notes in the ticket

4. Disposal

• Execute deletion tasks across the PII location map
• Include non-obvious stores: logs, analytics identifiers, support attachments
• Trigger subprocessor deletion requests where applicable and track confirmations
• Handle backups per your documented approach (do not overpromise)

5. Verification & closure

• Confirm deletion jobs completed successfully (system logs, job IDs, screenshots where appropriate)
• Provide customer confirmation consistent with the policy language

Step 5: Build a deletion/transfer evidence package that survives audit

You need a repeatable “proof bundle” per request/account. See the Evidence section below.

Step 6: Test it (tabletop + live-fire)

Run a tabletop exercise using a real tenant’s data map (in a non-production or sanitized context). Then run a controlled end-to-end test of export and deletion in a staging environment that mirrors production services. Capture gaps and update the policy/runbook.

Step 7: Manage change (policy drift is the silent failure mode)

Any new datastore, new telemetry pipeline, or new subprocessor can break disposal. Add a control: security/privacy sign-off for new systems that may store customer PII, with an explicit decision on how the system will support return/export and deletion.

Required evidence and artifacts to retain

Keep artifacts that prove both governance (policy exists and is available) and execution (requests were handled per policy):

Policy & availability

• Approved “PII Return, Transfer, and Secure Disposal Policy” with version history
• Customer-facing publication record (trust center page capture, contract exhibit reference, customer portal screenshot)
• Internal training/enablement materials for Support/CS on the workflow

Operational readiness

• PII location map (systems list and owners)
• Offboarding runbook with role assignments (Support, SRE, Security, Privacy, Legal)
• Subprocessor deletion/return clauses or operational procedures (where you rely on subprocessors)

Per-event evidence ¹

• Ticket/work order showing authorization, scope, and approvals
• Export logs (job IDs, timestamps, delivery method, encryption confirmation)
• Deletion job records across systems (job IDs, system logs, change records)
• Subprocessor deletion requests and confirmations
• Customer notification/closure statement consistent with the policy

Common exam/audit questions and hangups

Expect questions like:

• “Show me the customer-facing policy and where customers can access it.”
• “Walk me through a real offboarding: export, transfer, and deletion steps. Who does what?”
• “How do you ensure deletion includes logs, analytics, and support tooling?”
• “How do you handle backups? Where is that documented for customers?”
• “How do you confirm subprocessors delete customer PII after termination?”
• “How do you prevent policy drift when engineering introduces new datastores?”

Hangups auditors commonly find:

• Policy exists but is internal-only (fails “make available to the customer”)
• Policy promises “complete deletion everywhere immediately,” but backups/logs cannot support that statement
• No evidence bundle per offboarding event; everything is tribal knowledge

Frequent implementation mistakes (and how to avoid them)

1. Writing a policy that overpromises deletion.
   Fix: describe your real backup and log handling approach. Avoid absolute claims you cannot prove.

2. Treating export as “return” without custody controls.
   Fix: require authentication, admin authorization checks, secure delivery, and track chain-of-custody in a ticket.

3. Ignoring support channels as PII stores.
   Fix: include ticketing systems, attachments, and call artifacts in the PII location map and disposal checklist.

4. No subprocessor offboarding procedure.
   Fix: maintain a standard subprocessor deletion request workflow with tracked confirmations.

5. No change control for new PII stores.
   Fix: add an intake step to architecture reviews: “How will this system support export and secure disposal?”

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific cases.

Operational risk is still concrete:

• Customer trust and sales friction: enterprise customers often request offboarding terms during procurement. A vague or internal-only policy slows deals and triggers security exceptions.
• Data breach surface: retained customer PII in forgotten logs, support attachments, or old environments increases exposure during incidents.
• Disputes at termination: unclear responsibilities for return vs deletion can lead to escalations, legal holds, and messy handoffs.

Practical 30/60/90-day execution plan

Because no time-to-implement benchmarks are provided in the source catalog, use this as a sequencing guide rather than a promise.

First phase (immediate): Get to an auditable policy and a working path

• Draft the customer-facing policy that covers return, transfer, and secure disposal, and get Legal/Privacy/Security approval. ¹
• Publish it where customers can access it (trust center or contract exhibit) and train Support/CS on how to point customers to it. ¹
• Create a minimum viable offboarding runbook and ticket template.

Second phase (near-term): Make it complete across systems

• Build the PII location map and assign owners for each system.
• Expand the runbook to cover logs, analytics, support tooling, and subprocessors.
• Define standard evidence bundles and retention locations.

Third phase (operationalize): Prove repeatability

• Run a tabletop offboarding exercise and update gaps.
• Execute at least one controlled test export and disposal in a non-production environment that mirrors production.
• Add an architecture/change control gate to prevent new PII stores from bypassing return/disposal planning.

Ongoing: Keep the policy and practice aligned

• Review policy after material platform changes and subprocessor updates.
• Sample completed offboarding tickets for completeness and evidence quality.
• Use Daydream to track third-party and subprocessor obligations tied to offboarding, centralize evidence requests, and keep customer-facing commitments aligned with operational runbooks.

Frequently Asked Questions

Do we need to support all three actions (return, transfer, and disposal)?

ISO/IEC 27018 Annex A.10.3 requires a policy addressing return, transfer and/or secure disposal and making it available to customers. Your policy must clearly state what you offer and under what conditions, and it must match your actual capabilities. ¹

What does “make the policy available to the cloud service customer” mean in practice?

Customers must be able to access it without special backchannels, typically via your trust center, customer portal, or as a contract/DPA exhibit. Auditors will ask you to show where it lives and how customers are directed to it. ¹

Can we claim secure disposal if some data remains in backups?

You can, but your policy must describe backup handling truthfully and avoid absolute statements you cannot verify. Document the disposal scope (production, replicas, subprocessors) and explain how backup media is managed within your service design.

What evidence do customers and auditors usually want for deletion?

They want a traceable record: the authorized request, the systems in scope, deletion job outputs or logs, subprocessor confirmations where applicable, and a closure statement that matches your published policy. Keep it in a standard “proof bundle” format so you can produce it quickly.

Who should own this requirement internally?

The CCO/GRC lead should own policy governance and evidence expectations, but execution is shared: Support/CS runs intake, Engineering/SRE executes exports and deletion jobs, Security validates methods, and Legal/Privacy manages contractual language.

How do we handle PII in support tickets and attachments during offboarding?

Treat support systems as in-scope PII stores. Add ticket systems, attachments, and call artifacts to your PII location map, and include explicit steps in the disposal checklist to remove or redact them according to your policy.

Footnotes

1. ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors