Skip to main content
Promotional banner ad for the Penetration Testing Report Kit
California's Delete-on-Demand Law: What Changes When You Don't Control the DataData Privacy
5 min readFor Data Privacy Officers

California's Delete-on-Demand Law: What Changes When You Don't Control the Data

The Challenge

Starting January 1, 2027, California businesses must comply with a new requirement that shifts traditional data governance: honoring deletion requests for personal data they didn't collect themselves. SB 923, signed by Governor Gavin Newsom, removes the "original collector" limitation from the California Consumer Privacy Act. Previously, you could decline a deletion request if you hadn't collected the data directly. Now, if you hold personal data about a California resident, you're responsible for deleting it on request, no matter how it entered your systems.

This isn't about tweaking an existing control; it's about redesigning your data lifecycle management around a new accountability model: possession equals obligation.

The Environment and Constraints

The two-year implementation window reflects the complexity businesses face. Most data governance programs focus on collection points. Your Data Subject Access Request workflows trace data back to intake forms, account creation events, or API endpoints where the consumer interacted with you directly.

Third-party data complicates this model. Consider what you hold:

  • Lead lists from data brokers
  • Enrichment data from marketing platforms
  • Consumer profiles from acquisitions
  • Behavioral data from third-party scripts
  • Information from data partnerships

Your existing CCPA compliance framework likely documents these sources in your privacy notice. But your deletion procedures probably assume you can verify the consumer's relationship with you before acting. SB 923 removes that verification step as a basis for refusal.

The constraint isn't just technical; it's legal and operational. You need systems that can locate and delete data without relying on "we collected this from you on [date]" as a search parameter. You need verification methods that work when the consumer never created an account with you. And you need policies to handle deletion requests that conflict with other legal obligations, like financial record retention or fraud prevention.

The Approach Taken

California's approach prioritizes consumer control over data lifecycle efficiency. The law recognizes that modern data ecosystems are too complex for consumers to chase down every entity holding their information. By shifting the burden to businesses, it forces a reckoning with data inventory practices.

The practical response requires three parallel workstreams:

Data Mapping Beyond Collection Points. You need to know what personal data you hold, organized by data subject rather than by source system. This means tagging or indexing data to support deletion requests from individuals who never directly interacted with you. If your current data map shows "Marketing Database: 2.3M records from lead gen campaigns," you need to restructure it to answer "What do we hold about [specific California resident]?"

Identity Verification Without Prior Relationship. When someone requests deletion and you have no account record, how do you verify they're the person whose data you hold? Your verification process needs to balance two risks: deleting the wrong person's data (privacy violation) and refusing a legitimate request (CCPA violation). Consider verification methods that don't require proving a prior transaction: government ID verification, knowledge-based authentication using publicly available information, or third-party identity verification services.

Exception Documentation That Scales. CCPA allows businesses to retain data when deletion would prevent them from completing a transaction, detecting security incidents, complying with legal obligations, or exercising free speech rights. But these exceptions require documentation. When you receive 500 deletion requests in a month and 80 trigger retention exceptions, you need a system that logs the legal basis for each decision, not a spreadsheet maintained by a privacy analyst.

Results and Metrics

The law takes effect January 1, 2027, so measurable outcomes don't yet exist. But the compliance deadline tells you when your systems need to be operational, not when you should start building them.

The two-year window is less generous than it appears. If you're planning a data governance overhaul, you need executive approval, budget allocation, vendor selection, system integration, testing, and staff training. Organizations that start in 2026 will be implementing under pressure.

The California Privacy Protection Agency will enforce SB 923 using the same framework it applies to existing CCPA requirements. That means potential administrative fines, mandatory corrective action plans, and public reporting of violations. The agency hasn't published specific guidance on SB 923 yet, but its enforcement history shows it focuses on systemic failures, not isolated mistakes.

Building a Compliance Program

California didn't publish a compliance playbook with SB 923. The legislative text expands the deletion mandate without prescribing implementation methods. That puts the design burden on businesses.

If you're building a compliance program from scratch today, start with data inventory, not deletion workflows. You can't delete what you can't find. And if your data map shows "various third-party sources" as a category, you don't have enough detail to comply.

Second, integrate deletion capabilities into your data acquisition process. When you purchase a lead list, append enrichment data, or ingest information through a partnership, your contract should specify how you'll handle deletion requests. If your vendor can't tell you which California residents are in the dataset, you're inheriting a compliance liability.

Third, don't treat this as a California-only problem. If you operate nationally, you're likely holding data about residents in states that are considering similar laws. Building a system that only handles California requests means rebuilding when Colorado, Virginia, or Connecticut adopt comparable requirements. Design for portability.

Takeaways for Your Team

SB 923 exposes a gap between how privacy laws are written and how data actually moves through business systems. The original CCPA assumed a clear line between data collectors and data processors. That line has blurred.

Your compliance program needs to answer three questions before January 2027:

Can you locate personal data about a California resident if they never created an account with you? If your search function requires an email address or customer ID, you can't comply. You need a data architecture that supports fuzzy matching: name, address, phone number, or other identifiers that don't require a prior relationship.

Do you know which data you're legally required to retain even when a consumer requests deletion? Financial institutions have record retention obligations under the Gramm-Leach-Bliley Act. Healthcare entities have requirements under the Health Insurance Portability and Accountability Act. Your deletion workflow needs to check these obligations automatically, not rely on manual review.

Can you document why you refused a deletion request? CCPA gives you valid reasons to retain data, but you need to log the specific reason for each decision. When the California Privacy Protection Agency audits your program, "we thought we needed it" isn't documentation. "Retained under CCPA §1798.105(d)(2) for fraud detection based on [specific risk indicator]" is.

The 2027 deadline isn't a suggestion. Start your data inventory now, map your third-party data sources, and build deletion workflows that don't assume you collected the data yourself. California just made data possession a compliance event, not just data collection.

Promotional banner for the Penetration Report Template Kit

You Might Also Like