Overview
DataGrail's Data Broker Compliance product helps registered data brokers meet their obligations under the California Delete Act (SB 362), which requires data brokers to process consumer deletion requests submitted through the California Privacy Protection Agency (CalPrivacy) centralized deletion registry.
What is the California Delete Act?
The California Delete Act (SB 362) went into effect on January 1, 2026. It gives California consumers a single place to request deletion from all registered data brokers at once — rather than submitting individual requests to each company.
Every business registered as a data broker with CalPrivacy is required to:
- Monitor the DROP registry for new deletion requests on an ongoing basis
- Process deletion requests against all data held on the requesting consumer
- Confirm deletion back to the registry within 45 days of the request
- Repeat this process at least once every 45 days to catch new requests
Under California law, a data broker is a business that knowingly collects and sells or shares the personal information of consumers with whom it does not have a direct relationship. If your organization is registered with CalPrivacy's data broker registry, DROP Compliance applies to you. To verify your registration status, visit the CalPrivacy Data Broker Registry.
Learn more about the Delete Act
CalPrivacy continues to publish guidance on SB 362 implementation. DataGrail will update this documentation as requirements evolve. For the latest, visit CalPrivacy's official resources.
How DataGrail Helps
DataGrail's Data Broker Compliance product automates the end-to-end workflow required to meet your SB 362 obligations:
| Capability | Description |
|---|---|
| Registry Monitoring | DataGrail continuously polls the DROP registry and ingests new deletion requests on your behalf |
| Identity Matching | DataGrail matches incoming requests to records in your connected systems using hashed identifiers |
| Deletion Orchestration | Matched records are automatically routed for deletion across your in-scope systems; each deletion is created as a DROP request type visible and processable in the Request Manager queue |
| Confirmation Reporting | DataGrail submits deletion confirmations back to the registry and maintains an audit trail |
System Architecture
The diagram below shows how your systems, DataGrail, and the DROP registry interact end-to-end.
The Deletion Request Lifecycle
When a consumer submits a deletion request through the DROP registry, DataGrail automates the full processing workflow — from ingestion through to registry confirmation.
Registry Ingestion
DataGrail continuously monitors the DROP registry on your behalf. When a new consumer deletion request is available, DataGrail automatically ingests it — no manual action required from your team.
Each ingested request includes the consumer's hashed identifiers (such as a hashed email address or phone number). Identifiers are hashed by CalPrivacy before they are made available to data brokers, which means DataGrail and your organization never receive a consumer's raw personal information through this channel.
Hashing is a one-way process that converts personal information (like an email address) into a fixed string of characters. The original value cannot be reconstructed from the hash. This protects consumer privacy while still allowing DataGrail to check whether a match exists in your systems. See Hashed Identifier Matching for a plain-language explanation.
Identity Matching
DataGrail downloads the DROP registry deletion lists and compares them against the hashed identifiers your systems have ingested into DataGrail.
There are three possible match outcomes:
| Outcome | Description |
|---|---|
| Confirmed Match | A hashed identifier from the request matches a record in one or more of your connected systems. DataGrail proceeds to deletion. |
| No Match | No hashed identifiers match any records in your connected systems. DataGrail confirms to the registry that no data was found (not_found). |
| Uncertain Match | DataGrail cannot definitively confirm or rule out a match — for example, due to data quality issues or identifier gaps in a system. DataGrail proceeds with deletion to minimize compliance risk. This outcome reports as deleted (status code 3) to the registry. |
Deletion Orchestration
For confirmed matches, DataGrail creates a DROP request — a new request type that appears in your Request Manager queue alongside all other privacy requests. Your team can view and process DROP requests directly from the Request Manager queue, giving you a single place to manage all deletion activity across both DSRs and DROP compliance obligations.
DROP requests follow the same processing workflow as other deletion requests in Request Manager. Users with Request Admin or Request Agent roles can view, process, and track DROP requests from the queue without needing to navigate to a separate interface.
Not all of your connected systems may be in scope for Data Broker Compliance. See What Systems Are Covered for guidance on how to determine which systems apply.
Registry Confirmation
Once deletion is complete across all in-scope systems, DataGrail submits a deletion confirmation back to the DROP registry on your behalf. This confirmation closes out the request and satisfies your 45-day reporting obligation.
A full audit trail of each request — including ingestion timestamp, match outcome, deletion status, and confirmation — is available in the Audit Log & Reporting article.
Timing & SLAs
The following table summarizes the key timing milestones for DROP compliance:
| Milestone | Timeline |
|---|---|
| Registry polling frequency | Configured per your DataGrail setup |
| Deletion processing | Dependent on connected system response times |
| Registry confirmation deadline | 45-day deadline from request extraction date (SB 362) |
DataGrail's audit log tracks timestamps at each stage so you can verify compliance with the 45-day window at any time.
What Systems Are Covered
Not every system connected to DataGrail is automatically in scope for Data Broker Compliance. SB 362 applies to data your organization holds on consumers with whom you do not have a direct relationship — meaning data that was acquired, licensed, or inferred rather than collected directly through a customer relationship.
When scoping your systems, consider the following questions for each:
- Does this system contain consumer data? If the system only holds employee, vendor, or partner data, it is likely out of scope.
- Was this data collected directly from the consumer? Systems where consumers actively provided their own data (e.g., a first-party CRM) may be out of scope depending on your business model.
- Does this system hold data acquired from third parties? Data purchased, licensed, or received from data partners is the primary target of SB 362 and should be treated as in scope.
If you are unsure whether a system is in scope, err on the side of including it. Over-inclusion is far less risky than missing a system that holds covered data. Work with your legal team to make final scoping decisions.
Common system types that are typically in scope:
- Data enrichment and intelligence platforms
- Purchased or licensed consumer data stores
- Audience and identity graph systems
- Marketing data warehouses populated by third-party sources
Common system types that are typically out of scope:
- First-party CRM systems (e.g., direct customer records)
- HR and employee management systems
- Internal analytics tools with no consumer PII
Once you have identified your in-scope systems, work with your engineering team to connect them in DataGrail. See the Quickstart to get started.
Hashed Identifier Matching
When a consumer submits a deletion request through the DROP registry, DataGrail receives a set of hashed identifiers — not raw personal information. A hashed identifier is a fixed-length string generated by running a piece of personal information (such as an email address) through a one-way mathematical function called a hash.
Example: The email address jane.doe@example.com might produce a hash like vGM7y5n+hBXRSEAklhHDPCbysyNgYTmXdMcagGUOY8E= — a 44-character Base64-encoded SHA-256 value. The original email cannot be reconstructed from this string.
DataGrail matches incoming hashed identifiers against hashed versions of identifiers stored in your connected systems. For a match to occur, both sides must use the same hashing algorithm (SHA-256) and the same input format (e.g., lowercase, trimmed).
This means your systems need to be able to produce hashed versions of the identifiers they store so DataGrail can compare them. Your engineering team will configure this as part of Identifier Configuration.
CalPrivacy hashes consumer identifiers before making requests available to data brokers. DataGrail receives only hashed values from the registry — your organization's raw consumer data never leaves your systems.
Next Steps
New to Data Broker Compliance? Here's where to begin:
- Quickstart — end-to-end implementation guide covering setup, ingestion, and go-live
- Ingestion Format — how to deliver your consumer identifiers to DataGrail
Disclaimer: The information contained in this message does not constitute as legal advice. We would advise seeking professional counsel before acting on or interpreting any material.