Mutually agreed upon PII disposal process

To meet the “mutually agreed upon PII disposal process” requirement, you must (1) provide your cloud customer a reviewable, written PII disposal procedure and (2) document the customer’s acceptance of how PII will be deleted, returned, and rendered unrecoverable at contract end or on request ¹. This is a contracting-plus-operations control: your legal terms, runbooks, and deletion evidence must match.

Key takeaways:

• Publish disposal procedures in a form customers can review before signing, not after an incident.
• Make disposal “mutual” with explicit agreement artifacts (order form, DPA/SOW clause, or security exhibit sign-off).
• Operationalize with triggers, timelines, system-specific methods, and proof packages that stand up in audits.

This requirement is easy to misunderstand because it sounds like a policy ask. It is not. ISO/IEC 27018 Annex A.11.13 expects a public cloud PII processor to run a disposal process that the customer can inspect and then affirmatively agree to ¹. If you cannot show the procedure, cannot show the customer had the chance to review it, or cannot show agreement, you will struggle in a certification audit and in enterprise procurement reviews.

For a CCO or GRC lead, the fastest path is to treat “PII disposal” like a productized capability: define disposal events (termination, customer request, account inactivity, backup expiry), define what “disposed” means by system tier (production, replicas, logs, analytics, backups), then bind it contractually and prove it operationally with consistent evidence. This page gives you requirement-level guidance you can implement quickly: what to write, what to negotiate, what to run, and what to retain.

Regulatory text

Requirement (excerpt): “Procedures for disposal of PII shall be made available to the cloud service customer to review. The disposal process shall be mutually agreed upon between the cloud service customer and the public cloud PII processor.” ¹

What the operator must do:

1. Make disposal procedures available for customer review. This means a written procedure (or set of procedures) customers can access during diligence and contracting, such as a security exhibit, DPA attachment, trust portal document, or customer-facing runbook.
2. Mutually agree on the disposal process. This means you can show a specific customer accepted the disposal process (or negotiated an alternative). Agreement must be captured in contract artifacts, not informal emails alone.

Plain-English interpretation

If you process customer PII in a public cloud service, you must be transparent about exactly how you delete/return PII and you must get the customer to agree to that method. “Mutual” does not require a bespoke process for every customer, but it does require an explicit acceptance mechanism and a way to handle exceptions when a customer requests different disposal terms.

Who it applies to

Entity scope

• Public cloud PII processors providing services where they process PII on behalf of cloud customers ¹.

Operational context (where the control bites)

This requirement becomes real when any of the following occur:

• Customer offboarding, contract termination, or non-renewal
• Customer-initiated deletion requests (account-level or data-subject-related where contract routes through customer)
• Service deprovisioning or environment teardown (tenant, workspace, project)
• Storage lifecycle events (log rotation, backup expiration, archival deletion)
• Incident response or legal hold situations (you must reconcile holds with disposal commitments)

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

Step 1: Define “PII disposal” precisely for your service

Create a disposal definition that covers:

• Actions: delete, overwrite/crypto-erase, anonymize (if you offer it), return/export to customer, and confirmation.
• Data locations: primary databases, object stores, caches, search indexes, analytics pipelines, message queues, logs, backups, replicas, and third-party subprocessors.
• State exceptions: legal hold, security incident preservation, regulatory retention that applies to you (if any), and customer-configured retention features.

Deliverable: a customer-facing “PII Disposal Procedure” document.

Step 2: Map systems and data classes to disposal methods

Build a matrix that engineers can execute and auditors can read.

Example disposal control matrix (minimum viable):

Data store / component	Contains PII?	Disposal method	Trigger	Proof generated
Primary tenant DB	Yes	Hard delete or crypto-erase	Termination / request	Job logs + DB deletion report
Object storage (uploads)	Yes	Delete + lifecycle confirmation	Termination / request	Deletion request ID + storage audit log
Application logs	Possibly	Redaction + retention expiry	Log rotation	Log retention config + sample log validation
Backups	Yes	Expire per schedule; restore blocking	Backup lifecycle	Backup policy + backup deletion evidence
Subprocessor system	Yes	Contracted deletion + attestation	Termination / request	Subprocessor confirmation

Keep it honest. If backups cannot be immediately deleted, your procedure must say so, and your contract language must match.

Step 3: Publish the procedure for customer review

Make the disposal procedure accessible during security review. Common patterns:

• Trust portal document labeled “Data Deletion and Disposal”
• Security exhibit attached to the MSA/DPA
• Customer-facing knowledge base article controlled under change management

Operational checkpoint: Sales and procurement must know where it is and how to provide it consistently.

Step 4: Make agreement explicit in contracting

You need a repeatable “acceptance mechanism.” Options:

• DPA clause that incorporates the disposal procedure by reference (with version/date)
• Security exhibit signed with the MSA/SOW
• Order form checkbox/line item referencing the disposal terms

Minimum requirements for the agreement artifact:

• Names the document (title) and version/date
• States disposal triggers (termination/request)
• States what happens to PII (delete/return) and key limitations (e.g., backups)
• States how confirmation is provided (certificate, ticket closure, report)

Step 5: Build an executable offboarding and deletion workflow

Treat disposal as an operational process with owners and SLAs (internally set). The workflow should include:

• Intake (who can request deletion, authentication, authorization)
• Scoping (which tenants/environments, which data classes)
• Execution (automated jobs preferred, with manual fallback)
• Verification (post-deletion checks and sampling)
• Customer notification (what evidence you provide)
• Exception handling (legal hold, unpaid invoices, fraud investigations, technical constraints)

If you use a ticketing system, create a dedicated request type: “Customer PII Disposal / Tenant Deletion.”

Step 6: Generate a standard proof package per disposal event

Your proof should be consistent and safe to share (no new PII leaks inside evidence). Typical contents:

• Request ID, requestor authentication record, approval
• Systems executed and timestamps
• Deletion job output (sanitized)
• Backup handling statement aligned to the agreed procedure
• Subprocessor deletion confirmations (if applicable)
• Completion attestation signed by an authorized operator (or system-generated certificate)

Step 7: Control changes to the disposal procedure

Because customers “mutually agree” to a process, changes need governance:

• Version the procedure
• Maintain change logs
• Notify customers when changes are material (align to your contract terms)
• Ensure your sales collateral and DPA references point to the correct version

Step 8: Test the process

Run a tabletop and at least one end-to-end test in a non-production environment mirroring production data flows. Capture defects and re-test after fixes. Your goal is to avoid discovering during an audit that “we think it deletes” is not verifiable.

Required evidence and artifacts to retain

Keep these artifacts organized by customer and by procedure version:

1. Customer-facing PII Disposal Procedure (versioned, dated)
2. Contractual agreement artifacts referencing the procedure (MSA/DPA/SOW/order form)
3. System disposal matrix (data stores → methods → evidence)
4. Offboarding/deletion runbook (internal) aligned to the customer procedure
5. Completed disposal tickets with approvals, execution logs, and customer notifications
6. Subprocessor evidence (deletion terms in subprocessor contracts; deletion confirmations when executed)
7. Change management records for updates to disposal procedures
8. Training/enablement records for teams who execute and communicate disposal

Common exam/audit questions and hangups

Auditors and customer assessors tend to focus on a few pressure points:

• “Show me where customers can review disposal procedures.” They want the actual document and distribution method ¹.
• “Prove mutual agreement for Customer X.” They will ask for the signed contract artifact and the referenced procedure version ¹.
• “What about backups, logs, and replicas?” If your procedure is silent here, expect a finding or a procurement escalation.
• “Show evidence of a completed disposal.” A policy alone fails; they want event evidence.
• “How do you ensure subprocessors dispose?” Expect questions on flow-down obligations and proof.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: The procedure exists, but customers can’t actually access it pre-contract.
   Fix: Put it in a trust portal or attach it to standard contracting packages.

2. Mistake: “Mutual agreement” is implied, not documented.
   Fix: Reference the procedure in the DPA/security exhibit with version control, then retain signed copies.

3. Mistake: The procedure promises deletion everywhere “immediately,” but backups can’t comply.
   Fix: Describe backup handling accurately and get customer agreement to those constraints.

4. Mistake: Engineering can delete a tenant, but no one can prove it later.
   Fix: Standardize evidence capture and retention for every disposal request.

5. Mistake: Subprocessors are ignored in disposal scope.
   Fix: Maintain a subprocessor map and require deletion support contractually, then operationalize confirmations.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific ISO/IEC 27018 control. Practically, failure shows up as:

• Sales friction and delayed security reviews
• Audit nonconformities in ISO/IEC 27018 certification efforts
• Contract disputes when customers request deletion and you cannot meet or evidence the agreed process
• Higher incident impact if retained data persists longer than customers expected

Practical 30/60/90-day execution plan

You can move fast without guessing timelines for engineering rebuilds by focusing on definitional clarity, contracting hooks, and evidence.

First 30 days (Immediate)

• Draft the customer-facing PII Disposal Procedure with clear scope: systems, triggers, methods, backup/log constraints.
• Create a contract clause/exhibit that references the procedure by version/date and includes an acceptance mechanism.
• Stand up a single intake channel for disposal requests (ticket type + approval workflow).
• Build the system disposal matrix and identify the top gaps (unknown data stores, missing logs, subprocessor uncertainty).

Days 31–60 (Near-term)

• Implement or refine automated deletion jobs for primary production data stores where feasible.
• Define verification checks (queries, counts, retrieval attempts) and standardize a proof package template.
• Update subprocessor contracts or add operational steps to obtain deletion confirmations.
• Train Sales, Support, and Security on where the disposal procedure lives and how to route exceptions.

Days 61–90 (Operational hardening)

• Run at least one end-to-end disposal test per major product line and retain the full evidence package.
• Put the disposal procedure under formal change control with versioning and customer notification rules.
• Add monitoring and reporting: open disposal requests, aged requests, exceptions (legal hold, technical limitations).
• Prepare an audit binder: policy/procedure, signed agreements, sample tickets, and evidence.

Where Daydream fits (without adding process drag)

If you manage third-party risk and customer assurance workflows in Daydream, use it to track: which customers received the disposal procedure, which version they agreed to, where the signed artifacts live, and which disposal requests have complete proof. The win is consistency: fewer one-off email hunts during audits and customer escalations.

Frequently Asked Questions

Do we need a unique PII disposal process for every customer to satisfy “mutually agreed upon”?

No. You need a process customers can review and an explicit record that each customer agreed to it (or to negotiated changes) ¹.

Can “mutual agreement” be satisfied by including the disposal procedure in a trust portal?

Only if the contract clearly incorporates the referenced procedure and you can show the customer agreed to that incorporation. A public document alone does not evidence mutual agreement ¹.

What if we can’t delete PII from backups on demand?

Document the backup limitation in the disposal procedure and make sure the customer agrees to it in the contract artifact. Then generate evidence that production data was deleted and backups are governed by the disclosed lifecycle.

Is anonymization an acceptable disposal method?

ISO/IEC 27018 A.11.13 requires an agreed disposal process and reviewable procedures; it does not prescribe a single method in the provided excerpt ¹. If you offer anonymization, define it precisely and ensure it meets the customer’s expectations and contract terms.

What evidence do auditors usually accept as proof of disposal?

Auditors typically expect a traceable request, authorized approval, execution records/logs, and a completion attestation tied back to the agreed procedure. The key is consistency and the ability to reproduce the story for a specific customer.

How do we handle legal holds without violating the agreed disposal process?

Your procedure must define exceptions such as legal hold, and your contract language should reserve the right to delay disposal when a hold applies. Track holds explicitly so you can explain why disposal was paused and when it resumed.

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