California's DROP Processing Starts: Questions to Ask Your Data Vendors

California's DROP processing requirement began on August 1 for covered data brokers. For businesses that depend on outside data, this is a good time to ask how a request moves through the vendors and connected systems they actually use.

The system lets California residents make a single request to covered data brokers to delete information and stop its sale. The practical questions for a business go beyond whether a vendor has heard of DROP. Who assesses applicability? Who handles a request? What happens to information already delivered elsewhere?

Put those questions in writing. Ask for a process your team can understand and evidence appropriate to the vendor's role.

Start with the vendor's role

List the providers that supply, enrich, store or transmit personal information in the workflow you are reviewing. Include the destination systems as well as the original source.

For each provider, ask:

• Which legal entity provides the service we use?
• What is its role in collecting, supplying and handling the information?
• Who has assessed whether DROP requirements apply to that entity and activity?
• What changes, if any, follow from that assessment for our relationship?

Do not assign every supplier the same classification because they all handle data. Get the answer from the party responsible for that assessment, with a date and a named owner.

When you review visitor identification in the OSPRY overview, bring this same role-based question. Understand where the information comes from and what your business is responsible for doing with it.

Ask how requests enter the process

A useful answer identifies an intake route, an owner and a handling record.

Ask how the vendor receives applicable requests, how it distinguishes the kinds of request it handles and how the responsible team knows that work is waiting. Ask what happens when the usual owner is absent or an automated step fails.

For a provider covered by the DROP requirement, ask how its DROP process operates. For a provider with a different role, ask which request process applies to the information it holds.

Keep the answer specific to the service you buy. A company can have a general privacy page while your implementation still needs a clear route for a request or a correction.

Understand matching without collecting more than necessary

Ask how the vendor determines whether a request relates to a record it holds. What happens when the available information matches more than one person, matches nothing or conflicts with an existing record?

A confident “we match requests automatically” leaves important questions unanswered. Ask who reviews exceptions and how an incorrect association can be corrected.

Also ask what information your business must provide, why it is needed and how it should be transmitted. Keep access details and personal identifiers out of ordinary support notes and shared presentation files.

If the vendor describes hashing or another technical protection, ask how that method fits the actual matching and handling process. A technical label should not replace an explanation of the decision being made.

Separate deletion from preventing recreation

Deleting a record and preventing the same information from returning are related operating questions.

Ask which active stores, exports and connected services are covered by the vendor's process. Ask how later imports, enrichment jobs or restored data are checked so an earlier decision is not silently undone.

Where a limited suppression record is necessary and permitted, ask what it contains, why it is retained, who can access it and how it is used. Do not assume that the answer is to keep a complete customer profile under a different name.

The goal is a process that carries the relevant decision forward while handling information appropriately. Consent and data choices belong in that discussion alongside the technical steps.

Map the destinations that already received data

Draw one simple path from source to destination. Name the data provider, the system receiving the record and any later tools that act on it.

For example, a hypothetical workflow might receive a supplied record, place it in a CRM and create a review task for an account owner. A request affecting the source could leave an old CRM copy or an active task behind unless the connected process addresses them.

That example is an operating question, not a claim that every party has the same legal duty. Ask which notifications, restrictions or handling steps apply at each destination and who owns them.

Review the integrations carrying your records with that map in front of you. A deletion message is useful only when the receiving system and responsible person can interpret and act on it.

Ask for statuses that mean something

“Processed” can hide several different outcomes.

Ask the vendor to explain the statuses relevant to its process. Does a status mean work was received, a match was found, a decision was made, action completed or an exception recorded?

Find out how the vendor records timestamps and how your team can investigate a disagreement without exposing unnecessary personal information. Ask what evidence is available to demonstrate the completed step.

Do not invent a successful outcome when the response is pending or unresolved. Keep those states visible in your own operating record and assign someone to review them.

If the vendor's process includes an exception or retention decision, ask who makes it and how the reason is documented. A generic success badge is not a substitute for that explanation.

Keep contact permission outside the identity result

A matched record does not tell your team that a person wants a message. A deletion or suppression process should not accidentally create a fresh lead task simply because a system received an update.

Ask what happens to active communications, review queues and previously exported lists when the relevant state changes. Check whether a restriction is visible where the next action would occur.

Keep the purposes clear. A choice about collection, a request affecting stored information and a preference about a communication channel can require different handling. Avoid compressing all of them into an unexplained yes-or-no field.

When comparing website data and workflow features, ask how an updated state reaches the people using the record, not only how it appears in the original system.

Request a controlled walkthrough

Ask the vendor to walk through a test case appropriate to its process. Use an approved test identity or other controlled method, not a real customer's details copied into a demonstration.

Follow intake, matching, exception handling, action and any applicable downstream notice. Include a case that cannot be resolved automatically. Check what happens when the same input arrives again.

Record which steps were demonstrated and which were only described. Keep the date, service version and responsible owner with the result. A walkthrough of one path does not establish every outcome, but it can expose an unanswered handoff.

Leave the review with a named gap

Your vendor questionnaire should end in a short decision record: role assessed, process understood, evidence reviewed, unresolved question, owner and review date.

A useful unresolved question is specific. “We cannot yet show how an affected CRM copy is handled after the source record changes” gives the team something to resolve. “Privacy looks fine” gives it nothing to check.

Start with the vendor and workflow that matter to your next business action. Understand the path, preserve the limits of the answer and make sure the next person using the information receives the decision that applies to it.