California's SB 923, effective January 1, 2027, expands CCPA deletion obligations to cover personal data regardless of who originally collected it. This isn't just another compliance checkbox. It's a structural shift that reveals how most privacy programs handle Individual Rights today: reactively, manually, and with risky assumptions about data lineage.
I've watched privacy teams scramble through deletion requests for years. The same mistakes appear across industries, and they're about to get much more costly under the expanded mandate. Here's what goes wrong and how to fix it before 2027.
Why These Mistakes Keep Happening
Most privacy programs were built for notice-and-consent compliance, not operational data management. You documented your processing activities, wrote a privacy policy, and set up a form for Data Subject Requests. That worked when deletion requests were rare and limited to data you directly controlled.
SB 923 changes the playing field. When a California resident asks you to delete their data, you're now responsible for deletion across your entire data ecosystem, including information collected by vendors, partners, or third-party platforms on your behalf. Your privacy team suddenly needs visibility and control over data flows they may not have mapped.
These mistakes aren't about negligence. They're about program design that never anticipated this level of operational complexity.
Mistake 1: Treating Data Processing Registers as Compliance Artifacts
Why it happens: Your Data Processing Register was created for regulatory documentation, not operational data management. It lists high-level processing activities, legal bases, and retention periods. It doesn't map actual data flows, system dependencies, or downstream sharing relationships.
The consequence: When a deletion request arrives, your team can't answer basic questions: Which systems hold this person's data? Who did we share it with? What's the technical process to purge it from each location? You're searching through systems manually, missing data in shadow IT, and blowing past response deadlines.
The fix: Rebuild your Data Processing Register as an operational tool. For each processing activity, document:
- Specific systems and databases where data resides
- API connections and data synchronization points
- Third-party processors with access
- Technical deletion procedures (API calls, manual purges, backup retention)
- Average time required to complete deletion in each system
Test this quarterly. Pick a random data subject, simulate a deletion request, and time how long it actually takes to purge their data completely. If you can't complete it within your stated response window, your register is fiction.
Mistake 2: Assuming Vendors Will Handle Deletion Automatically
Why it happens: Your vendor contracts include standard data processing language. You assume that when you delete a customer record in your CRM, your email platform, analytics tools, and support systems automatically receive and process the deletion.
The consequence: Data persists in vendor systems indefinitely. Under SB 923, you're still liable. When California residents exercise deletion rights, you're responsible for ensuring deletion across processors who collected data on your behalf, even if you lack direct technical control.
The fix: Add deletion mechanics to your Vendor Risk Profile for every processor handling California resident data:
- Does the vendor provide a deletion API or must you submit manual requests?
- What's their documented response time for deletion requests?
- Do they delete from backups, or only from production systems?
- Do they provide deletion confirmation with audit trails?
For critical vendors, negotiate service-level agreements specifying deletion completion within 15 days of your request. For vendors without deletion APIs, establish a manual request process and test it before you need it under deadline pressure.
Mistake 3: Ignoring Data in Backups and Archives
Why it happens: Your production systems have deletion workflows. Your backup systems don't. Most backup solutions weren't designed for granular record deletion, and your retention policies prioritize disaster recovery over Individual Rights.
The consequence: You delete data from production, confirm deletion to the requestor, then restore a backup six months later and resurrect the supposedly deleted information. You've violated both your deletion commitment and the expanded CCPA mandate.
The fix: Document your backup retention schedule and establish a backup deletion policy:
- For backups retained less than 90 days: Accept that data persists until the backup expires, and disclose this timeline in your privacy policy
- For backups retained longer than 90 days: Implement either granular deletion capabilities or a "deletion flag" system that prevents deleted data from being restored to production
- For archives required for legal or regulatory reasons: Document the specific legal basis for retention and communicate this exception clearly when responding to deletion requests
This is expensive and technically complex. That's the point. SB 923 makes comprehensive deletion a regulatory obligation, not a best-effort courtesy.
Mistake 4: Failing to Validate Deletion Across Federated Systems
Why it happens: Your systems are loosely coupled. When you delete a customer record, that deletion propagates through some integrations but not others. You have no systematic way to verify that deletion completed everywhere.
The consequence: Data fragments persist in analytics databases, data warehouses, or reporting systems that receive periodic snapshots but don't process real-time deletion events. You've technically failed to honor the deletion request, and you won't discover the failure until an audit or investigation.
The fix: Build deletion validation into your response workflow:
- Document every system that receives personal data (primary applications, analytics platforms, data warehouses, reporting tools)
- For each system, identify whether deletion propagates automatically or requires manual action
- Create a deletion checklist that your privacy team completes for every request
- Implement technical validation where possible (query each system to confirm the data no longer exists)
- Require sign-off from system owners confirming deletion completion
This turns a 10-minute task into a 2-hour process. That's the actual cost of compliance with expanded deletion rights.
Mistake 5: Using Legal Exceptions as Operational Shortcuts
Why it happens: CCPA includes exceptions for data you must retain for legal, regulatory, or security purposes. Your team interprets these exceptions broadly to avoid the operational complexity of deletion.
The consequence: You're retaining far more data than the exceptions actually permit. When regulators review your deletion practices, they'll find you've applied legal exceptions to data that should have been deleted. The California Privacy Protection Agency will view this as systematic non-compliance, not good-faith interpretation.
The fix: Document the specific legal or regulatory obligation for every retention exception you claim:
- For financial records: Cite the specific statute requiring retention (e.g., Sarbanes-Oxley Act Section 802 for audit documentation)
- For security logs: Document the security purpose and retention period justified by that purpose
- For legal claims: Retain only data directly relevant to the specific claim, not entire customer profiles
When you deny a deletion request based on an exception, provide the specific legal basis in your response. If you can't cite a statute or regulation, you're probably over-retaining.
Prevention Checklist
Use this checklist to audit your current deletion capabilities before SB 923 takes effect:
Data Mapping
- Data Processing Register includes system-level detail, not just activity descriptions
- All third-party processors are documented with deletion procedures
- Data flows between systems are mapped and validated quarterly
Technical Capabilities
- Deletion procedures exist for every system holding personal data
- Backup deletion or flagging process is documented and tested
- Validation process confirms deletion across all systems
Vendor Management
- Vendor Risk Profiles include deletion mechanics for all processors
- Contracts specify deletion timelines and confirmation requirements
- Manual deletion request process exists for vendors without APIs
Documentation and Exceptions
- Legal basis is documented for every retention exception
- Deletion response templates include specific exception citations
- Privacy policy discloses backup retention timelines
Testing and Validation
- Quarterly deletion simulations measure actual completion time
- System owners sign off on deletion completion
- Audit trail captures all deletion requests and outcomes
You have until January 1, 2027 to close these gaps. That sounds like plenty of time until you start mapping actual data flows and discover how many systems you've lost track of. Start with the Data Processing Register. If it can't answer operational questions about deletion, nothing else on this checklist will work.
