How CRM teams should operationalize California's expanded deletion rights (SB 923): a short checklist for sales & customer‑success

A practical guide to keeping your pipeline clean, your forecasts intact, and your deletion workflows audit-ready before January 1, 2027

Most CRM admins I talk to about SB 923 start in the wrong place. They ask about the webform requirement — "do we need to build an online intake channel?" — and then stop thinking about it. The webform is the easy part. Everything that happens after someone clicks submit is where things get complicated, especially once you realize this law reaches into data you didn't collect directly.

Below is what actually changes for revenue teams, and a checklist you can run through before the deadline.

What SB 923 actually changes (the short version)

California's Governor signed SB 923 on September 27, 2026. The law closes a gap in the CCPA that a lot of companies had quietly been relying on. Previously, when a consumer asked you to delete their data, there was real ambiguity around personal information you'd purchased or received from a third party — enrichment vendors, data brokers, list providers, that whole category.

SB 923 removes that wiggle room. According to the official CalPrivacy announcement, businesses now have to honor deletion requests for personal information obtained from third parties, not just data the customer handed you directly. It also requires online-only businesses to offer an online submission method for these requests. The law takes effect January 1, 2027.

A Venable legal summary on the bill notes this is part of a broader tightening of California privacy rules — but for CRM teams, the third-party data piece is the one that quietly breaks things.

That's why this isn't a legal-team-only problem.

The real problem: your CRM doesn't know where its data came from

Walk into a typical B2B sales org and look at a single contact record. You'll see fields like:

Email and name (probably collected directly)
Job title and company size (often enriched)
Phone number (could be either)
Technographic data, intent signals, firmographics (almost always third-party)
LinkedIn URL, headcount, funding stage (enrichment)

Now ask: which of these fields came from a third party?

In most CRMs, nobody can actually answer that. The data got merged into the record months ago through an enrichment tool, a bulk list import, or a data-append job, and the provenance disappeared the moment it landed.

That's the core issue SB 923 exposes. The law assumes you can distinguish third-party data from directly-collected data. Most CRM instances can't. You can't honor a request to delete third-party-sourced information if there's no tag telling you which fields those are.

In practice, this surfaces fast once real deletion requests start coming in. A consumer submits a request, the admin pulls the record, and the only honest answer is "delete the whole contact" — which may be more than the law actually requires and absolutely wrecks downstream reporting if that contact is tied to an open opportunity.

Where deletion requests quietly damage revenue operations

Deleting a contact sounds clean. It isn't. Here's what happens when a record disappears across a typical revenue stack:

What gets deleted	Downstream effect	Who feels it
Primary contact on open deal	Opportunity loses its buyer, routing rules break	Sales rep, forecast
Contact tied to historical closed-won	ARR attribution and cohort reports shift	RevOps, finance
Enrichment fields only	Segmentation filters silently stop matching	Marketing, SDR targeting
Contact in active nurture	Automation errors, sequences throw exceptions	Customer success, ops
Account's only known stakeholder	Renewal owner loses all context	CSM

Deletion gets treated as a database event when it's really a workflow event. A single deletion can touch your pipeline, your attribution, your automations, and your renewal coverage all at once. If your only plan is "we'll delete the row when asked," the first quarter of 2027 is going to be rough.

This is also where solid data hygiene habits pay off. The groundwork — field standardization, knowing what each field is for, keeping records clean — overlaps heavily with the practices in our CRM data-hygiene playbook for SMB sales teams. If you already run tight hygiene, SB 923 is an extension of that work. If you don't, this law is going to force the issue.

The suppression list problem nobody talks about

When you delete someone's data, you still need to remember not to re-add them. Otherwise your next enrichment job or list import pulls their third-party data right back into the CRM, and now you've re-ingested data the person asked you to remove.

The standard answer is a suppression list — a record of "do not re-enrich, do not re-import" identifiers. But this creates a genuinely awkward tension: to suppress someone, you have to keep some identifier about them. Most privacy frameworks allow this when it's narrowly scoped to compliance. The mistake teams make is building a bloated suppression list that itself becomes a privacy liability.

A cleaner approach:

Store only a hashed identifier (email hash) on the suppression list, not the full record.
Tag the suppression entry with the deletion-request date and source for your audit trail.
Run every enrichment and import job against the suppression list before writing to the CRM.
Never let the suppression list feed segmentation, scoring, or outreach — it's quarantine, not a dataset.

The key operational point: suppression is a gate at the point of ingestion, not a cleanup job you run later. If you only check at cleanup time, data leaks into your workflows between runs.

Prefer storing only a salted email hash and minimal metadata to limit the suppression list's long-term privacy exposure.

The key operational point: suppression is a gate at the point of ingestion, not a cleanup job you run later. If you only check at cleanup time, data leaks into your workflows between runs.

Reversible deletion: why "delete now, ask questions later" burns you

Hard-deleting records immediately on request feels compliant, but it leaves you with no way to verify you did it correctly, no audit trail, and no recovery if the request turns out to be fraudulent or mistaken.

Phase 1 (immediate)
Suppress the record. Remove it from all active views, automations, segmentation, and outreach. Strip or mask third-party fields so they stop influencing anything. The customer's rights are satisfied — the data is out of use.
Phase 2 (after a short verification window)
Complete the permanent deletion of the applicable fields and log the final confirmation to your audit trail.

This gives you a window to confirm the request is legitimate, catch over-deletion before it damages an open deal, and keep a defensible record of what happened and when. Legal gets its audit trail; sales doesn't lose a live opportunity to a misfired request.

Worth noting: teams that have AI-assisted operational platforms managing their CRM workflows tend to handle this transition more cleanly. Not because the software magically solves the compliance question, but because having automated ingestion gates, field-level tagging, and deletion queue tracking built into the workflow means you're not relying on someone remembering to check a spreadsheet. The process runs the same way every time, which is what audit trails actually require.

The diagram above visualizes the two-phase deletion workflow and where the suppression gate and audit trail sit in the process.

A short checklist to get CRM-ready before January 1

Run through this with your RevOps and legal leads. It's operational, not legal advice — your counsel owns the interpretation, you own the execution.

- [ ] Inventory third-party fields. List every field in your CRM that comes from enrichment, appends, or purchased lists. Tag them at the schema level so provenance is visible on the record.
- [ ] Add provenance tagging going forward. Every new enrichment job should stamp its source and date onto the fields it writes.
- [ ] Build the intake webform and route submissions to a single owner or queue with an SLA clock, not a shared inbox.
- [ ] Define your deletion SLA. Decide the internal turnaround (well inside the legal window) and who's accountable at each step.
- [ ] Stand up the suppression list as an ingestion gate, hashed and scoped.
- [ ] Implement two-phase deletion so requests are reversible during a short verification window.
- [ ] Audit your automations for records that could vanish mid-sequence. Add graceful handling so a deleted contact doesn't throw errors across active flows.
- [ ] Protect reporting integrity. Decide how deleted contacts are handled in attribution and ARR reporting so a wave of deletions doesn't silently distort your dashboards.
- [ ] Write the account-owner playbook. When a deletion hits an open deal or active account, the rep and CSM need a defined next step.
- [ ] Review enrichment vendor contracts so your downstream deletion obligations are reflected upstream.

Getting through that list before January isn't a sprint — it's more like six to eight weeks of steady work if you're starting from scratch on provenance tagging. Start earlier than you think you need to.

A realistic scenario

Picture a mid-market B2B SaaS company — roughly 40 people, selling into California among other states. Their CRM holds around 60k contacts, and maybe 70% of those records carry at least one enriched field from two different data vendors.

Before SB 923, their deletion process was "legal forwards the email, an admin deletes the row." Fine when it happened a couple of times a quarter. The problem: once the law takes effect and they publish the required webform, request volume realistically climbs. Companies with public webforms tend to see steady request traffic, not the occasional one-off.

Their first fix wasn't technology — it was mapping. They spent about two weeks tagging which fields came from which vendor. That alone revealed roughly a third of their "verified" phone numbers were third-party and had never been confirmed. That was a data-quality win that had nothing to do with privacy compliance.

Then they moved to the two-phase model with a suppression gate. The measurable change wasn't dramatic in revenue terms; it was in stability. Deletion requests stopped breaking active sequences, open deals stopped losing their contacts unexpectedly, and the audit trail meant legal stopped pinging RevOps for proof every time a request came through. The whole thing shifted from a fire drill to a routine queue with an SLA.

When to go light vs. when to build the full workflow

Not every team needs the complete machinery on day one.

Keep it lightweight if: you have low California exposure, enrichment is a small part of your data, and request volume is genuinely rare. A tagged-field inventory, a webform, and a documented manual process may be enough — just make sure it's actually documented and someone owns the SLA.

Build the full workflow if: California is a meaningful customer base, you enrich heavily, you run many active automations, or deleted contacts can land on open pipeline. The cost of a broken forecast or a missed deletion SLA climbs fast once volume is real.

Who should not improvise this: anyone whose CRM has no field-level provenance and no clear record owner. If you can't currently answer "where did this field come from," solve that before touching deletion workflows. Guessing is exactly what this law penalizes.

The thing to remember

SB 923 isn't really a privacy project dropped on your legal team. It's a data-quality and workflow problem that lands squarely on CRM and RevOps, because you're the only people who actually know how the data moves. The webform is a half-day of work. Knowing where every field came from, deleting without breaking your pipeline, and proving you did it correctly — that's the real work, and it's work that makes your CRM cleaner regardless of the law.

Start with the inventory. Everything else depends on knowing what you have and where it came from. Get that right before January and the deadline becomes a formality instead of a scramble.