Notifications
Clear all
Topic starter
11/07/2026 8:36 pm
TL;DR: California’s Delete Request and Opt-Out Platform centralises deletion requests so residents can submit one request to registered data brokers, while brokers must meet fixed retrieval, deletion, and reporting obligations under the Delete Act, according to OneTrust. The shift turns deletion into a repeatable control process, not a one-off privacy workflow, and exposes where manual consent operations no longer scale.
NHIMG editorial — based on content published by OneTrust: California’s DROP and what the Delete Act changes for consent, preferences, and data deletion
Questions worth separating out
Q: What fails when deletion requests are handled as manual privacy tickets?
A: Manual handling breaks down when matching, routing, and evidence capture are spread across teams and tools.
Q: Why does DROP create extra risk for data brokers with enrichment models?
A: Because DROP looks beyond direct collection and focuses on whether a business knowingly sells consumer data without a direct relationship.
Q: How do teams know whether deletion automation is actually working?
A: They should measure completion rates, exception rates, time to fulfilment, and residual data found in downstream systems.
Practitioner guidance
- Map broker exposure against the statutory definition Review whether the organisation knowingly collects and sells personal information of consumers with whom it has no direct relationship.
- Automate request intake and identity matching Build a workflow that ingests DROP requests, validates consumer identifiers, routes matches to the right systems, and logs each decision.
- Extend deletion to derived data and downstream copies Ensure fulfilment logic removes associated records, inferences, replicas, and partner-held copies where contracts and technical integrations allow.
What's in the full article
OneTrust's full blog covers the operational detail this post intentionally leaves for the source:
- The Delete Act definition tests that determine whether a business is in broker scope.
- The request retrieval cadence, registration deadlines, and API integration timing that drive implementation planning.
- The matching and deletion workflow details for confirmed records, including inferences and status reporting.
- How OneTrust positions Data Subject Request Automation for teams that need a repeatable fulfilment process.
👉 Read OneTrust's analysis of California DROP and deletion governance changes →
California DROP: what it means for deletion, consent, and data brokers?
Explore further
11/07/2026 9:06 pm
DROP turns deletion into a lifecycle governance problem, not a customer-service workflow. The operational issue is no longer whether a request can be received, but whether identity matching, data discovery, and deletion evidence hold together across systems. That makes the programme closer to IAM-style lifecycle control than to a simple privacy inbox. Practitioners should treat deletion as a governed process with ownership, auditability, and exception management.
A question worth separating out:
Q: Who is accountable when consumer deletion rights are centralised across a regulator-run platform?
A: The organisation remains accountable for receiving, matching, deleting, and evidencing the request, even if the consumer uses a central platform to submit it. Regulators do not transfer operational responsibility to the portal. Teams must own the control chain end to end.
👉 Read our full editorial: California DROP and the new operating model for deletion requests
