You've probably heard that California's SB 923 expands deletion rights. What you might not know is how many data governance teams are misinterpreting what "all personal information collected about a consumer no matter the source" actually means.
These misunderstandings persist because the Expanding Privacy Rights Act uses deceptively simple language to describe a complex technical requirement. When the California Privacy Protection Agency announced the bill's passage, the phrase "no matter the source" led to many incorrect assumptions about what deletion now covers. Most of those assumptions are wrong, and the gap between myth and reality will define your compliance posture when this bill reaches the Governor's desk.
Myth 1: "We only need to delete data we directly collected from the consumer"
Reality: The bill explicitly closes this loophole. The phrase "no matter the source of the information" means you can't exempt purchased lists, data broker feeds, or third-party enrichment data from deletion requests.
Consider a team that maintains customer profiles enriched with demographic data from a data broker. Under current CCPA, you might argue that deletion only applies to information the consumer provided directly. SB 923 eliminates that distinction. If the personal information is about the consumer, it's subject to deletion regardless of whether they typed it into your webform, you bought it from Experian, or you inferred it from their browsing behavior.
The technical challenge here isn't philosophical. You need an inventory that tracks not just what data you hold, but where it came from. Your deletion workflow can't stop at "data the consumer submitted." It must reach into every system that holds personal information about that consumer, including CRM enrichment fields, analytics platforms fed by third-party identifiers, and marketing automation tools that append demographic segments.
Myth 2: "User-friendly webforms are just a UX improvement"
Reality: The requirement for user-friendly webforms is a compliance mandate with technical teeth, not a suggestion to make your privacy center prettier.
The bill requires businesses to offer user-friendly webforms for rights requests. This isn't about aesthetics. It's about reducing friction that discourages consumers from exercising their rights. If your current process requires consumers to email a privacy inbox, wait for a verification email, click a link, then fill out a PDF, you're not compliant.
What does "user-friendly" mean in practice? Your webform should:
- Accept the request without requiring account login (though you can verify identity afterward)
- Process the request without making the consumer explain which systems might hold their data
- Provide confirmation and timeline expectations immediately
- Work on mobile devices without requiring horizontal scrolling or pinch-to-zoom
The California Privacy Protection Agency has signaled through this bill that accessibility of rights mechanisms matters as much as the rights themselves. Your webform is now a compliance control, not a customer service channel.
Myth 3: "We can handle this with our existing DSAR workflow"
Reality: Expanding the scope to "all personal information" means your current Data Subject Access Request workflow probably can't scale to the new deletion obligations.
Most DSAR workflows are built around structured data in known systems. You query the CRM, the email platform, the support ticketing system, maybe the data warehouse. You're done in a few hours.
But "all personal information collected about a consumer no matter the source" includes:
- Hashed Email Identifiers in your advertising platforms
- Behavioral segments stored in your Tag Manager
- Predictive scores calculated by your analytics engine
- Notes in your sales team's spreadsheets
- Cached data in your CDN logs
- Mobile Advertising IDs collected through your app
Each of these requires different technical access, different deletion APIs, and different verification that deletion actually happened. Your workflow needs to account for systems that don't have a "delete user" button, data stores you don't directly control, and third parties who need to receive deletion instructions.
Myth 4: "Deletion means we delete the record entirely"
Reality: You can retain certain information for specific legal purposes, but you need documented justification for every exception.
Deletion doesn't mean destroying all evidence that the consumer ever existed. You can retain information necessary to:
- Comply with legal obligations (tax records, warranty claims)
- Complete transactions the consumer requested
- Detect security incidents and protect against fraud
- Exercise or defend legal claims
The mistake is assuming these exceptions are broad enough to cover "we need this for business intelligence" or "we might want to market to them later." They're not. Each exception requires a specific Legal Basis for Processing that survives the deletion request.
Your deletion workflow should flag records for retention review, document the legal basis for keeping them, and actually delete everything that doesn't qualify for an exception. Soft-deleting by setting a flag while keeping the data accessible to your analytics platform won't satisfy the requirement.
Myth 5: "This only affects California consumers"
Reality: If you can't reliably identify which consumers are California residents before they submit a deletion request, you'll need to apply these standards to everyone.
The technical reality of consumer data is that you often don't know someone's residency until they tell you. Your analytics platform doesn't store "is_california_resident" flags. Your advertising identifiers don't come with state boundaries attached.
Most organizations will choose one of two paths:
- Build geolocation detection into every data collection point and maintain residency flags across all systems (expensive, error-prone)
- Apply California's deletion standards to all U.S. consumers (simpler, more defensible)
The second path is becoming standard practice. When you can't reliably segment your compliance obligations by state, you comply with the strictest standard everywhere.
What to do instead
Start by mapping every source of personal information in your organization, not just the databases you control directly. Include purchased data, inferred attributes, and third-party identifiers. Document which systems can execute deletions via API, which require manual intervention, and which need vendor coordination.
Build your webform as a compliance control. Test it on mobile. Time how long it takes a consumer to submit a request. Remove every step that doesn't serve verification or fraud prevention.
Review your retention policies against the specific exceptions in the bill. If you're keeping data "just in case," you're keeping it illegally. Document the legal basis for every retention decision.
And recognize that SB 923 represents where privacy law is heading, not an isolated California experiment. The gap between "data we collected" and "all personal information about the consumer" is closing across jurisdictions. Your deletion workflow needs to close that gap before the Governor signs this bill.
