Privacy requests after delivery: tracing what can actually be removed

Establish the applicable request and role first

A request-handling plan needs more than a delete button on the source archive. After delivery, the same material may exist in an export, a recipient workspace, an annotation copy and a transformation pipeline. The privacy operator must know which duty applies and which objects the request actually reaches.

This California agenda is current to 7 October 2026 and assumes a data broker’s statutory applicability has already been established. It does not classify VOID as a data broker. A direct consumer request to a controller, a DROP request to an applicable broker and a request governed by another jurisdiction are different routes; assess their requirements separately.

The current official statute and CalPrivacy instructions require applicable brokers to access DROP at least every 45 days, beginning 1 August 2026, and address deletion and specified provider/contractor instructions within the framework. The statutory exceptions are conditional and retained information is restricted to permitted purposes. A private contract is not a blanket exception.

Worked example: trace one delivered package

The following hypothetical request concerns an applicable California broker after a package has been delivered. The request has passed the organisation’s relevant matching review. The map is an internal evidence record, not real inventory or a claim that every artifact below falls within exactly the same legal duty.

The package manifest connects the subject’s source identifier to the export version and recipient workspace. It also records transformations and uncertainty. No model has been certified to forget the material, and no recipient has been contacted by this article.

Record matches and continuing suppression correctly

CalPrivacy’s current processing guidance and regulations address multiple identifier matches, status reporting and later-acquired information. A no-match response does not mean the operator may forget the request and resume ordinary acquisition later. The published workflow includes continuing suppression and matching requirements.

In the hypothetical case, an annotation system has used a second identifier. The operator links that artifact to the original manifest and records the pending response rather than closing it because the archive’s first identifier was deleted. The task owner must explain whether the annotation contains relevant personal information and which actual recipient relationship applies.

Use the current official matching/status rules for the actual case. Avoid inventing a deadline from an internal service target or marking every status deleted when an exception or technical dependency remains. Accurate reporting is an operating output, not a cosmetic label on the request tracker.

A recipient copy needs a recipient-specific decision

The official statute directs applicable service-provider and contractor handling within its conditions. An independent recipient may have a different role and legal or contractual obligations. The map must identify that relationship rather than issuing one generic deletion promise for every third party.

In this illustration, the privacy lead identifies the annotation operator as a separate recipient with unresolved role evidence. The completed decision stays open until the responsible legal owner establishes the applicable instruction and the operator’s actual response is documented. Source deletion evidence is retained as one completed step; it is not substituted for missing downstream evidence.

If an exception is asserted, the reviewer records the particular legal ground, material retained, permitted purpose and access restriction. Preserve uncertainty where the facts do not support the exception. The seller’s wish to keep a useful archive or comply with a commercial promise is not sufficient reasoning by itself.

Do not let a model claim close the traceability gap

A training-run manifest can show that a package was used. It cannot, alone, prove which information persists in a model or that a technical removal method has achieved a legally adequate outcome. Ask the responsible technical and legal reviewers what evidence the actual duty requires and what the available method can demonstrate.

The hypothetical request record closes only individually verified steps. Annotation response, embedding handling and model effects remain separately open with owners and the next evidence needed. It also tracks suppression so later intake does not silently recreate the affected records. A single green archive status would hide those dependencies.

Use due diligence to ask recipients about copy/transform handling before an evaluation, and inventory to preserve package lineage. A permissioned introduction through VOID does not authorize delivery or certify deletion capability. Design traceability before disclosure so a later request has a map to follow; do not promise universal erasure after the fact.