Privacy rights have an infrastructure problem.

Late last month, WIRED senior writer Reece Rogers ran a simple experiment. As a California resident, he spent a week sending more than 100 companies a request under the California Consumer Privacy Act asking for a copy of the personal data they held about him. Not a deletion request. Not an opt-out. An access request, stated as plainly as the law allows.

Some companies handled it. McDonald's sent back a 515-page report covering app interactions and inferred behavior – exactly what the right to know is supposed to produce.

Others produced a catalog of failure modes. Crunchbase told him his account had been permanently deleted, then clarified that other records remained; the company called it a processing error and said it would proceed with the original access request. BeenVerified said it had removed his report, phone number, and email from search results, then said it couldn't verify his identity, then characterized the whole thing as an opt-out. Its parent company acknowledged the support agent had misunderstood the request and promised retraining and an audit. Cash App's privacy policy listed a phone route for requests; callers were redirected to the app or website instead, on the grounds that identity verification is faster online.

One reporter, one week, one state's law. It isn't a statistical audit. But the pattern it surfaced is one I've watched from inside privacy programs for two decades, and it deserves a clearer diagnosis than "companies aren't trying hard enough."

The words are fine. The plumbing isn't.

Every one of those companies almost certainly has a privacy notice that describes the right to know, the right to delete, and the right to opt out as separate rights with separate handling. The legal team wrote it correctly. The problem is what happens after the notice.

A privacy request lands in a support queue. The person who picks it up has a set of tools built for the work support teams actually do all day: closing accounts, removing listings, unsubscribing people. There is rarely a tool for "assemble every record we hold about this individual across every system and produce it in a readable form." So the rep maps the unfamiliar request onto the familiar button. Sometimes nothing happens. Sometimes the wrong thing happens.

That isn't malice, and it usually isn't even negligence in the way regulators think about it. It's what a policy looks like when it has no infrastructure underneath it.

And this isn't only visible in one reporter's inbox. A Stanford RegLab and HAI study presented at FAccT this year reviewed all 522 data brokers registered in California and examined a stratified sample of 250 in detail. Only 9.2% were fully compliant with the transparency requirements. Forty-three percent did not allow consumers to exercise all six of their rights. Sixty-four percent had at least one design feature in the request process that increased friction. Thirty-seven percent required identity verification to exercise the do-not-sell right, which California law does not permit.

These are companies whose entire business is holding and moving personal data. If the request path is broken there, it is not better in a mid-market hospital system with fourteen SaaS vendors and a two-person privacy function.

Regulators have noticed the symptom. The law gives businesses 45 calendar days to respond, with a possible 45-day extension, and consumers in California can complain to the Attorney General or the California Privacy Protection Agency. But private lawsuits are generally limited to data breaches, and a complaint filed months later doesn't recover a record that was deleted by mistake in week one. Enforcement operates on paper. The failure happened in the systems.

What "infrastructure for privacy rights" actually means

If an organization wants access, correction, deletion, and portability to work the way its privacy notice promises, a few things have to be true at the system level:

• Identity resolution across systems. The organization has to be able to answer "which records, in which systems, belong to this person?" without a human guessing. Most data maps were built for a compliance filing, not for runtime lookup.
• Distinct, auditable operations. Retrieve, correct, delete, and restrict have to be separate actions with separate logs. A deletion that can't be distinguished from an opt-out in the audit trail is a deletion that can't be defended.
• Deletion that reaches everywhere the data went. Primary databases, replicas, backups, disaster-recovery snapshots, analytics warehouses, and every downstream processor and subprocessor. A deletion that clears the production table and leaves six copies elsewhere is a deletion in name only.
• Evidence, not attestation. "We deleted it" is a promise. A system-level record of what was deleted, from where, when, and by what mechanism – with exceptions documented and justified – is proof.

Most organizations have some of this for their own front-end systems. Almost none have the last two.

The failure point is the system boundary

Here is the part that gets skipped. Assume an organization solves the internal problem completely. It builds the portal, resolves identity across systems, distinguishes the four operations, logs everything. A consumer submits a valid deletion request and the company executes perfectly against every system it controls.

The organization can send instructions downstream. Then what? Did every vendor identify the right records? Did they delete from the systems in scope, or only the ones that were easy? What happened in backups and archives? Did the instruction reach the subprocessors the vendor uses? What evidence came back, who evaluated it, and against what standard? What happens when a vendor simply doesn't respond? And six months from now, can anyone reconstruct what actually occurred?

These are not policy questions. They are infrastructure questions, and almost no one has infrastructure for them. The consumer's right terminates, quietly, at the edge of the first company's network.

The same gap, at contract scale

Now change the unit from one person to one organization.

A contract ends. The agreement almost certainly requires the vendor to return or destroy the data within some window after termination. But that request doesn't go to a consumer support queue – it goes to an account manager, or to no one at all. The mechanism is the same one Rogers ran into: a person, a set of tools built for something else, and a great deal of improvisation.

If a company can't reliably distinguish an access request from a deletion request for one individual, how confident should a hospital, a bank, or a university be that a former vendor actually purged their records across production, backups, and subprocessors? The honest answer is: not very. And unlike the consumer case, there is usually no one on the other side checking. The clause was negotiated, the relationship ended, and everyone moved on.

Every regulated organization already has contracts that require return or destruction. Almost none can prove it happened. The problem runs in both directions: an organization can't show that its vendors deleted its data, and it can't show its own former clients that it deleted theirs. Every customer is also somebody's vendor.

What proof looks like

This is the gap Fimi Data was built to close, and the design assumption is simple: a certificate of destruction is not evidence. It's an attestation, and attestations are exactly what the WIRED experiment shows to be unreliable when there's no system behind them.

When a contract ends, we pull the deletion obligations from that contract and put them in front of the vendor. The vendor submits an evidence package – deletion certificate, system-level deletion evidence, a backup and disaster-recovery statement, the subprocessor deletion chain, and an exception register for anything that legitimately has to be retained. That package gets scored. Adequate evidence across the checklist earns a strong score. A signed letter with nothing behind it does not.

There are human decision points, deliberately, because a privacy or third-party-risk lead needs to see the exceptions and decide whether they're acceptable. What changes is that the decision is made against evidence instead of against a promise, and the record of that decision survives the relationship.

The consumer story and the enterprise story are the same story

It's tempting to read the WIRED piece as a consumer-rights problem and leave it there. But the root cause – organizations that wrote the right words and never built the systems to back them – doesn't stop at the individual. It shows up in every contract termination, every vendor migration, every M&A carve-out, every offboarded subprocessor.

We have spent twenty years building infrastructure to collect, share, classify, and monetize data. We have built almost nothing for the end of the data lifecycle. Privacy law gave people rights; it didn't give organizations the means to fulfill them. Until that changes, rights on paper will keep failing the people they were written for, and contract clauses on paper will keep failing the organizations that negotiated them.

The right to delete matters. The ability to execute and prove deletion is what makes the right real.

Sources

• Reece Rogers, "I Asked 100 Companies for My Data. I Got Deletion Notices Instead," WIRED, August 2026.
• Gueorguieva, King, Panidapu & Ho, "Privacy Without Remedy: An Assessment of Data Broker Compliance with California Privacy Law," FAccT '26.
• California Consumer Privacy Act, Cal. Civ. Code § 1798.100 et seq.