Return, transfer or disposal of PII (processor)

As a PII processor, you must be able to return PII to the customer, transfer it to a new provider, and/or securely dispose of it within the timeframe and method agreed in the contract, and you must document and implement policies that make this repeatable. Build an exit-ready process that covers all PII locations (including backups and sub-processors) and produces audit-ready evidence. ¹

Key takeaways:

• Contract language must define the “what, when, how” for PII return/transfer/disposal, including formats, deadlines, and scope.
• Your process has to cover the full data estate: production, logs, analytics, support tools, and backups, plus sub-processors.
• Auditors will look for provable execution: tickets, export manifests, deletion certificates, and sub-processor attestations.

“Return, transfer or disposal of PII (processor)” sounds like a contract cleanup task. In practice, it is an operational capability you need to run on demand, under time pressure, with high scrutiny. ISO/IEC 27701 Clause 8.4.2 requires two things: (1) the ability to return, transfer, and/or dispose of PII in a timely manner as agreed with the customer, and (2) documented policies that are implemented, not just written. ¹

For a CCO or GRC lead, the fastest path to operationalizing this requirement is to treat it as a standardized “customer exit and data handling” playbook. That playbook must map where customer PII lives, define approved export and deletion methods, coordinate sub-processors, and produce evidence that stands up in audits and customer due diligence. The failure mode is predictable: teams delete primary records but forget derived data, backups, or third-party tooling, then cannot prove what happened.

This page gives requirement-level guidance you can implement quickly: who owns what, what to build, what artifacts to retain, and what examiners and customers ask when they test your process.

Regulatory text

ISO/IEC 27701 Clause 8.4.2 states: “The organization shall provide the ability to return, transfer and/or disposal of PII in a timely manner as agreed with the customer and shall document and implement policies for this.” ¹

Operator interpretation (what you must do):

• Ability: You need a working, repeatable operational process to return PII, transfer it to another processor/controller, and/or dispose of it.
• Timely manner: “Timely” is not abstract; it is the timeframe you and the customer agree to in writing (usually in the MSA/DPA and exit terms).
• As agreed with the customer: Your contract must define scope, method, and constraints (format, secure delivery, deletion approach, treatment of backups, sub-processor coordination).
• Document and implement policies: A policy alone fails audits. You need procedures, roles, and records that show the process was executed.

Plain-English requirement

If a customer asks for their PII back, wants it moved to a new provider, or ends the relationship, you must be able to (a) export it in an agreed format, (b) transfer it securely, and/or (c) securely delete it, then prove you did it. Your process must include all the places PII exists, including systems you do not think of as “the database” (support tools, logs, backups, and sub-processors).

Who it applies to

Applies to: Organizations acting as PII processors delivering services that involve processing customer PII. ¹

Operational contexts where this gets tested:

• Contract termination / non-renewal (planned exit).
• Customer request during an active contract (data portability, migration, segregation demands).
• Incident response (customer demands data return/transfer and deletion verification).
• Sub-processor change (customer asks you to move data away from a sub-processor).

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

1) Set the contractual “exit criteria” you can meet

Work with Legal/Procurement/Sales Ops to standardize contract terms that your teams can execute:

• Define eligible actions: return, transfer to a named recipient, disposal.
• Define scope: which datasets count as customer PII (including derived data where applicable).
• Define format: CSV/JSON/database dump, schema documentation, encryption requirements.
• Define delivery method: secure file transfer, customer-managed bucket, encrypted media with chain of custody.
• Define deletion standard: deletion method, verification, and what happens with backups and archives.
• Define sub-processor obligations: flow-down requirements for deletion/return and evidence delivery.

Practical note: if Sales agrees to “immediate deletion everywhere including backups,” you may fail. Write terms that reflect your backup architecture and retention model, and document what “deletion” means for backups.

2) Build a PII location map (data inventory for exit)

Create a customer-scoped “PII data estate map” that answers: Where does customer PII exist? Include:

• Primary application databases and object stores
• Search indexes and caches
• Analytics/warehouse datasets
• Logs and monitoring data
• Support tooling (ticketing, chat transcripts, call recordings)
• CI/CD artifacts (rare, but check)
• Backups, archives, cold storage
• Sub-processors that receive or store PII

This map is the backbone of both execution and audit defense.

3) Define three runbooks: Return, Transfer, Dispose

Write operational procedures that an on-call team can follow without improvising.

Return runbook

• Validate requester authority (customer’s authorized contacts).
• Identify datasets and timeframe (full export vs subset).
• Generate export in approved format.
• Apply encryption and access controls.
• Provide a data manifest (what fields, what systems, export timestamp).
• Record delivery confirmation.

Transfer runbook

• Confirm recipient and transfer method (customer environment or new processor).
• Complete security checks for the transfer channel.
• Transfer data and provide integrity checks (hashes) if your process supports it.
• Document chain of custody and completion.

Disposal runbook

• Freeze processing where needed to prevent re-creation of data during deletion.
• Delete from primary systems first, then secondary stores, then derived datasets.
• Handle logs/support artifacts per agreed terms.
• Trigger sub-processor deletion requests and track confirmations.
• Address backups/archives per contractual language (for example, data is removed from active systems and will age out of backups per retention controls).
• Generate deletion evidence package.

4) Integrate sub-processors (don’t treat this as “their problem”)

For every sub-processor that may hold customer PII:

• Ensure the contract requires return/transfer/disposal support and evidence production aligned to your customer commitments.
• Maintain a contact and escalation path.
• Create a standard “sub-processor deletion request” ticket template.
• Track completion and retain the attestation/certificate in your evidence package.

5) Operationalize with workflow, roles, and approvals

Make it executable:

• Create an intake workflow (ticket type) for “Customer PII return/transfer/disposal.”
• Assign roles: Request owner (Customer Success), Security approver (Infosec), Data engineer/operator (Engineering), Privacy/Compliance reviewer (GRC), Sub-processor coordinator (TPRM).
• Require a completion checklist and attach all artifacts before closure.
• Add a “lessons learned” step to update the PII location map when surprises occur.

6) Test the process before a customer forces the test

Run tabletop exercises using a real customer footprint (with internal test data if needed):

• Can you identify all PII locations quickly?
• Can you export in the format you promised?
• Can you complete deletions and gather proof across sub-processors?
• Do you have gaps around backups, logs, or support tooling?

A practical way to systematize this is to track each customer’s “exit readiness” in a third-party risk and compliance workspace like Daydream, so the contract terms, data map, sub-processor list, and evidence pack are tied together and searchable during an exit.

Required evidence and artifacts to retain

Auditors and customers typically want proof, not assurances. Keep an “exit evidence pack” with:

• Policy covering return/transfer/disposal and roles/responsibilities (required by the clause). ¹
• Procedures/runbooks (return, transfer, disposal) and step checklists.
• Customer agreement terms: DPA/MSA exit clause, scope, timelines, formats.
• Data location map (systems list and sub-processors involved).
• Export artifacts: manifests, schemas, timestamps, delivery confirmation.
• Deletion records: change tickets, job logs, scripts run, system screenshots where appropriate.
• Sub-processor confirmations: certificates/attestations, emails, or portal confirmation exports.
• Exception approvals: anything you could not delete/return, documented and approved per contract.

Common exam/audit questions and hangups

Expect these:

• “Show the policy and procedure that implements ISO 27701 Clause 8.4.2.” ¹
• “Provide evidence from a completed customer exit: what was returned, what was deleted, when, and by whom?”
• “How do you ensure derived data, logs, and support tickets are included?”
• “How do you handle backups and archives? What does the contract say?”
• “How do you ensure sub-processors delete data, and how do you verify?”
• “What happens if the customer asks for transfer to a competitor or a risky destination?”

Hangups usually appear in backups and in tooling outside engineering’s view (support systems, marketing automation, analytics).

Frequent implementation mistakes and how to avoid them

• Mistake: Treating deletion as a single database operation.
  Fix: Make the PII location map mandatory for closure; require sign-off from system owners.

• Mistake: No contract-to-operations alignment.
  Fix: Standardize exit terms and runbooks together; reject non-executable sales redlines.

• Mistake: Ignoring sub-processors until termination week.
  Fix: Pre-wire sub-processor deletion workflows and evidence expectations in onboarding.

• Mistake: No evidence package.
  Fix: Make the ticket workflow require artifacts before closure; audit your own packets quarterly.

• Mistake: Confusing “age out” with “deleted,” without documenting it.
  Fix: Document backup handling precisely in customer terms and in the disposal runbook.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source catalog, so this page does not list specific cases. Practically, this control sits at the intersection of contractual breach risk, customer due diligence failures, and privacy incident escalation: if you cannot return/transfer/dispose reliably, you create avoidable disputes at termination and lose credibility during audits.

Practical execution plan (30/60/90-day)

Use phased execution without relying on fixed-duration promises in customer contracts.

First phase: Immediate

• Inventory current exit/termination commitments in templates and signed contracts.
• Draft or update the policy required by ISO/IEC 27701 Clause 8.4.2 and assign accountable owners. ¹
• Stand up a single intake workflow (ticket) for all return/transfer/disposal requests.
• Build a first-pass PII location map for your core product and top sub-processors.

Second phase: Near-term

• Write and approve the three runbooks (return, transfer, disposal) with Engineering, Security, and Support.
• Update sub-processor contracts or add operational addenda to require deletion/return support and evidence.
• Pilot the process on one internal “mock customer exit” and one real low-risk customer request (if available).
• Define an evidence pack template and make it mandatory.

Third phase: Ongoing

• Run periodic drills and update the data location map after system changes.
• Add exit readiness checks to change management (new datastore, new log pipeline, new sub-processor).
• Centralize artifacts (contracts, sub-processor list, exit tickets, evidence packs) in a system of record such as Daydream so you can answer customer audits quickly and consistently.

Frequently Asked Questions

Does “return” mean we must provide a full database dump?

Only if you agreed to that. The requirement is to return/transfer/dispose “as agreed with the customer,” so define export format and scope in the contract and make sure your runbook can produce it. ¹

How do we handle backups if we can’t delete individual customer records from them?

Address it explicitly in customer terms and your disposal runbook. A common pattern is deletion from active systems with backup retention and eventual overwrite, but you need the agreement and a way to explain and evidence the control.

What counts as “PII locations” beyond the production database?

Include logs, monitoring/observability tools, analytics warehouses, support ticketing, and any sub-processor that stores or can access customer PII. If your exit process does not cover these, you will miss data and fail to prove completion.

What evidence is usually enough to prove disposal?

Keep deletion tickets, job logs or scripts executed, system-owner sign-offs, and sub-processor attestations in a single evidence pack. The goal is a coherent chain from request to completion, mapped to systems.

Do we need to support transfer to any new processor the customer selects?

The clause requires capability as agreed with the customer, so your contract can constrain transfer methods for security and feasibility. Document approval steps for unusual destinations and keep the decision record.

Who should own the end-to-end process internally?

Assign one accountable owner for the workflow (often GRC, Privacy, or Customer Success Ops), with Engineering owning technical execution and TPRM coordinating sub-processors. Without a single owner, exits become ad hoc.

Footnotes

1. ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management