How Data Broker Compliance Is Actually Measured (2026)

The short answer: sending a privacy request is evidence that a request was submitted, not proof that a broker deleted a record. A defensible review uses at least three separate observations: the submission or acknowledgment, the provider's written response, and a dated recheck of the exact result or product named in that response. A search-engine result, a source record and a downstream broker are separate layers and must not be collapsed into one “removed” number.

This guide explains how to measure data-broker request outcomes without inventing removal rates, assigning a provider an unverified service-level agreement (SLA), or claiming that a missing public page proves deletion from an internal database. It is a measurement framework—not an outcome study. OfflistMe's catalog records workflows and evidence fields; it does not turn a catalog record into a verified deletion result.

For the request workflow itself, see the Complete Data Broker Opt-Out Guide. For California's current data-broker process, consult the California Privacy Protection Agency's data-broker information and DROP regulations.

Key takeaways

• A request receipt shows that a request entered a channel. It does not show that a broker accepted, verified or completed it.
• A provider response is the strongest evidence for the scope it names, but it can still contain exceptions, retained data or product boundaries.
• A page returning `404`, `410`, a redirect, a login screen or an empty result is an observation about that URL—not proof of root deletion.
• Search-engine visibility is a separate index layer. A provider can remove a page while an old result remains, or a result can disappear while a non-public record remains.
• “Root suppression,” hash lists, re-ingestion intervals and internal database behavior should not be claimed unless the provider documents them or a controlled study can directly support the claim.
• Legal deadlines depend on the jurisdiction, request type, controller, verification and exceptions. A 45-day rule is not a universal deadline for every provider or every person.
• Publish a rate only with a defined cohort, denominator, observation date, source evidence and method for handling unknowns.

The layers that must stay separate

Data removal reviews become unreliable when a visible page is treated as the whole data system. Use a layer model:

Source record or licensed feed
          │
          ▼
Provider record or product
          │
          ▼
Public profile, search result or report
          │
          ▼
Search-engine index and third-party copies

Each layer has a different owner, access method and evidence standard. A request to a consumer-facing profile provider may not reach a court, property office, marketing database, subscriber download or unrelated brand. A source correction may not be imported by a broker. A Google result may persist after the provider page changes.

The practical rule is simple: name the layer in every status. Prefer “provider confirmed suppression of the public profile URL” to “data deleted everywhere.”

A defensible outcome vocabulary

Use explicit statuses rather than a single green checkmark:

Do not use `verified_removed` unless the project defines the status narrowly and the evidence meets that definition. A catalog workflow can be evidence-ready while its provider outcome remains unknown.

The evidence packet for one request

For each provider and record, keep a private packet containing:

1. provider name and exact domain;
2. route URL and final URL after redirects;
3. source URL or registry reference used to identify the route;
4. source-check date and route status;
5. exact profile, report or search URL;
6. request type and the minimum fields submitted;
7. submission date, confirmation number and verification step;
8. provider response, including exceptions and retention language;
9. dated recheck of the exact result; and
10. unresolved contradiction, mismatch or missing evidence.

Keep request contents and personal information under the user's control. Do not put names, addresses, emails, generated request bodies or screenshots into analytics events, public logs or an unrelated research dataset.

Metrics that can be measured honestly

Metrics are useful only when the cohort and denominator are visible. These are measurement definitions, not OfflistMe performance claims.

Route reachability

`route reachability = routes returning an expected page or redirect / routes checked`

Record the date, HTTP result, final URL and whether a human could identify a request action. A `200` response alone does not prove that the form works. A `404` route may be outdated, replaced or intentionally unavailable.

Acknowledgment rate

`acknowledgment rate = requests with a provider receipt / requests submitted`

Define the acknowledgment window before collecting data. An auto-response can confirm delivery without confirming identity, eligibility or completion. Count “no evidence” separately from “rejected.”

Scope-confirmed response rate

`scope-confirmed rate = responses naming the requested product, profile or purpose / responses received`

This is stronger than an acknowledgment rate because it tests whether the response identifies what was handled. It still does not prove that an internal record was deleted unless the provider says so.

Public-result recheck rate

`not-found recheck rate = exact results not found at the recheck / exact results rechecked`

Define the recheck method: direct URL, provider search, authenticated report, or another route. Do not combine a direct URL recheck with a Google search in one denominator. Record “blocked,” “ambiguous,” “redirected,” and “not rechecked” separately.

Reappearance observation rate

`reappearance observation rate = records observed again in the defined cohort / records with a prior scope-confirmed result`

This is not a universal “re-list rate.” State the recheck dates, identifiers searched, provider scope, source conditions and how a namesake was excluded. A later listing can be a new source, a new URL, a matching error, an old cache or a provider copy; classify it before counting it.

Verification completeness

For a research ledger, track expected fields, recorded fields, unknown fields and not-recorded fields. Report the denominator. “1,018 records passed a bounded gate” is materially different from “1,018 records fully verified.”

Why HTTP status codes are not enough

An HTTP check can be useful, but it cannot see a private database. A provider may:

• return `200` with “no result” content;
• return a generic `404` for an unknown or deleted URL;
• redirect a page to a search page;
• require a login or email verification;
• serve different content by region, cookie or user agent; or
• leave a source page unchanged while removing its own index.

Use status, visible content, canonical URL, provider response and recheck date together. Never describe a `404` as proof of hard deletion or a `200` as proof that a profile remains without inspecting the page meaningfully.

Search-engine rechecks are a separate test

Search engines crawl on their own schedules and may show stale titles, snippets or URLs. A search result can remain after a provider removes a page; a page can also be difficult to find even while a direct URL remains live. If you test search visibility, record:

• the engine and search query;
• the exact result URL;
• date and location settings where relevant;
• whether the direct URL still loads; and
• whether the result is a source page, provider page or cached snippet.

Use the search engine's current outdated-content or personal-information process only when its eligibility rules fit the result. Search removal does not delete the source or provider record.

Legal timing and SLA boundaries

Some privacy laws provide response periods, but the clock and obligation depend on the request and facts. California's CCPA regulations generally provide a response period for covered requests, while the California Delete Act creates a distinct DROP process for eligible residents and covered data brokers. The CPPA's current information says covered brokers must access DROP at least every 45 days beginning August 1, 2026, subject to the applicable rules and exceptions. That is not a universal promise that every broker result disappears in 45 days.

Other US state, EU and UK regimes have their own scopes, exceptions and response rules. A provider's voluntary route may serve people outside a statutory scope, but a voluntary workflow is not proof of a legal right. Link to the current official statute or regulator when stating a deadline, and label an estimate as an estimate.

Auditing a cohort without fabricating a benchmark

For an audit or editorial study:

1. freeze the cohort definition and as-of date;
2. record why each provider belongs in the cohort;
3. capture the route and exact result before submission;
4. use the same evidence fields for every record;
5. distinguish missing evidence from a failed request;
6. use a predeclared recheck schedule suited to the risk;
7. have a second reviewer inspect ambiguous cases; and
8. publish the numerator, denominator, exclusions and limitations.

Do not publish a percentage from a convenience sample as an industry-wide rate. Do not compare providers when one cohort measures public pages and another measures private reports. Do not infer compliance from a provider's marketing coverage count.

What OfflistMe can truthfully say

OfflistMe's catalog is a preparation and research layer. It can expose recorded route information, evidence fields, source freshness, required-field notes and review status. The user reviews the match, decides what information to provide, submits through the provider's current route and keeps the response.

The catalog does not establish that every provider has a particular user, that all route fields remain current, that every legal right applies, that a provider will accept a request, or that a response reaches downstream databases. It also does not measure a removal success rate unless a separately defined outcome study supplies the evidence.

Example audit row

provider: Example Provider
route_checked_at: 2026-08-21
route_url: https://example.test/privacy-request
route_status: route_recorded
record_url: https://example.test/profile/example
request_type: delete_personal_information
submitted_at: not_recorded
provider_response: unknown
recheck: not_started
scope: public_profile_only_if_confirmed
limitations: source_and_downstream_records_not_tested

This row is useful because it is honest about what has not happened. A blank or `unknown` field is a research task, not a successful outcome.

Frequently asked questions

Is a deleted profile the same as hard deletion?

No. A deleted public result may reflect removal from one interface, while the provider retains information for a permitted purpose or another product. Only the provider's stated scope and applicable evidence support a narrower conclusion.

Does a provider's “completed” status prove compliance?

Not by itself. Ask what product, record and processing purpose were completed, then recheck the exact public result where possible.

Should every audit use a 30-, 60- or 90-day recheck?

No universal interval is correct. Choose the interval based on risk, provider response, source behavior and study design. Publish the chosen interval instead of presenting it as a law or industry fact.

Does DROP make every data-broker request permanent?

No. DROP has a defined California statutory scope and recurring access requirements for covered brokers. Review the CPPA guidance and DROP regulations; do not extend the process to every provider, resident or downstream copy.

What is the strongest evidence of completion?

For a public listing, the strongest practical packet is a provider response that names the scope plus a dated recheck of the exact result. For a private product, the provider's written scope and any available disclosure or suppression confirmation are more informative than a Google search.

Sources and review note

The CPPA's data-broker information and DROP system requirements describe the California Delete Act's covered scope and the requirement beginning August 1, 2026 for data brokers to access the accessible deletion mechanism at least every 45 days, subject to the applicable rules and exceptions. The CPPA's current CCPA regulations provide a separate reference for general California request timing. These legal intervals are not universal provider SLAs or proof that a public result disappeared.

Reviewed August 26, 2026. The statuses and metrics in this guide are editorial measurement definitions; record the source, scope, evidence, date, unknowns, and limitations before treating any result as comparable.

Related guides

• Complete Data Broker Opt-Out Guide
• Why Your Data Reappears After Removal
• California Delete Act and DROP Guide
• Does Opting Out Guarantee Data Removal?
• OfflistMe Opt-Out Directory