California SB 923 raises the bar for DSAR workflows

At a glance

What this is: Osano outlines how California SB 923 expands CCPA deletion rights and online request obligations, making subject rights management broader and more operationally demanding.

Why it matters: This matters because privacy requests now touch more data sources, more workflow steps, and more verification and retention controls than many point solutions can handle cleanly.

Context

California’s latest privacy amendment widens both the intake path and the deletion scope for subject rights requests. That changes the governance problem from receiving a request to proving the request was verified, routed, fulfilled, recorded, and closed across every system that holds personal data.

For IAM and privacy teams, the key issue is not just a consumer form. It is identity verification, jurisdiction-aware handling, suppression records, and downstream system coordination. Where request intake touches customer data, the control surface starts to resemble an identity and access workflow, not a simple web task.

Key questions

Q: What breaks when DSAR requests are handled with a CMS form?

A: A CMS form often routes requests into marketing or CRM workflows first, which can create new contact records, miss non-CMS data stores, and weaken deletion evidence. The failure is not just user experience. It is that privacy handling becomes coupled to systems designed for lead capture, not regulated request fulfillment.

Q: Why do subject rights workflows need identity verification rules?

A: Because different request types create different risk levels, and some laws restrict verification for simple opt-outs. Verification has to be strong enough to prevent unauthorised disclosure or deletion, but not so blunt that it violates request handling rules. The right model is policy-based verification tied to request category and jurisdiction.

Q: How can organisations prove deletion actually reached all systems?

A: They need data mapping, owner assignment, and completion logging across internal platforms and vendors. A deletion is only credible when the request can be traced through every relevant store, including third parties and replicated datasets. Without that traceability, the organisation can claim completion without proving it.

Q: What is the difference between a privacy request form and DSAR management?

A: A form only collects a request. DSAR management governs intake, verification, routing, execution, deadlines, suppression handling, and evidence retention. The difference is operational control. A form can submit work, but DSAR management proves that the work was completed correctly and consistently across systems.

Technical breakdown

Why DSAR intake breaks when it is treated as a web form

A subject rights request is a governed workflow, not a static input field. It must classify the request type, map the requester to the right jurisdiction, verify identity when required, and preserve evidence of what happened next. A generic CMS form often writes into marketing or CRM objects first, which can reintroduce the very data the requester asked to suppress. Once the request reaches multiple systems, the real challenge becomes orchestration and auditability across owners, not page design.

Practical implication: route DSAR intake through a dedicated workflow that separates privacy requests from marketing capture and preserves a complete audit trail.

Why deletion scope now reaches data brokers, vendors, and inferred data

California’s amended deletion right extends beyond data directly collected from a person to data collected from or about them. That matters because modern data estates include brokered data, vendor-fed records, inferred attributes, and replicated datasets that live outside the original collection point. In practice, deletion has to traverse internal stores, outsourced services, and contractual processors. A record of the request can remain, but only to the extent needed to prevent repopulating the requester’s data and to prove compliance.

Practical implication: inventory every downstream store that can repopulate consumer records and tie deletion handling to those dependencies.

How verification, deadlines, and retention turn compliance into a control system

Subject rights operations combine identity proofing, response deadlines, and evidence retention. The CCPA distinguishes request types and prevents unnecessary verification for some opt-outs, which means the workflow must apply policy by request category rather than uniformly. It must also track deadlines, extensions, and retention periods, because a short-lived operational task can become a regulatory failure if the evidence disappears too soon. This is where privacy requests intersect with identity governance and records management in a very practical way.

Practical implication: enforce policy-based verification, automated due dates, and multi-year record retention rather than relying on manual follow-up.

NHI Mgmt Group analysis

SB 923 turns subject rights handling into a governance workflow, not a form project. The article shows that the compliance failure mode is treating privacy requests as a front-end task while the data lives across CRM, warehouse, support, and vendor systems. That creates a lifecycle gap where intake, verification, execution, and evidence are no longer controlled as one process. Practitioners should treat DSAR operations as a governed workflow spanning identity, records, and data handling.

Request verification is now an identity decision, not just a privacy checkbox. When a request can trigger deletion, export, or correction, the organisation has to decide when verification is required, how strong it should be, and how that policy varies by request type. That intersects directly with IAM thinking because the requester’s identity must be trusted enough to trigger data action but not over-verified where the law forbids it. Practitioners should align privacy intake with identity assurance policy rather than ad hoc manual checks.

Deletion without downstream reach is governance theatre. If a team only updates the system that captured the request, it has not fulfilled the deletion obligation where data brokers, processors, and replicated stores are involved. The article’s strongest operational signal is that privacy compliance now depends on data mapping and controlled handoffs, not a single system feature. Practitioners should focus on deletion propagation across the full data estate.

Osano’s example reflects a broader market shift toward privacy operations with evidence retention built in. Once laws shorten the time between request and required action, organisations need workflow, logging, and retention that survive audit scrutiny. This is especially relevant where privacy requests intersect with human identity data and account records, because request handling becomes part of the identity lifecycle. Practitioners should expect privacy platforms to behave more like control systems than simple intake tools.

What this signals

Subject rights handling is becoming a lifecycle control, not an intake control. As privacy laws expand deletion scope and request channels, teams need workflows that connect identity assurance, downstream system action, and retained evidence. A standalone web form is no longer enough to demonstrate control.

Data mapping now sits at the centre of privacy operations. If a business cannot see where brokered, inferred, or vendor-supplied data lives, it cannot reliably honour deletion requests. The practical programme response is to tie DSAR handling to data inventory and owner accountability.

Identity privacy and consent controls need to align with the request type, not the tool used to collect it. The challenge is to apply the right verification, retention, and fulfilment rules across a consumer journey that may begin in one system and end in many others.

For practitioners

• Implement a dedicated DSAR workflow Separate privacy requests from marketing forms, CRM contact creation, and support tickets so a deletion request cannot recreate the requester as a new contact.
• Map every downstream data store Inventory internal systems, vendors, brokers, and inferred-data stores that can repopulate consumer records, then attach deletion handling to each owner.
• Policy-enable request verification Apply different verification rules by request type, and disable unnecessary verification where the law bars it for simple opt-outs.
• Automate deadlines and evidence retention Set jurisdiction-aware due dates, preserve request records for the required retention window, and keep an auditable trail of actions taken on each request.

Key takeaways

• California SB 923 widens deletion obligations and makes online request handling mandatory for certain online-only businesses, which raises the operational burden on privacy programmes.
• The main control gap is not form availability but workflow coverage across identity verification, downstream systems, and evidence retention.
• Teams that rely on CMS-native forms or ad hoc automation risk incomplete deletion, weak auditability, and avoidable compliance failure.

Key terms

• Subject Rights Request: A Subject Rights Request is a formal request from an individual to access, correct, erase, restrict, or otherwise control their personal information. In operational terms, it becomes a workflow problem across data discovery, identity matching, records handling, and evidence retention.
• Deletion Propagation: Deletion propagation is the ability to remove personal data from all systems where it exists, including copies, backups, derivatives and downstream indexes. It matters because a deletion request is only effective when the data disappears from every environment that can still use or expose it.
• Identity Verification For Privacy Requests: The process of confirming that a person making a privacy request is entitled to act on the data involved. Organisations typically use multiple reasonable data points, such as phone number, address, or account number, to reduce fraud and prevent unauthorised disclosure. Verification should fit the sensitivity of the request.
• Suppression Record: A suppression record is the minimum retained record of a deletion or opt-out request needed to prevent the requester’s data from being reintroduced later. It is not a customer profile. It is a governed exception record that supports compliance without recreating the original data relationship.

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. It is designed for practitioners who need to connect identity control to broader security and governance programmes.