You Deleted the Data. What Happens When It Comes Back? │ CLICBrain Weekly Briefing - Issue #16

Compliance Intelligence for Online Businesses.

What Changed. Why It Matters. What to Do Next.

You Deleted the Data. What Happens When It Comes Back?

Welcome to the CLICBrain Weekly Briefing – operational compliance intelligence for internet businesses from CLIClaw.com.

Each week, we identify significant privacy, AI, advertising, data governance, email marketing, and regulatory developments and focus on what they mean operationally: what systems, workflows, governance controls, and evidence organizations should examine in response.

This week’s focus: preparing for California DROP’s August 1 processing obligations and testing whether consumer requests remain effective when new data arrives. Beginning August 1, 2026, data brokers subject to California’s Delete Act must access the state’s Delete Request and Opt-out Platform, or DROP, at least once every 45 calendar days. They must process downloaded requests and report their statuses within 45 days of downloading them, while continuing to retrieve subsequent requests on the required schedule.

But the operational challenge does not end when a broker deletes the information it currently holds. Following deletion under the statute, covered brokers must continue deleting the consumer’s personal information at least once every 45 days, subject to applicable exceptions and unless the consumer requests otherwise. They also must not sell or share newly collected personal information about that consumer unless the consumer requests otherwise or an applicable statutory exemption permits it.

That creates two connected controls: recurring deletion and screening newly collected information before sale or sharing. The recurring deletion cycle is not permission to sell or share the information before the next scheduled deletion.

The organization needs to preserve the effect of the consumer’s request even after the underlying profile has been removed from ordinary business use.

Some Privacy Choices Have to Survive the Transaction.

Many compliance workflows are designed around events:

Request received.
Information matched.
Required action completed.
Status reported.
Request closed.

That model is incomplete when the request has continuing effect.

What happens when the same consumer’s information returns? It may arrive through:

A new marketing list.
A data vendor.
An enrichment provider.
A reseller.
An advertising partner.
An identity-resolution system.
Another dataset.

If the organization simply reloads the information without checking the applicable request, its ordinary data pipeline may undo the effect of the earlier deletion.

For covered brokers processing DROP requests, the operational objective is therefore broader than deleting today’s records. The process must preserve the applicable instruction, recognize relevant newly collected information, prevent prohibited sale or sharing, and perform recurring deletion as required.

This briefing’s specific recurring-deletion and newly collected data requirements concern covered California data brokers processing DROP requests. Other deletion, marketing, and opt-out workflows may have different legal effects. Before applying a persistence control, identify the applicable law, the scope of the consumer’s instruction, and any relevant exceptions or subsequent changes to the request.

The broader governance lesson is persistence: When a consumer instruction has continuing effect, the control must survive the original transaction.

What Happens If Deleted Data Comes Back Next Month?

Pick one DROP deletion workflow. Imagine that the consumer’s non-exempt information is successfully deleted today. Now imagine that 30 days later, a vendor sends your organization a new file containing information about that consumer. What happens?

Does the system recognize the applicable request?
Is the incoming information checked before sale or sharing?
Is prohibited sale or sharing prevented?
Is the non-exempt information scheduled for deletion within the applicable recurring cycle?
Are relevant service providers and contractors instructed to act?
Is any exception documented and its permitted use enforced?
Can the organization demonstrate the result?

Now consider a second scenario: The consumer was not found when the request was first processed, but their information arrives later. Does the system recognize that request too?

CalPrivacy’s guidance addresses ongoing compliance identifiers for both matched and unmatched requests. An initial “Not found” result does not mean the request can simply be discarded. If matching information is collected later, the broker must process it appropriately and update the request status.

If the answer is, “We already closed that request,” you may have identified a workflow gap.

The original processing step ended. The continuing obligation did not.

California DROP Makes Deletion a Recurring Operation.

California’s Delete Act created a centralized mechanism through which consumers can submit deletion requests to covered data brokers.

Beginning August 1, 2026, those brokers must operate on two related schedules:

ACCESS AND DOWNLOAD. Access DROP and download the applicable consumer request lists at least once every 45 calendar days.
PROCESS AND REPORT. Process downloaded requests and report their statuses within 45 days of downloading them. Completing a batch does not suspend the recurring access schedule.

The obligations extend beyond a one-time deletion from a primary database.

Following deletion under the statute, brokers must continue deleting the consumer’s personal information at least once every 45 days, subject to applicable exceptions and unless the consumer requests otherwise. They must also prevent prohibited sale or sharing of newly collected information about that consumer.

The ongoing process needs to account for requests that initially produce no match. CalPrivacy directs brokers to maintain the identifiers needed to recognize applicable requests when information is collected later, including requests initially reported as “Not found.”

Deletion and opt-out outcomes also need to be distinguished. When a request cannot be verified, the statute requires it to be processed as a sale-or-sharing opt-out, subject to the statute’s limitations. “No deletion occurred” does not necessarily mean “no action was required.”

That changes the operational model.

Instead of: REQUEST → DELETE → CLOSE.

The workflow needs to account for: REQUEST → MATCH → PROCESS → PRESERVE REQUEST → SCREEN NEW DATA → DELETE AS REQUIRED → UPDATE STATUS.

The compliance control must remember the applicable instruction, not recreate the deleted profile.

1. Limited Compliance Identifiers Can Preserve the Request. Keeping information about someone who requested deletion may initially sound contradictory.

But covered brokers need a way to recognize applicable requests when matching information appears again, or appears for the first time.

CalPrivacy’s guidance addresses ongoing identifier lists for matched and unmatched requests. It instructs brokers to retain only the minimum information necessary to maintain their compliance obligations and not use that information for another purpose. Brokers do not have to use DROP’s identifiers for their ongoing compliance lists; they should use the identifiers needed to maintain compliance.

The objective is not to rebuild the consumer’s deleted profile. It is to recognize the request, prevent prohibited sale or sharing, and support required recurring deletion. That requires careful design:

What identifiers are necessary?
Where are they stored?
Who can access them?
What uses are permitted?
How are incoming records checked against them?
How are amended requests reflected?
How long are the identifiers needed to fulfill the continuing obligation?
How is the information kept separate from active marketing and commercial datasets?

DROP uses hashed identifiers for matching, but hashing does not eliminate the need to restrict the information’s use. The identifiers still serve a consumer-recognition function.

✔ CLIClaw Compliance Tip: A limited compliance record should preserve the request, not become another audience, enrichment, or marketing dataset.

2. New Vendor Data Can Recreate an Old Privacy Problem. Suppose a consumer’s information is deleted from your systems. Six weeks later, Marketing purchases another audience file. The consumer appears again.

Technically, this may look like newly acquired information. Operationally, however, the organization may already have an applicable instruction associated with that person.

For covered DROP workflows, CalPrivacy directs brokers to compare their compliance identifiers against newly collected information before that information is sold or shared.

That means vendor intake and deletion governance cannot operate independently.

The organization needs to know:

Where incoming data enters.
Which identifiers are available for matching.
When the request check occurs.
What happens when a match is found.
Whether sale or sharing is blocked.
When recurring deletion occurs.
How failed checks or integrations are detected.

A recurring deletion job is one control. Screening information before prohibited sale or sharing is another. Both need to work.

3. Deletion Has to Reach the Relevant Data Supply Chain. A broker may delete information from its primary database while relevant copies remain in other systems or with service providers and contractors.

CalPrivacy’s DROP guidance directs covered brokers to instruct their service providers and contractors to take the applicable action, including deleting non-exempt information or implementing the required sale-and-sharing opt-out.

Operationally, map the systems and entities holding the information, determine their roles, and document the required instructions and resulting actions.

An analytics platform, marketing system, or cloud environment describes a technology function. It does not, by itself, establish the entity’s legal role or obligations.

Also distinguish information that must be deleted from information that may be retained under an applicable exception. Information retained under the Delete Act’s specified deletion exceptions must remain limited to the permitted purposes; it cannot be used or disclosed for unrelated purposes, including marketing.

✔ CLIClaw Compliance Tip: An exception permitting retention is not a general authorization to return the information to ordinary commercial use.

The Operational Problem: The Data Pipeline Doesn’t Remember.

Modern data environments are built to acquire information continuously.

New records arrive.
Lists are refreshed.
Profiles are enriched.
Identifiers are matched.
Data is synchronized.
Records are updated.

Those systems are designed to make data flow.

A continuing privacy instruction asks them to make distinctions: recognize the consumer, apply the correct restriction, delete information when required, and prevent prohibited downstream activity.

If the instruction does not persist somewhere in the architecture, the ordinary pipeline may recreate what the deletion workflow removed. That creates an unusual governance question: How do you remember that someone asked to be forgotten?

For DROP, the answer is not to retain the entire deleted profile. CalPrivacy’s guidance calls for the minimum information needed to maintain compliance, restricted to that purpose.

The operational task is to connect that limited compliance information to the places where new data enters and where sale, sharing, deletion, and downstream instructions occur.

“We Deleted Everything, Including the Compliance Identifier.”

That may sound privacy-protective. But if the request has continuing effect, removing every mechanism for recognizing it can undermine the control. When information arrives again, the business may fail to:

Recognize the applicable request.
Prevent prohibited sale or sharing.
Perform required recurring deletion.
Instruct relevant service providers and contractors.
Update the request status.

A related red flag is: “We Only Keep Identifiers for Successful Deletions.”

That approach can miss consumers whose requests initially produced no match but whose information is acquired later. CalPrivacy’s guidance addresses retaining the identifiers needed for continuing compliance for both matched and unmatched requests.

✔ CLIClaw Compliance Tip: Where a request has continuing effect, preserve the limited compliance information needed to honor that effect. Do not preserve the full profile merely because some identifiers are necessary.

Run the “What If It Comes Back?” Test.

Review a completed workflow, or simulate a request using synthetic identifiers in a controlled test environment. Do not reload a real consumer’s deleted information into production merely to test whether suppression works.

CalPrivacy provides a DROP Sandbox for integration and request-processing testing and recommends fake data for testing standardization and hashing.

Test two scenarios:

A consumer whose information was previously matched and deleted.
A consumer whose request was previously reported as “Not found,” but whose information now arrives.

Introduce the test information through one realistic intake path:

A purchased list.
A vendor feed.
A CRM import.
An enrichment file.
Another recurring data source.

Then ask:

Does the system recognize the applicable request?
Is newly collected information screened before sale or sharing?
Is prohibited sale or sharing prevented?
Is non-exempt information deleted within the applicable recurring cycle?
Are service providers and contractors directed to take the required action?
Is any applicable exception documented and its permitted use enforced?
If the request’s status changes, is DROP updated within 45 days of detecting the change?
If matching, synchronization, or vendor instructions fail, who detects, retries, and escalates the failure?

Document the result through appropriate logs, timestamps, instructions, and completion records.

These records are practical evidence for evaluating the control. The objective is to demonstrate the complete outcome, not just that an import ran or a deletion job completed.

You are testing three different things:

Whether the request is remembered.
Whether restricted activity is prevented.
Whether the required deletion and reporting actions occur.

Q: If we delete someone’s personal information, how can we keep enough information to know not to add them again?

CLICBrain: For covered brokers processing DROP requests, this requires distinguishing the consumer’s commercial profile from the limited information needed to maintain compliance.

CalPrivacy’s guidance instructs brokers to retain only the minimum information necessary for that compliance purpose and not use it for another purpose. It also addresses ongoing identifiers for both matched and unmatched requests.

The purpose is not necessarily to prohibit every form of collection under every circumstance. It is to recognize the applicable request and carry out its required effect, including recurring deletion and restrictions on sale or sharing.

Operational questions include:

What minimum identifiers are necessary?
Can they be separated from active commercial and marketing records?
Are access and permitted uses restricted?
Can incoming information be checked against them before sale or sharing?
Are previously unmatched requests included?
Can relevant service providers and contractors honor the required instruction?
How are amended requests and applicable exceptions handled?
Can the organization demonstrate that the retained information is used only for its compliance purpose?

The exact design depends on the applicable requirements and the organization’s systems.

The governing principle is straightforward: Preserve the instruction without rebuilding the profile that should have been deleted.

Have another compliance question? Ask CLICBrain on CLIClaw.com.

One Question to Take With You.

If a consumer submitted a DROP request today and their information arrived from a vendor next month, would your systems recognize the request and apply the required outcome?

Test that question for both a previously deleted consumer and a consumer who was initially “Not found.” That is where this week’s review should begin.

CLICBrain Weekly Briefings provide operational compliance intelligence and commentary for internet businesses. Regulatory developments, enforcement activity, and legal requirements discussed herein should be evaluated in the context of your organization’s specific operations, systems, data practices, jurisdictions, and risk profile. This briefing is for informational and educational purposes only and does not constitute legal advice.

You Deleted the Data. What Happens When It Comes Back? │ CLICBrain Weekly Briefing – Issue #16

Compliance Intelligence for Online Businesses.

What Changed. Why It Matters. What to Do Next.

You Deleted the Data. What Happens When It Comes Back?

Welcome to the CLICBrain Weekly Briefing – operational compliance intelligence for internet businesses from CLIClaw.com.

Each week, we identify significant privacy, AI, advertising, data governance, email marketing, and regulatory developments and focus on what they mean operationally: what systems, workflows, governance controls, and evidence organizations should examine in response.

That creates two connected controls: recurring deletion and screening newly collected information before sale or sharing. The recurring deletion cycle is not permission to sell or share the information before the next scheduled deletion.

The organization needs to preserve the effect of the consumer’s request even after the underlying profile has been removed from ordinary business use.

Some Privacy Choices Have to Survive the Transaction.

Many compliance workflows are designed around events:

Request received.

Information matched.

Required action completed.

Status reported.

Request closed.

That model is incomplete when the request has continuing effect.

What happens when the same consumer’s information returns? It may arrive through:

A new marketing list.

A data vendor.

An enrichment provider.

A reseller.

An advertising partner.

An identity-resolution system.

Another dataset.

If the organization simply reloads the information without checking the applicable request, its ordinary data pipeline may undo the effect of the earlier deletion.

The broader governance lesson is persistence: When a consumer instruction has continuing effect, the control must survive the original transaction.

What Happens If Deleted Data Comes Back Next Month?

Pick one DROP deletion workflow. Imagine that the consumer’s non-exempt information is successfully deleted today. Now imagine that 30 days later, a vendor sends your organization a new file containing information about that consumer. What happens?

Does the system recognize the applicable request?

Is the incoming information checked before sale or sharing?

Is prohibited sale or sharing prevented?

Is the non-exempt information scheduled for deletion within the applicable recurring cycle?

Are relevant service providers and contractors instructed to act?

Is any exception documented and its permitted use enforced?

Can the organization demonstrate the result?

Now consider a second scenario: The consumer was not found when the request was first processed, but their information arrives later. Does the system recognize that request too?

If the answer is, “We already closed that request,” you may have identified a workflow gap.

The original processing step ended. The continuing obligation did not.

California DROP Makes Deletion a Recurring Operation.

California’s Delete Act created a centralized mechanism through which consumers can submit deletion requests to covered data brokers.

Beginning August 1, 2026, those brokers must operate on two related schedules:

ACCESS AND DOWNLOAD. Access DROP and download the applicable consumer request lists at least once every 45 calendar days.

PROCESS AND REPORT. Process downloaded requests and report their statuses within 45 days of downloading them. Completing a batch does not suspend the recurring access schedule.

The obligations extend beyond a one-time deletion from a primary database.

The ongoing process needs to account for requests that initially produce no match. CalPrivacy directs brokers to maintain the identifiers needed to recognize applicable requests when information is collected later, including requests initially reported as “Not found.”

Deletion and opt-out outcomes also need to be distinguished. When a request cannot be verified, the statute requires it to be processed as a sale-or-sharing opt-out, subject to the statute’s limitations. “No deletion occurred” does not necessarily mean “no action was required.”

That changes the operational model.

Instead of: REQUEST → DELETE → CLOSE.

The workflow needs to account for: REQUEST → MATCH → PROCESS → PRESERVE REQUEST → SCREEN NEW DATA → DELETE AS REQUIRED → UPDATE STATUS.

The compliance control must remember the applicable instruction, not recreate the deleted profile.

1. Limited Compliance Identifiers Can Preserve the Request. Keeping information about someone who requested deletion may initially sound contradictory.

But covered brokers need a way to recognize applicable requests when matching information appears again, or appears for the first time.

The objective is not to rebuild the consumer’s deleted profile. It is to recognize the request, prevent prohibited sale or sharing, and support required recurring deletion. That requires careful design:

What identifiers are necessary?

Where are they stored?

Who can access them?

What uses are permitted?

How are incoming records checked against them?

How are amended requests reflected?

How long are the identifiers needed to fulfill the continuing obligation?

How is the information kept separate from active marketing and commercial datasets?

DROP uses hashed identifiers for matching, but hashing does not eliminate the need to restrict the information’s use. The identifiers still serve a consumer-recognition function.

✔ CLIClaw Compliance Tip: A limited compliance record should preserve the request, not become another audience, enrichment, or marketing dataset.

2. New Vendor Data Can Recreate an Old Privacy Problem. Suppose a consumer’s information is deleted from your systems. Six weeks later, Marketing purchases another audience file. The consumer appears again.

Technically, this may look like newly acquired information. Operationally, however, the organization may already have an applicable instruction associated with that person.

For covered DROP workflows, CalPrivacy directs brokers to compare their compliance identifiers against newly collected information before that information is sold or shared.

That means vendor intake and deletion governance cannot operate independently.

The organization needs to know:

Where incoming data enters.

Which identifiers are available for matching.

When the request check occurs.

What happens when a match is found.

Whether sale or sharing is blocked.

When recurring deletion occurs.

How failed checks or integrations are detected.

A recurring deletion job is one control. Screening information before prohibited sale or sharing is another. Both need to work.

3. Deletion Has to Reach the Relevant Data Supply Chain. A broker may delete information from its primary database while relevant copies remain in other systems or with service providers and contractors.

CalPrivacy’s DROP guidance directs covered brokers to instruct their service providers and contractors to take the applicable action, including deleting non-exempt information or implementing the required sale-and-sharing opt-out.

Operationally, map the systems and entities holding the information, determine their roles, and document the required instructions and resulting actions.

An analytics platform, marketing system, or cloud environment describes a technology function. It does not, by itself, establish the entity’s legal role or obligations.