Skip to main content
DROP Compliance: Your Data Broker ChecklistPrivacy Regulations
5 min readFor Legal and Compliance Teams

DROP Compliance: Your Data Broker Checklist

California's Delete Request and Opt-Out Platform (DROP) went live on January 1, 2026, with over 215,000 registrants and more than 500 registered data brokers. If your organization operates as a data broker in California, you're now subject to new operational requirements beyond registration. This checklist guides you through the steps to maintain DROP compliance.

What This Checklist Covers

This checklist covers DROP platform integration, consumer request fulfillment, and the technical controls required under California's Delete Act. It assumes you've already registered as a data broker with CalPrivacy. If not, complete registration before proceeding.

Prerequisites

Before you start:

  • Confirmed data broker status: Ensure your organization meets California's definition of a data broker (selling or licensing consumer personal information not collected directly from those consumers).
  • Active DROP registration: Register with CalPrivacy and receive your data broker identification number.
  • Technical contact designated: Assign a technical owner to implement API integrations and manage webhook endpoints.
  • Legal review completed: Have your legal team review your data retention and deletion procedures against the California Consumer Privacy Act and California Privacy Rights Act requirements.

Checklist Items

1. Configure DROP API authentication

Set up OAuth 2.0 credentials for the DROP API and test authentication in the sandbox environment before moving to production.

Good looks like: Your system successfully authenticates, retrieves a valid access token, and can make test API calls without errors. Document token refresh procedures and assign backup technical contacts.

2. Implement deletion request webhook endpoint

Build a webhook listener that receives deletion requests from DROP in real time. The endpoint must accept POST requests, validate the signature, and return a 200 status code within 30 seconds.

Good looks like: Your endpoint processes requests without timeouts, logs each request with a unique identifier, and triggers your internal deletion workflow within one business day.

3. Map DROP request fields to internal data identifiers

Create a mapping document that translates DROP's consumer identifiers (email, phone, name variations) to your internal customer or data subject IDs across all systems where you store consumer data.

Good looks like: You can trace a DROP deletion request through every database, data warehouse, backup system, and third-party integration where the consumer's data might exist. Include edge cases like merged records and historical data.

4. Build deletion confirmation response mechanism

Implement the API call that confirms deletion completion back to DROP. This must include the request ID, completion timestamp, and scope of deletion.

Good looks like: Your system automatically sends confirmation within 45 days of receiving the request, includes specific details about what was deleted, and logs the confirmation for audit purposes.

5. Update Data Sanitization procedures for DROP requests

Revise your Data Purging procedures to distinguish between DROP requests (requiring deletion across all systems) and standard CCPA deletion requests (which may have different scope).

Good looks like: Your procedure specifies which systems must be checked, defines acceptable retention periods for technical logs, and includes verification steps to confirm deletion completeness.

6. Establish opt-out signal processing

Configure your systems to receive and honor opt-out preference signals from DROP. This applies to both sale/sharing opt-outs and sensitive personal information processing opt-outs.

Good looks like: When a consumer sets an opt-out preference through DROP, your systems stop selling or sharing their data within the timeframe required by CPRA (typically within 15 business days). Maintain an audit log of when preferences were received and applied.

7. Create DROP request tracking dashboard

Build internal reporting that shows DROP request volume, processing times, completion rates, and any failures or errors.

Good looks like: Your Chief Privacy Officer can view real-time metrics on DROP compliance, identify processing bottlenecks, and generate reports for board or regulatory inquiries. Track average fulfillment time and demonstrate improvement over time.

8. Document third-party data broker relationships

Inventory all data brokers you purchase data from and confirm whether they're DROP-registered. Document how you'll handle deletion requests for data you obtained from them.

Good looks like: Maintain a current list of data sources, their DROP registration status, and your contractual obligations regarding Data Purging. Test the process of requesting deletion from upstream brokers when you receive a DROP request.

9. Test DROP integration end-to-end

Run test deletion and opt-out requests through your complete workflow, from DROP receipt through final confirmation, using non-production data.

Good looks like: Document test results, identify and fix integration issues, and demonstrate successful request processing to auditors. Test failure scenarios (system downtime, API timeouts) and confirm your error handling works correctly.

10. Train operations team on DROP procedures

Provide specific training to the team that handles consumer requests, covering DROP-specific requirements and how they differ from direct consumer requests.

Good looks like: Team members can explain DROP request processing, know where to find technical documentation, and understand escalation procedures when issues arise. Document this training and show completion records.

Common Mistakes

Treating DROP requests like standard DSAR workflows: DROP requests often require broader deletion across data broker networks. Don't assume your existing Data Subject Access Request process is sufficient.

Failing to verify deletion in backup systems: Deletion must extend to backups and archives unless you can demonstrate they're technically isolated and will never be restored to production. Document your backup retention period and restoration controls.

Ignoring upstream data sources: If you bought consumer data from another broker, you may need to request deletion from them as well. Your contracts should address this scenario.

Missing the automated decision-making connection: CalPrivacy is implementing regulations for automated decision-making alongside DROP. If you use consumer data from DROP-registered sources in automated decisions, document your Rights Related to Automated Decision-Making procedures now.

Next Steps

After completing this checklist:

  • Schedule quarterly DROP integration reviews to catch processing failures early.
  • Monitor CalPrivacy's regulatory updates, particularly the forthcoming cybersecurity audit requirements and risk assessment regulations.
  • Document your DROP compliance procedures for your next cybersecurity audit.
  • Review your data broker vendor contracts to ensure they include DROP compliance obligations.

CalPrivacy has been operational for six years, and under executive director Tom Kemp's leadership since April 2025, enforcement priorities are becoming clearer. DROP isn't just another registry; it's an operational system that requires technical integration and ongoing maintenance. Complete this checklist now, before you're responding to a compliance inquiry.

You Might Also Like