DROP turns deletion compliance into an identity resolution test

At a glance

What this is: California’s DROP regime makes deletion operations depend on identity resolution, because broker requests arrive as hashed identifiers that must be matched, assembled, and actioned across multiple systems.

Why it matters: It matters because privacy and IAM teams now need deletion workflows that can resolve the same person across disconnected records, or reporting, enforcement, and remediation all break down.

By the numbers:

• 566 registered data brokers must check DROP every 45 days, according to Transcend.
• The fine is $200 per request, per day, with no cure period, according to Transcend.

Context

DROP is a regulatory workflow for consumer deletion and opt-out requests, but the operational challenge sits underneath the law: the organisation must identify the same person across disconnected records before it can delete anything correctly. That makes the problem one of identity resolution, not just deadline management.

The first-stage mistake is treating DROP like a privacy-team queue. In practice, the article argues that the real control point sits in data infrastructure, where matching, assembling, and reporting must happen consistently across systems and data formats, including DSAR handling patterns that already depend on reliable identity verification.

Key questions

Q: What breaks when deletion requests cannot be resolved to one person?

A: The workflow breaks at the point where matching becomes reporting. If the same consumer is fragmented across multiple records, teams may delete only part of the data, overstate completion, or miss systems entirely. The result is not just operational inefficiency, but inaccurate compliance evidence and avoidable regulatory exposure.

Q: Why do privacy deletion workflows need identity resolution rather than ticketing alone?

A: Ticketing tracks work, but identity resolution determines whether the work is correct. A deletion request must be matched, assembled, and applied to the right person across all systems, otherwise one request can become several partial actions and a false sense of completion. Automation has to operate on identity, not on spreadsheet rows.

Q: What are the signs that deletion compliance is failing at scale?

A: Common warning signs include manual report-back preparation, repeated re-matching of the same consumer, disconnected deletions across systems, and growing delay as request volume rises. If the workflow depends on people stitching evidence together after execution, the control is already too fragile for recurring regulatory cycles.

Q: Who should own DROP compliance when data lives across many systems?

A: Ownership should sit with the team that controls data paths, integrations, and audit evidence, because they are the only group that can make the workflow deterministic. Legal and privacy teams still govern the policy, but engineering has to run the mechanism that executes deletion and proves completion.

Technical breakdown

Why DROP creates an identity resolution problem

DROP sends deletion requests as hashed identifiers across six list types, including email, phone, mobile advertising ID, name plus date of birth plus ZIP, name plus VIN, and connected TV ID. There is no universal shared identifier across those lists, so the same consumer can appear as several unrelated records. The technical issue is not simply locating data, but normalising broker-provided hashes, matching them against internal records, and proving that multiple hits belong to the same person before deletion begins. Read DSAR Guide: Handling Data Subject Requests.

Practical implication: Practitioners should design the matching layer as a governed identity-resolution service, not a manual lookup process.

Why person-scoped deletion beats ticket-based workflows

A ticketing workflow can track requests, but it cannot reliably execute deletion across every downstream system or produce an accurate report-back file at scale. The article’s core mechanism is policy-as-code: a matched request becomes a person-scoped deletion job, the job fans out to all systems holding that person’s data, and the audit trail is generated by execution rather than reconstructed from spreadsheets. That is the difference between semi-automation and durable operational control. See the Compliance Automation Guide.

Practical implication: Practitioners should bind deletion to an executable workflow that spans all configured systems and writes its own evidence trail.

How core identifiers stabilise recurring compliance cycles

The article describes a persistent identifier model in which a resolved person key becomes the anchor for later DROP cycles. That means the system does not re-derive who the person is every 45 days; it reuses the previously resolved identity so future requests land on the same subject instead of being treated as a fresh record each time. This is a governance pattern borrowed from broader privacy and personalization operations, but here it is required for compliance continuity.

Practical implication: Practitioners should preserve a stable core identifier for each resolved person so repeated regulatory cycles stay consistent.

Threat narrative

Attacker objective: The objective is not an attacker outcome but a regulatory enforcement outcome: force organisations to prove they can identify, delete, and report consumer data correctly across fragmented systems.

1. Entry occurs when a broker receives hashed deletion requests in six list types that do not share a common identifier, creating ambiguity before any deletion can start.
2. Credential_harvested is not the right model here; the critical control point is identity matching, where fragmented records must be assembled into one person-scoped request before action is taken.
3. Impact appears when organisations cannot accurately delete across all systems or report completion back to the state, exposing them to recurring non-compliance and daily fines.

Breaches seen in the wild

• iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

DROP exposes a governance gap that privacy teams often miss: identity resolution is now an enforcement control. The article shows that the state is not asking whether a request was logged, but whether the right person was identified across multiple incompatible list types before deletion and reporting occurred. That shifts the control question from case management to identity assurance. Practitioners should treat person resolution as part of compliance evidence, not a back-office convenience.

Manual deletion operations do not scale when the regulator checks every 45 days. A ticket queue can satisfy a small volume of requests, but it cannot sustain repeated matching, cross-system erasure, and report-back generation at hundreds of thousands of requests. The article’s infrastructure framing is correct: the durable model is automated execution with evidence captured as a byproduct. Practitioners should move deletion into platform engineering ownership, not keep it inside a legal intake process.

Privacy operations now depend on the same identity stitching logic used in personalization and first-party activation. That creates a broader governance pattern: the same core identifier can support lawful deletion, but only if the system can reconcile fragmented records without over-deleting or under-deleting. Privacy management platform capabilities become relevant here because the problem is not just policy compliance, it is cross-system identity correlation at scale. Practitioners should evaluate whether their privacy stack can unify person identity consistently enough to enforce rights requests end to end.

DROP turns the data broker stack into an infrastructure accountability test. The article makes clear that compliance success depends on engineering decisions about data flows, system coverage, and automation boundaries. That is why the operational owner matters: if engineering cannot execute and prove the workflow, legal cannot rescue it after the fact. Practitioners should assign ownership to the team that controls the data paths, not the team that merely tracks the deadline.

What this signals

Identity resolution is becoming a compliance control, not a marketing capability. When deletion rights depend on reassembling the same person across many disconnected records, governance shifts from request tracking to identity assurance. That means privacy programmes need engineering-grade controls around matching logic, identity persistence, and evidence capture, not just policy language.

DROP-style enforcement will expose weak operating models quickly. A 45-day cycle leaves little room for manual remediation, especially when request volume is already accelerating. The programmes that cope will be the ones that treat rights fulfilment as executable infrastructure, with stable identity anchors and automated execution paths rather than human coordination alone.

For practitioners

• Define a person-scoped deletion workflow Map every incoming DROP request to a single resolved person record before any downstream deletion starts, then use that resolved identity to drive all system-level actions.
• Automate cross-system erasure and proof Replace spreadsheet-driven follow-up with an executable workflow that deletes data in every configured system and emits the report-back evidence automatically.
• Assign ownership to data platform teams Move DROP execution out of legal queue management and into the engineering group responsible for the data stack, system connectors, and audit trail generation.
• Preserve a stable core identifier Store the resolved person key so future 45-day cycles reuse the same identity anchor instead of treating each file as a new matching exercise.

Key takeaways

• DROP converts consumer deletion into an identity resolution problem because the same person can appear in multiple hashed list types with no shared identifier.
• The article ties the operational pressure to scale, with 566 registered data brokers, more than 300,000 requests, and a $200 per request per day penalty.
• The practical fix is to automate person-scoped deletion, preserve a stable core identifier, and generate report-back evidence from the workflow itself.

Related NHI Mgmt Group resources: DSAR Guide: Handling Data Subject Requests · Privacy Management Platform Buyer's Guide · Compliance Automation Guide · GRC Platform Buyer's Guide

Key terms

• Identity Resolution: Identity resolution is the correlation step that determines whether multiple accounts belong to the same person or accountable role. It combines identifiers, context, and system-specific attributes to reduce false splits and missed matches, which is what makes governance outputs dependable rather than approximate.
• Person-Scoped Deletion: Person-scoped deletion is the practice of linking a regulatory request to one resolved individual before erasing data anywhere in the environment. It ensures the workflow acts on the full identity footprint, not on isolated records or partially matched system entries.
• Report-Back Evidence: Report-back evidence is the proof an organisation returns after completing a consumer request or regulatory workflow. It should be generated by the system that performed the work, so the evidence reflects actual execution rather than a manually assembled after-action record.
• Core Identifier: A core identifier is the stable internal key used to anchor a person’s resolved identity across multiple systems and future cycles. In privacy automation, it prevents repeated re-derivation of the same subject and helps keep matching, execution, and reporting aligned over time.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is a useful foundation for practitioners who need to connect identity governance to operational control across programmes.