Who Verifies the Status? A Working Paper on Evidence for Deletion Requests

Full title: Who Verifies the Status? Evidence Standards for Deletion Requests When the Auditee Writes the Record. Ben Tobin, Sirveil, Inc. The complete paper is published below; a PDF in the ACM template is available from contact@sirveil.ai.

Working paper, 19 October 2026. Submitted to the 6th ACM Symposium on Computer Science and Law (CS&Law 2027), non-archival track. Not peer reviewed.

Abstract

Three U.S. states now address a consumer's ability to learn the "status" of a data-broker deletion request. California's Delete Act requires its accessible deletion mechanism to let a consumer "verify the status" of a deletion request; Connecticut's Public Act 26-64 requires its mechanism to let a consumer "determine the status"; and Vermont's Act 138 directs a study of a mechanism that would let a consumer "verify the status." None of these texts says what evidence establishes that status. In the one mechanism now operating, California's Delete Request and Opt-out Platform (DROP), the status a consumer sees is the code the data broker reports about itself.

The paper argues that a status reported only by the party whose compliance is in question is an attestation, not a verification, and that evidence law, auditing standards and the technical structure of deletion all point to the same remedy: at least one item of evidence that the broker did not generate. It (1) analyzes the statutory texts and the California status vocabulary; (2) models what "deleted" can mean technically and what each meaning leaves observable from outside, showing that outside observation can contradict a reported deletion but cannot confirm one; (3) reports a census of the contact email addresses that all 603 registered California data brokers published to the state registry, run on 7 September, 15 September and 19 October 2026; and (4) proposes a three-state, time-stamped, independently observed evidence standard mapped to each statute. Under the standard, a verified status is a broker report that has been tested against independent evidence and not contradicted. It verifies the report, never the deletion itself.

The four findings in brief

• The statutes converge on a word and leave it undefined. California says "verify," Vermont says "verify," Connecticut says "determine." None defines "status," and Connecticut defines "deletion request" but not "delete."
• California's status codes cannot express the differences a consumer would most want to know. One code, "record deleted," covers erasure, deidentification and aggregation, and it is consistent with exempt information remaining.
• Outside observation is a one-way test. Finding a record after a reported deletion is strong evidence against the report; not finding it is weak evidence for it.
• The registry's own contact layer had errors that stayed in place. Two of 603 published contact addresses could not receive mail on any of three dates over 42 days, and neither entry changed in the published registry. Both were reported to the Agency.

Data and method

The registry census used only the Agency's public registry export and public DNS. No requests were sent to any broker and no personal information about any individual was collected. The paper does not name the two registrants.

Full text of the working paper

Introduction

A consumer who asks a data broker to delete their personal information then has two questions: did the broker do it, and does it stay done? Until recently the law gave the consumer no way to check either. That has started to change. California’s accessible deletion mechanism “shall allow the consumer, or their authorized agent, to verify the status of the consumer’s deletion request” (California Legislature 2025). Connecticut’s Public Act 26-64, effective October 1, 2026, requires its mechanism to permit a consumer to “determine the status of the consumer’s deletion request” (Connecticut General Assembly 2026). Vermont’s Act 138 of 2026 directs the Secretary of State to study a mechanism that “allows the consumer or their authorized agent to verify the status of the consumer’s deletion request” (Vermont General Assembly 2026). A New York bill that passed the state Senate in June 2026 uses the California formulation (New York State Senate 2026).

The texts converge on a word, “status,” and on a verb, “verify” or “determine,” without saying what evidence establishes either. The gap is not academic. California’s mechanism opened to consumers in 2026, brokers began processing its requests on August 1, 2026, and more than 550,000 Californians had signed up by the beginning of October (California Privacy Protection Agency 2026h). Its operator tells consumers that, after a data broker processes deletion requests, the broker reports “back to DROP with the results of each record they process” (California Privacy Protection Agency 2026h). The status a consumer can verify is therefore the status the broker reports. The entity whose compliance is in question supplies the only evidence of compliance that the mechanism displays.

This paper makes four contributions.

1. Legal analysis (Section 2). We set out what each statute requires the consumer to be able to verify, how California’s regulations constrain what a status can express, and what evidence law and auditing standards say about records produced by the party whose conduct they document.

2. A technical model of “deleted” (Section 3). California permits three methods of deletion (erasure, deidentification and aggregation) and reports none of them by name. We show that all three remove identifiers, so an identifier-keyed outside observation can contradict a reported deletion but can never confirm one.

3. A measurement (Section 4). Before a status can be verified, a request has to reach the broker. We checked the contact email address that every registered California data broker published to the state registry, on three dates over six weeks. The same two of 603 addresses could not receive mail on every run, and both entries were unchanged in the published registry.

4. A proposed evidence standard (Section 5). We propose that a status be reported in three states (observed, not observed, indeterminate), that a status described as verified rest on at least one item the broker did not generate, and that observations be dated, repeated and bounded by a published statement of what was searched. We map the standard to each statute’s text.

Section 6 takes objections and limits, Section 7 sets out ethics and disclosure, and Section 8 concludes with recommendations for regulators now designing mechanisms in Connecticut and Vermont and audit rules in California.

The Legal Landscape

California: a right to verify, implemented as a broker report

California’s Delete Act requires the California Privacy Protection Agency (CalPrivacy) to run an accessible deletion mechanism. Since August 1, 2026, each registered data broker must access the mechanism at least once every 45 days and process the deletion requests it finds (California Legislature 2025). Assembly Bill 883, chaptered on September 27, 2026, shortens that interval to 30 days, beginning January 1, 2027 (California Legislature 2026a). After a request is processed, the broker may not sell or share the consumer’s newly collected personal information (California Legislature 2025). Since the Delete Act’s enactment in 2023, subdivision (b)(9) has required the mechanism, which the Agency had to establish by January 1, 2026, to let the consumer or an authorized agent “verify the status” of the deletion request (California Legislature 2023, 2025).

The implementing regulations define the vocabulary in which that status can be expressed. A broker reports each matched identifier as one of four outcomes: record deleted, record opted out of sale, record exempted, or record not found (California Privacy Protection Agency 2026b). The Agency’s consumer guidance adds a fifth, pending, for requests not yet processed, and says processing “can take up to 90 days” (California Privacy Protection Agency 2026h). Three features of the regulations shape what any status can mean.

One code covers three methods.

For DROP, “delete” means “permanently and completely erasing the personal information from existing systems, including archived or backup systems, deidentifying the personal information, or aggregating consumer information” (California Privacy Protection Agency 2026b). The broker chooses the method. The status code reports whether the broker complied, not how. Deletion from archived or backup systems may be delayed until the system is restored to active use or accessed for a sale, disclosure or other commercial purpose (California Privacy Protection Agency 2026b), which is close in effect to the general CCPA rule that excepts such systems (California Privacy Protection Agency 2026a). And the broker must keep the minimum personal information needed to honor the request in future (California Privacy Protection Agency 2026b), so a deleted record coexists by design with a retained suppression entry.

“Deleted” can mean partly deleted.

A broker reports “record deleted” when it matched the identifier and deleted the associated personal information “as required in section 7613(b)” (California Privacy Protection Agency 2026b), and section 7613(b) does not require deletion of information that is exempt. “Record exempted” is reserved for the case where all of the information is exempt (California Privacy Protection Agency 2026b). The Agency’s own explanation is that a deleted status means the broker deleted any non-exempt personal information (California Privacy Protection Agency 2026g). A status of deleted is therefore consistent with part of a record remaining under an exemption.

“Not found” is a snapshot.

The broker must keep an unmatched request and check newly collected records against it, and if it later finds a match it must report the new status, for example a change from not found to deleted (California Privacy Protection Agency 2026b). Not found is a statement about a matching attempt at a time, not a finding that the broker holds nothing.

Each of these outcomes is the correct, compliant report in its circumstances. The point is not that brokers misreport. It is that the vocabulary cannot express the differences a consumer would most want to know, and that nothing in the mechanism tests the report against anything else.

Two further 2026 developments raise the stakes. Senate Bill 923, signed on September 27, 2026, provides that a business that obtained personal information about a consumer from a source other than the consumer complies with a deletion request by retaining a record of the request and “the minimum data necessary for the purpose of ensuring the consumer’s personal information remains deleted” (California Legislature 2026b). Two things follow. “Remains deleted” makes deletion an ongoing state rather than an event, and an ongoing state is something that can be checked over time. And for indirectly obtained data, the statute’s measure of compliance is a suppression record the business keeps about itself. Separately, the Delete Act requires each data broker, beginning January 1, 2028, and every three years thereafter, to “undergo an audit by an independent third party to determine compliance” (California Legislature 2025). In August 2026 the CalPrivacy Board advanced draft audit regulations toward formal rulemaking (California Privacy Protection Agency 2026d; IAPP 2026). The draft would set an audit period beginning August 1, 2026, require an auditor who is “qualified, objective, and independent,” and include testing of the deletion processing system within the audit scope (California Privacy Protection Agency 2026d). As of October 19, 2026, the Agency’s rulemaking page still describes the audit rulemaking as preliminary, and no proposed text has been formally noticed for comment (California Privacy Protection Agency 2026f). The evidence an auditor may rely on is therefore still open.

Connecticut: “determine the status”

Connecticut’s Public Act 26-64 creates a registration regime and directs the Commissioner of Consumer Protection to establish an accessible deletion mechanism. Section 5(a)(1)(B)(ii) requires that mechanism to permit a consumer to “determine the status of the consumer’s deletion request” (Connecticut General Assembly 2026). Its definitions section defines “deletion request” but not “delete,” and not “status.” Section 5(e) permits the Commissioner to contract with public or private entities to administer the program or “a multistate accessible deletion mechanism program,” and Section 9 permits, but does not require, regulations implementing Sections 2 through 8 (Connecticut General Assembly 2026). The mechanism must be established by July 1, 2028, and Section 5(d) separately requires independent audits of brokers beginning in 2031 (Connecticut General Assembly 2026). Because the mechanism is not yet built, Connecticut is the jurisdiction where an evidence standard can be specified before a system is procured.

Vermont: a study of “verify the status”

Vermont’s Act 138 does not create a mechanism. Section 2 directs the Secretary of State to study the feasibility of one, and lists features the study must address, including that the mechanism “allows the consumer or their authorized agent to verify the status of the consumer’s deletion request” (Sec. 2(a)(1)(M)) (Vermont General Assembly 2026). An interim report is due on or before December 1, 2027 and a final report on or before December 1, 2028 (Vermont General Assembly 2026). Vermont’s verb is the same as California’s; Connecticut’s is different. We treat the difference as potentially meaningful and return to it in Section 5.

Beyond the three states

The same template is spreading, and so is the opposite approach. New York’s S9088-A would require its mechanism to let a consumer verify the status of a deletion request and would require brokers to undergo an independent audit every three years (New York State Senate 2026). In the other direction, a federal bill heard in June 2026 would treat a controller that obtained data from a third party as “in compliance” with a deletion request if it retains a record of the request and the minimum data necessary to ensure the data “remains deleted,” or if it opts the consumer out (U.S. House of Representatives 2026). Like SB 923 for indirectly obtained data, that provision would make the controller’s own suppression record, or an opt-out, the statutory measure of deletion, and it would extend the approach nationally. In the European Union, a thematic case digest on erasure prepared for the European Data Protection Board’s Support Pool of Experts describes proof that erasure has occurred as “a topic that has been little explored,” and reports a national decision in which a controller’s screenshot showing a negative database result was accepted (Mantelero 2026). The digest states that it does not necessarily reflect the Board’s official position. In each case, the accepted proof of deletion is something the deleting party produces.

One regime points the other way. Under New Jersey’s Daniel’s Law, which lets covered persons demand that their home addresses not be disclosed, the state’s Supreme Court held in August 2026 that liability for actual damages carries no mental-state requirement (“Atlas Data Privacy Corp. v. We Inform, LLC” 2026). Liability then turns largely on a dated, observable fact: whether the information was still disclosed after the statutory period following a valid notice. That is a question an outside observer can answer, and one on which a self-report carries little weight. The constitutionality of the statute remains before the federal courts.

Finally, mechanism design is becoming multistate. Connecticut’s Section 5(e) contemplates a multistate mechanism, and in August 2026 CalPrivacy and the attorneys general of eleven states, including California, Connecticut and Vermont, formed a Consortium of Privacy Regulators to coordinate (California Privacy Protection Agency 2026c). An evidence standard specified once could travel.

What evidence law and auditing standards offer

The statutes leave “status” undefined, but the problem of evidence produced by an interested party is old. Evidence law, auditing standards, computer science and ordinary meaning each bear on it.

Authentication.

Federal Rule of Evidence 901(a) requires evidence sufficient to support a finding that an item is what its proponent claims it is (Federal Rules of Evidence 2024). A status code is authentic as a record of what the broker reported. Whether it is evidence that deletion occurred is a separate question that authentication does not answer.

Business records.

The hearsay exception for records of a regularly conducted activity rests on the reliability of routine record-keeping. It does not apply if the opponent shows that “the source of information or the method or circumstances of preparation indicate a lack of trustworthiness” (Federal Rules of Evidence 2024). In Palmer v. Hoffman, construing the statutory predecessor of the rule, the Supreme Court held that an accident report a railroad prepared about its own conduct, with litigation in view, was not the kind of routine record the exception contemplates (“Palmer v. Hoffman” 1943). A deletion status is prepared to demonstrate the preparer’s own compliance with a legal duty. A report the law requires on a routine schedule is not a litigation document, and we do not claim Palmer controls it. The narrower point is the one Rule 803(6)(E) states: the circumstances of preparation, including the preparer’s interest in what the record shows, bear on trustworthiness. The doctrine treats self-interest in preparation as a reason to seek corroboration, not as a reason to exclude.

Audit evidence.

Auditing standards rank evidence by source. The PCAOB’s standard on audit evidence treats evidence from a knowledgeable source independent of the company as more reliable than evidence obtained only from internal company sources (Public Company Accounting Oversight Board 2010), and the international standard likewise treats evidence from independent sources outside the entity as more reliable (International Auditing and Assurance Standards Board 2009). A broker’s report of its own deletion outcomes is, in audit terms, internal evidence. The critical literature on auditing warns that verification rituals can substitute for verification (Power 1997), and work on algorithmic auditing has made the same point about internal audits that lack external checks (Raji et al. 2020).

The narrow reading.

“Status of the consumer’s deletion request” can be read as the request’s processing state: received, pending, processed. On that reading a broker’s report fully satisfies the statute. But the mechanism must already show that a request was transmitted and must already display the broker’s reported outcome; if “verify the status” meant only “see what the broker reported,” subdivision (b)(9) would add nothing to the reporting duties the regulations already impose. The broader reading gives the provision independent work. And the standard we propose stands as policy under either reading: nothing in the statutes prevents an operator from displaying independent evidence beside the broker’s report.

Verifiable deletion in computer science.

The computer-science literature has formalized deletion as an indistinguishability property: a system has deleted a user’s data if its subsequent state is as if the data had never been provided (Garg, Goldwasser, and Vasudevan 2020). Work on machine unlearning has shown how a data subject can test, probabilistically and from outside, whether a model provider actually removed their data, by planting markers and checking whether they persist (Sommer et al. 2022). Both strands share the premise of this paper: a deletion claim is a claim about the deleter’s state, and the claim should be testable by someone other than the deleter. Our setting is simpler than either, because the question is not what a model remembers but whether a record is still published.

The ordinary meaning of “verify.”

To verify is “to establish the truth, accuracy, or reality of” something (Merriam-Webster 2026). Reading the California and Vermont statutes to let a consumer verify a status, where the only available evidence is the assertion being verified, gives the verb no work to do. Connecticut’s “determine” is weaker; one can determine what a report says by reading it. Even on that reading, a mechanism that returns only the broker’s report lets the consumer determine what the broker said, not what happened.

What “Deleted” Can Mean Technically

States of a record

From the consumer’s point of view, a record about them at a broker can be in at least seven states after a deletion request. Table 1 lists them with what an outside observer can see and what the broker would report.

Table 1. Possible states of a consumer’s record after a deletion request, what an identifier-keyed outside observation would show, and the DROP code a compliant broker would report.

State	Description	Outside observation	Reported code
Erased	Removed from live, archived and backup systems	Absent, if previously present	Deleted
Deidentified	Identifiers removed; attributes retained	Absent (no identifier to match)	Deleted
Aggregated	Folded into group statistics	Absent (no identifier to match)	Deleted
Partially deleted	Some fields deleted; rest retained under exemption	Possibly present	Deleted
Suppressed	Source retained; filtered at query or display time	Absent until the filter fails or changes	Varies
De-indexed	Page persists; removed from a search index	Absent via search; present by direct URL	Varies
Re-listed	Deleted, then re-acquired from a new source	Absent, then present again	Deleted (no new report)

Two observations follow. First, the three lawful deletion methods are not distinguishable from outside. Each removes the identifiers by which an outside observer would find the record. Second, several states that are not deletion (suppression, de-indexing, a filter applied only to the requesting consumer’s view) look the same from outside as deletion, at least for a time. Re-listing is the case the regulations address by requiring brokers to check newly collected information against past requests; whether that check succeeded is not reported once a request has been closed as deleted. A public description by one broker-side compliance vendor of query-time suppression, in which flagged records stop appearing in results while source data is retained, illustrates how close suppression and deletion can be in practice. We do not suggest that any particular implementation is non-compliant; whether suppression satisfies a given statutory definition is a legal question about specific facts.

Observation is a falsification test

Let D be the event that the broker deleted the consumer’s record by any lawful method and let O be the event that an outside observer, querying public sources with the consumer’s identifiers, finds the record. Because every lawful method removes identifiers, P(O | D) is small. It is not zero only because of namesake collisions, caches and propagation delay, which a careful protocol can control. But P(not-O | not-D) is not small: the record may be absent from the sources searched for reasons that have nothing to do with deletion, including incomplete index coverage, a login wall, a robots exclusion, or suppression of the consumer’s own view.

The evidential asymmetry is therefore sharp. Observing the record after a reported deletion is strong evidence against the report, subject to identity resolution. Not observing it is weak evidence for the report. In likelihood-ratio terms, P(O | not-D) / P(O | D) is large, so a finding strongly favors non-deletion; P(not-O | D) / P(not-O | not-D) is close to one when coverage is low, so a non-finding barely moves the odds. Outside observation can falsify a reported deletion; it cannot confirm one. Any evidence standard that labels an outside observation “verified deleted” overclaims, and any standard that ignores outside observation discards the most accessible evidence the broker did not produce. (Seeded or canary identities, as used in synthetic-identity studies (Kempen et al. 2026) and in unlearning verification (Sommer et al. 2022), are a second source of such evidence; they test a broker’s process rather than a particular consumer’s record.)

Two caveats bound the inference. First, a found record shows non-deletion by this broker only if it is found on a surface the broker controls or can be traced to it; a copy held by another broker, a mirror or a public-records source says nothing about the broker that reported. Second, a record that is partly deleted and partly exempt is compliant and may still be found. A finding is therefore inconsistent with full deletion, not proof of non-compliance.

Identity resolution

Observation is useful only if the observer can tell whether a found record is about the consumer. Names alone are ambiguous; many people share a name and a city. A protocol that treats a name-only match as a finding will report false contradictions, and one that treats a failed name-only search as absence will report false not-observed results. We therefore treat any observation keyed only on a name as indeterminate, and require a match on at least one non-name identifier (a phone number, an email address or a street address) for an observation to count as present.

Measurement: Can a Request Reach the Broker?

Why the contact channel

Verifying the status of a request presupposes that the request was deliverable. The state registry is where a consumer, an authorized agent, a researcher or a regulator finds a broker’s published contact details, and the Delete Act requires each registrant to provide its “primary physical, email, and internet website addresses” (Cal. Civ. Code § 1798.99.82(b)(2)(A)). CalPrivacy has advised registrants that they must provide true and correct information, and that “the Delete Act does not distinguish unintentional mistakes from intentional misrepresentation: both result in incorrect information” (California Privacy Protection Agency 2026i). The registry entry is therefore itself a self-reported record with a legal accuracy duty, and its most basic property, whether the published email address can receive mail, can be checked mechanically from outside.

This measurement does not test deletion. It tests the first link in the chain on which any later status depends, and it tests whether a self-reported record that is wrong in an obvious way gets corrected.

Method

We downloaded the registry’s bulk export from the Agency’s website on September 6, September 15 and October 19, 2026 (California Privacy Protection Agency 2026e), and ran the census on September 7, September 15 and October 19. Each file contained 603 registrant records; the September 15 and October 19 files were byte-identical. For each registrant we parsed the published primary contact email address and asked the domain name system whether its domain can receive mail. Each address was assigned one verdict:

• OK: the domain publishes one or more MX records;

• NXDOMAIN: the domain does not exist (on September 7 and 15 also confirmed against the top-level domain’s authoritative servers; on October 19, two independent resolvers agreed);

• DNS_BROKEN: the domain is delegated but its authoritative servers do not answer (SERVFAIL), so no resolver we queried found a mail exchanger;

• NULL_MX: the domain publishes a single null MX, declaring that it accepts no mail (Levine and Delany 2015);

• NO_MAIL: the domain resolves but has neither MX nor address records;

• A_ONLY: no MX but an address record, so mail may be delivered by the implicit-MX rule (Klensin 2008) (recorded as soft, not a defect);

• MALFORMED or MISSING: the field cannot be parsed or is blank.

On September 7 we queried three public resolvers and confirmed nonexistence against the .com authoritative servers. On September 15 we repeated the check against three public resolvers and the authoritative server. On October 19 we repeated it through two independent DNS-over-HTTPS resolvers. We required agreement across resolvers before assigning any defect verdict.

An early version of the instrument used a single local resolver and classified a domain whose nameservers refused to answer as nonexistent. Cross-checking against public resolvers and the authoritative server corrected that verdict to DNS_BROKEN. We report this because it illustrates a requirement of Section 5: an outside observation is only as good as its recorded method, and the method must be published so that others can reproduce or correct it.

Results

Table 2 reports the verdicts. On all three dates, 601 of 603 registrants published an address at a domain that accepts mail. Two did not. For Registrant A, the published email domain does not exist; the registrant’s own published website domain differs from it by one letter and has working mail records, so the defect is almost certainly a transcription error in the registry filing. For Registrant B, the domain is delegated but its nameservers do not answer, so mail to the published address cannot be delivered. Both entries were unchanged across all three downloads, 42 days from first to last observation. When the defects began is unknown.

Table 2. Contact-channel verdicts for all registered California data brokers, by audit date.

Verdict	7 Sep 2026	15 Sep 2026	19 Oct 2026
OK	601	601	601
NXDOMAIN	1	1	1
DNS_BROKEN	1	1	1
NULL_MX, NO_MAIL, A_ONLY, MALFORMED, MISSING	0	0	0
Registrants	603	603	603

Interpretation

The defect rate is low: two of 603, or 0.3%. We do not offer it as evidence that the registry is unreliable. Its value lies elsewhere. First, the defects are binary and machine-checkable, and a one-line validation at intake would have caught both. Second, the defects persisted in what the public sees. On October 19 the published registry still showed both entries unchanged. Because the September 15 and October 19 exports are byte-identical, we cannot tell whether a registrant filed a correction that the export does not yet reflect; the finding is about the record a consumer or agent would use, not about any registrant’s conduct. Either way, we observed no correction of an obvious error in the published self-reported record. Third, the result is consistent with prior work showing that brokers’ self-reported compliance data are inconsistent: one study found that of 457 brokers whose registry filings could be matched to their own posted policies, only 27 (5.9%) reported identical request metrics in both places (Gueorguieva et al. 2026). A third-party tally of the 2024 request metrics that registrants reported in their filings counts more than 58 million deletion requests received; the tally’s authors note that all figures are self-reported and not independently verified (Control D 2026).

Prior measurement work has tested whether brokers respond to requests. A study of access requests to the 543 brokers then registered in California found that more than 40% did not respond at all (Kempen et al. 2025). A preprint testing deletion and opt-out requests with synthetic identities reports that of 322 brokers sent a deletion request, only 97 responded with a result, and that some replied that data was deleted for a consumer who did not exist (Kempen et al. 2026). The authors state that the study “did not evaluate the actual efficacy” of the requests. A study of transparency compliance found only 9.2% of 522 registered brokers fully compliant (Gueorguieva et al. 2026). We are not aware of published work that measures whether a reported deletion held. The contact-layer census is narrower than these studies, but it adds one thing: repeated observation of a self-reported record over time, which is the property a status standard needs.

Limitations of the measurement

We tested one channel, the published email address. We did not test web forms, the rights page URL, or postal addresses, and an MX record shows that a domain accepts mail, not that a particular mailbox is monitored. We did not send any request. The census covers the registry as exported; whether the export reflects every registrant the Agency holds is not something we can observe.

A Proposed Evidence Standard

Design goals

A standard for “verify the status” should (i) give the verb work to do, (ii) be honest about what outside observation can and cannot show, (iii) be cheap enough to specify before a mechanism is procured, and (iv) not depend on any particular vendor. We propose seven elements.

E1. Independent provenance.

A status may be described as verified only if the record includes at least one item of evidence not generated by the broker to which the request was directed, and that evidence does not contradict the broker’s report. “Verified” then means that the report was tested and not contradicted; it never means that deletion was confirmed. A broker’s own report, log, screenshot or attestation does not qualify, however detailed.

E2. Three outcome states, never “deleted.”

An outside observation is reported as PRESENT (the record was found, with a non-name identifier matched), NOT OBSERVED (the search ran and found nothing within its stated boundary), or INDETERMINATE (the search could not distinguish the consumer from another person, a source failed, or corroboration was insufficient). No observation is reported as “deleted” or “removed.” Section 3 explains why: absence is weak evidence.

E3. A complete observation record.

Each observation records the source queried, the class of identifier used (never the identifier itself in any published output), the URL and a short snippet or content hash when present, the date and time, the version of the instrument, and the boundary of the search, including sources it could not reach.

E4. Identity resolution.

A PRESENT finding requires a match on at least one non-name identifier. Name-only observations are INDETERMINATE by rule.

E5. Repetition.

Because deletion must now “remain” (California Legislature 2026b), and brokers must re-access the mechanism on a fixed cycle (California Legislature 2025, 2026a), an observation should be repeated on a cadence tied to that cycle. A single observation describes a moment; a series describes a state.

E6. Independence of the observer.

The observer should not be the broker, should not be paid by the broker, and should disclose any interest in the outcome, including acting as the consumer’s agent for the same request.

E7. Uncertainty stated, not averaged away.

The standard reports each observation with its boundary. It does not support aggregate claims such as “98% verified,” because the denominator would mix strong and weak evidence.

Combining the broker’s report with an observation

The standard does not replace the broker’s report. It sits next to it. Table 3 shows how a mechanism could display the two together.

Table 3. Combining a broker-reported status with an independent observation.

Broker report	Observation	Status shown to the consumer
Deleted	Not observed	Broker reported deleted; not observed on the sources searched as of [date].
Deleted	Present	Broker reported deleted; a matching record was still observed on [broker-controlled source] as of [date]. Inconsistent with full deletion; may reflect exempt retention. Referred for review.
Deleted	Indeterminate	Broker reported deleted; independent check inconclusive.
Not found	Present	Broker reported no match; a matching record was observed on [broker-controlled source]. Referred for review of matching.
Opted out / exempted	Any	Broker reported that it did not delete; observation shown for information.
Pending	Any	Awaiting broker report.

The second and fourth rows are the cases the current mechanism cannot express. They are also the cases with the highest value to a consumer, to a regulator, and to an auditor testing the deletion processing system.

Mapping to the statutes

California, Civ. Code § 1798.99.86(b)(9). “Verify” is satisfied by E1. The vocabulary limits of the regulations are addressed by E2 and the combined display, which labels the broker’s code as the broker’s and places independent evidence beside it. E5 implements “remains deleted.”

Connecticut, PA 26-64 § 5(a)(1)(B)(ii). “Determine” could be read to require only the broker’s report. E2, E3 and E7 give the Commissioner a status vocabulary that says which source each status comes from. The standard gives the Commissioner a way to require more without new legislation, through the permissive regulation authority in Section 9 or through the specifications of a contract under Section 5(e).

Vermont, Act 138 § 2(a)(1)(M). The study must address how a consumer could verify status. The standard is one concrete answer the study can evaluate on cost and feasibility before its interim report, and E4 and E6 address the study’s authorized-agent language directly: an agent may observe, but must disclose its role.

California’s proposed audit regulations. The proposed scope includes testing the deletion processing system (California Privacy Protection Agency 2026d). Sampled outside observation under E1–E7 is one such test; with seeded identities, it is among the few in which the evidence does not come from the auditee.

Objections and Limits

Coverage and false negatives.

No observer searches everything. A NOT OBSERVED result can reflect a gap in coverage. The standard answers this by requiring a published boundary (E3) and by never reporting absence as deletion (E2).

The standard cannot positively see any lawful method.

Deidentification and aggregation are invisible to identifier-keyed observation by construction, and erasure looks the same as every other kind of absence. The standard does not claim to verify them. It can only show when a record still carrying identifiers contradicts all three methods at once. That is why it is a floor and not a substitute for an audit with access to the broker’s systems.

Privacy of the verifier.

An observer must hold the consumer’s identifiers in order to search for them. A badly designed verification service would become another dossier. The standard should be paired with minimization: identifiers held only as long as the request is open, retained otherwise only as keyed or salted hashes held by the operator (unsalted hashes of phone numbers and email addresses can be reversed by brute force), and never published. Prior work found that brokers’ own verification demands can create new privacy risks (Kempen et al. 2025); a verification standard must not repeat that mistake.

Conflict of interest.

A party that both files deletion requests as an agent and checks whether they held has an interest in the result. E6 requires disclosure. The stronger structural answer is that an observation is reproducible from its record (E3) by any party entitled to hold the identifiers, including the broker, the regulator and an auditor.

Gaming.

A broker could treat known observers differently, for example by blocking their network addresses. Observation from varied vantage points, and comparison with what an ordinary visitor sees, reduces the risk. The regulator, as a mechanism operator, can also observe directly.

Legality of observation.

The standard contemplates reading publicly accessible pages, not bypassing access controls. The Supreme Court has read the federal computer-fraud statute’s “exceeds authorized access” clause narrowly (“Van Buren v. United States” 2021), and the Ninth Circuit has held that accessing publicly available web pages is unlikely to be access “without authorization” (“hiQ Labs, Inc. v. LinkedIn Corp.” 2022), but site terms and state law vary, and a mechanism operator should specify permitted methods.

Rights may be the wrong instrument.

A broader critique holds that individual privacy rights place the burden on consumers who cannot realistically exercise them at scale (Solove 2023). Verification is vulnerable to the same objection if it is left to individuals. That is why the recommendations below are addressed to mechanism operators and auditors: the standard is meant to be applied systematically, on a sample or on every request, not left to each consumer.

Cost.

Outside observation costs something per check. Specified before a mechanism is procured, the cost is a line in a contract. Retrofitted afterwards, it is likely to cost more.

Ethics and Disclosure

The measurement in Section 4 used only public data: the state’s registry export and the public domain name system. We sent no requests to any broker, collected no personal information about any individual, and used no synthetic identities. Both defects were reported to the Agency before this paper was made public. We do not name the two registrants; the facts can be reproduced from the public registry.

Conflict of interest.

The author is the founder of Sirveil, Inc., which sells an outside-in exposure check whose results use three states similar to those in Section 5, and a consumer application that files deletion requests as an authorized agent. The author has filed public comments with California and written to regulators in Connecticut and Vermont on the subject of this paper. The measurement in Section 4 did not use Sirveil’s product.

Conclusion and Recommendations

Two states have written “the status of the consumer’s deletion request” into statute, a third is studying it, and none says what evidence establishes it. Where a mechanism exists, the answer by default is the broker’s own report. Evidence law, auditing standards and the plain meaning of “verify” all treat that as an attestation that needs corroboration, and the technical structure of deletion means outside corroboration can contradict a report but never confirm it. We recommend that:

1. Connecticut and Vermont define status evidence before procurement. Connecticut can do so by regulation or contract specification; Vermont’s study can evaluate it before the December 2027 interim report.

2. California label the source of each status. A status shown to a consumer should say that it is the broker’s report and should show any independent observation beside it.

3. California’s audit rules admit outside observation as audit evidence, sampled and recorded under a published method, alongside the broker’s own logs.

4. Registries validate published contact channels at intake and on a schedule. A DNS check costs almost nothing and would have caught both defects we found.

5. Researchers measure outcomes, not only responses. The open empirical question is whether reported deletions hold over time. Answering it requires repeated, independent, identity-resolved observation, which is the same thing a status standard requires.

Appendix A. Data Dictionary for the Contact-Channel Census

Field	Description
data_broker_name	Registrant name as published in the registry export (withheld in this paper for the two defect cases)
published_email	“Data broker primary contact email address” field, as published
domain	Domain part of the address, lower-cased
verdict	One of the verdicts in Section 4, assigned only on resolver agreement
checked_utc	Time of the check

Appendix B. Statutory Excerpts

• Cal. Civ. Code § 1798.99.86(b)(9): “The accessible deletion mechanism shall allow the consumer, or their authorized agent, to verify the status of the consumer’s deletion request.”

• Cal. Civ. Code § 1798.99.86(e)(1): “Beginning January 1, 2028, and every three years thereafter, a data broker shall undergo an audit by an independent third party to determine compliance with this section.”

• Cal. Code Regs., tit. 11, § 7613(b)(1)(C): “‘delete’ means permanently and completely erasing the personal information from existing systems, including archived or backup systems, deidentifying the personal information, or aggregating consumer information …”

• Cal. Code Regs., tit. 11, § 7614(b)(2)(A): “Record deleted” is reported when the broker matched the identifier “and deleted the consumer’s personal information associated with a matched identifier as required in section 7613(b).”

• Conn. Pub. Act 26-64, § 5(a)(1)(B)(ii): the mechanism shall permit a consumer to “determine the status of the consumer’s deletion request.”

• Conn. Pub. Act 26-64, § 5(e): “The Commissioner of Consumer Protection may enter into a contract with one or more public or private entities (1) for any services necessary to implement the provisions of subsections (a) to (d), inclusive, of this section, (2) to administer the accessible deletion mechanism program established pursuant to subsection (a) of this section, or (3) to administer a multistate accessible deletion mechanism program.”

• Vt. Act 138 (2026), Sec. 2(a)(1)(M): the mechanism under study “allows the consumer or their authorized agent to verify the status of the consumer’s deletion request.”

References

“Atlas Data Privacy Corp. v. We Inform, LLC.” 2026. No. A-8-25 (N.J. Aug. 12, 2026).

California Legislature. 2023. “Senate Bill 362 (2023), the Delete Act, Stats. 2023, Ch. 709.”

———. 2025. “California Civil Code § 1798.99.86 (Delete Act; as Amended by Stats. 2025, Ch. 466).”

———. 2026a. “Assembly Bill 883 (2025–2026 Reg. Sess.), Stats. 2026, Ch. 507.”

———. 2026b. “Senate Bill 923 (2025–2026 Reg. Sess.), Consumer Privacy Requests: Deletion Request Records and Request Submission Methods, Stats. 2026, Ch. 482.”

California Privacy Protection Agency. 2026a. “Cal. Code Regs., Tit. 11, § 7022 (Requests to Delete).”

———. 2026b. “Cal. Code Regs., Tit. 11, §§ 7613–7614 (Delete Request and Opt-Out Platform Regulations).”

———. 2026c. “Consortium of Privacy Regulators (Press Release).”

———. 2026d. “Data Broker DROP Compliance Audits: Text of Proposed Regulations, §§ 7630–7633.” Board meeting materials, August 6–7, 2026.

———. 2026e. “Data Broker Registry (Bulk CSV Export).” https://cppa.ca.gov/data_broker_registry/registry.csv.

———. 2026f. “Delete Request and Opt-Out Platform (DROP) Audits.” https://privacy.ca.gov/laws-and-regulations/drop-audits/.

———. 2026g. “DROP Data Broker Deletions: How Do They Work?” https://privacy.ca.gov/2026/07/drop-data-broker-deletions-how-do-they-work/.

———. 2026h. “DROP FAQ: 10 Common Questions about DROP.” https://privacy.ca.gov/2026/10/drop-faq-blog/.

———. 2026i. “Enforcement Advisory No. 2026-01: Accuracy of Data Broker Registration Information.”

Connecticut General Assembly. 2026. “Public Act 26-64 (Substitute Senate Bill 4), an Act Concerning Consumer Privacy and Protection.” https://www.cga.ct.gov/2026/act/pa/pdf/2026PA-00064-R00SB-00004-PA.pdf.

Control D. 2026. “Data Brokers Received 58.0 Million Requests to Delete Personal Data Last Year and Refused Nearly 900,000, California Filings Show.” https://controld.com/blog/data-broker-report/.

Federal Rules of Evidence. 2024. “Fed. R. Evid. 803(6) and 901(a).”

Garg, Sanjam, Shafi Goldwasser, and Prashant Nalini Vasudevan. 2020. “Formalizing Data Deletion in the Context of the Right to Be Forgotten.” In Advances in Cryptology – EUROCRYPT 2020.

Gueorguieva, Anna-Maria, Jennifer King, Apoorva Panidapu, and Daniel E. Ho. 2026. “Privacy Without Remedy: An Assessment of Data Broker Compliance with California Privacy Law.” In Proceedings of the 2026 ACM Conference on Fairness, Accountability, and Transparency (FAccT ’26). https://doi.org/10.1145/3805689.3812413.

“hiQ Labs, Inc. v. LinkedIn Corp.” 2022. Federal Reporter, 4th Series 31: 1180.

IAPP. 2026. “CalPrivacy Discusses DROP Enforcement, Data Broker Fee Hike.” https://iapp.org/news/a/calprivacy-discusses-drop-enforcement-data-broker-fee-hike.

International Auditing and Assurance Standards Board. 2009. “International Standard on Auditing 500: Audit Evidence.”

Kempen, Elina van, Isita Bagayatkar, Pavel Frolikov, Chloe Georgiou, and Gene Tsudik. 2025. “Consumer Beware! Exploring Data Brokers’ CCPA Compliance.” arXiv:2506.21914v2.

Kempen, Elina van, Gene Tsudik, Pragya Jhunjhunwala, and Mihir Raja. 2026. “Let My Data Go: Data Brokers’ Compliance with Opt-Out and Deletion Requests.” arXiv:2607.04552v1 (preprint).

Klensin, John. 2008. “Simple Mail Transfer Protocol.” RFC 5321.

Levine, John, and Mark Delany. 2015. “A ‘Null MX’ No Service Resource Record for Domains That Accept No Mail.” RFC 7505.

Mantelero, Alessandro. 2026. “One-Stop-Shop Thematic Case Digest: Right to Object and Right to Erasure.” European Data Protection Board, Support Pool of Experts programme.

Merriam-Webster. 2026. “Verify.” Merriam-Webster.com Dictionary.

New York State Senate. 2026. “Senate Bill S9088-A (2025–2026).”

“Palmer v. Hoffman.” 1943. United States Reports 318: 109.

Power, Michael. 1997. The Audit Society: Rituals of Verification. Oxford University Press.

Public Company Accounting Oversight Board. 2010. “AS 1105: Audit Evidence.”

Raji, Inioluwa Deborah, Andrew Smart, Rebecca N. White, Margaret Mitchell, Timnit Gebru, Ben Hutchinson, Jamila Smith-Loud, Daniel Theron, and Parker Barnes. 2020. “Closing the AI Accountability Gap: Defining an End-to-End Framework for Internal Algorithmic Auditing.” In Proceedings of the 2020 Conference on Fairness, Accountability, and Transparency, 33–44. https://doi.org/10.1145/3351095.3372873.

Solove, Daniel J. 2023. “The Limitations of Privacy Rights.” Notre Dame Law Review 98.

Sommer, David Marco, Liwei Song, Sameer Wagh, and Prateek Mittal. 2022. “Athena: Probabilistic Verification of Machine Unlearning.” Proceedings on Privacy Enhancing Technologies 2022 (3).

U.S. House of Representatives. 2026. “H.R. 8413, 119th Cong. (2026).”

“Van Buren v. United States.” 2021. United States Reports 593: 374.

Vermont General Assembly. 2026. “Act 138 of 2026 (H.211), an Act Relating to Data Brokers and Personal Information.” https://legislature.vermont.gov/bill/status/2026/H.211.

Disclosure

I run Sirveil, a California company whose service reports whether a named person's information is publicly indexed at a named website, as INDEXED, NOT INDEXED or INDETERMINATE. The paper's standard uses three similar states, and the paper says so. Nothing in it claims that outside observation confirms a deletion. I have a commercial interest in how deletion and verification get regulated, and I disclose it wherever I write.

---

Comments and corrections are welcome at contact@sirveil.ai. NONE OF THIS CONSTITUTES LEGAL ADVICE.