A privacy product tells a user that her personal data has been removed from data broker sites. Every test in the suite passed. Was the data removed? Most test suites cannot answer that question, and this article explains why, and what to do about it.
Author: Yevheniia Sakovets, https://yevheniiasakovets.com/
Consumer privacy and security software makes a specific kind of promise. It does not promise a feature; it promises that something happened. Your data was deleted. Your password is encrypted. Your files were wiped. Your credentials have not appeared in a breach. The user cannot check any of these claims. That is the whole reason she bought the product.
I have spent the last year owning quality for exactly this kind of software, and before that thirteen years verifying data as it moved across systems in fintech, e-commerce, medical devices, and a loyalty platform with tens of millions of users. The defect class described here is the one that worries me most, because it does not look like a defect. It looks like success.
I call it a silent protection failure: the software reports that a protective operation has completed, and it has not.
Why every test passes anyway
Think about how a deletion request actually travels. The user enters her name, email, and address in the interface. The interface sends that to an API. The API hands it to a backend service. The backend builds a request to an external party, in this case a data broker, and sends it. Something comes back. The backend records a status. The API serves that status to the interface. The interface shows the user a green check and the word Removed.
That is at least six handoffs, and every one of them is a place where data can be altered, dropped, or never delivered while the next layer carries on as if nothing happened. An empty response from the broker can be parsed as success. A queued request can be recorded as sent. A request that failed for three of five brokers can produce an aggregate status of Complete. A field that the interface collected can be silently trimmed before it reaches the backend, so the deletion is filed under a name that matches nothing.
Now think about how we normally test this. Feature-level testing checks each layer against its own specification. The interface test confirms that the form submits and the status renders. The API test confirms that the endpoint accepts the payload and returns a well-formed response. The backend test confirms that a request object is built and a status is written. Each layer does exactly what it was asked to do. Each test passes. And the protective operation may never have occurred.
The reason is structural, not a matter of effort. Feature-level tests take the system’s own report as the oracle. When the interface says Removed, the test agrees, because the interface is what the test is checking. Nobody is checking the interface against reality. In this category of software, the interface is the last thing you should trust, because it is the layer furthest from where the work actually happens.
Borrowing an idea from evidence handling
In legal and forensic work, evidence has to travel through many hands: the scene, the collecting officer, the lab, storage, the courtroom. The rule that makes this trustworthy is the chain of custody. Every transfer is documented and accounted for, because a single undocumented handoff makes everything downstream unreliable. It does not matter how careful the lab was if nobody can prove what arrived at the lab.
User data in a privacy or security product travels the same way, and I started treating it the same way. Instead of testing features, I follow one piece of user data from the moment it enters the system to the moment the system tells the user what happened to it, and at every handoff I ask whether it is still what it was. I have come to call this Chain of Custody Verification, or CoCV, because the name states the discipline: the chain is only as good as its weakest documented link.
What Chain of Custody Verification actually checks
The method reduces to a small set of questions asked at each transition rather than at the end.
Did the data arrive complete? What the user submitted should reach the backend with every field intact. This sounds trivial until you find a whitespace trim or a length limit quietly dropping part of an address.
Was the operation actually dispatched? A record that says Sent is not evidence of sending. The check is whether an outbound request left the system and reached its destination, not whether a row was written.
Was the response interpreted, or assumed? Empty, ambiguous, and error responses from external parties must be handled as what they are. The most common silent failure I see is a default branch that maps anything unexpected to success.
Does the recorded state match the real outcome? Reconcile the internal status against downstream evidence, not against the request log.
Does the user see the truth? The status in the interface should be derived from the reconciled state, and the check should compare the two directly.
What happens on partial failure? If some of the operation failed, the system must not report the whole as complete.
Is the data protected in transit and at rest along the way? At every hop, confirm it is not sitting in cleartext in a log, a queue, or a cache where it should not be.
Does the effect persist? Deletion that quietly reverses, or suppression that lapses, is a failure that only appears if you look again later.
Do telemetry and metrics agree with what happened? If your dashboards are built on the same status field the interface uses, they will be just as wrong.
None of these checks is exotic. What is different is that they are applied across layers rather than within one, and that the oracle is the actual downstream state, never the system’s own report of it.
Where AI helps, and where it does not
Comparing values across six layers by hand for every operation is not sustainable. This is the part of the work where AI assistance earns its place. Once the chain is defined and the verification points are instrumented, an AI-assisted analysis layer can consume the state captured at each transition, identify where two adjacent layers disagree, localize the transition where the divergence began, and classify it as a defect with the evidence attached. It turns a manual reconciliation across three or four systems into something that runs on every build.
But the order matters, and I want to be direct about it because the reverse order is what I see failing in other teams. If you hand a language model a codebase and ask for tests, you will get plausible tests that check each layer against itself. That is the failure mode we started with, automated. The model does not know which transitions carry protective claims, what the external party’s real responses look like, or what the user was actually promised. The architecture has to define what must be verified and where. AI is then applied to that defined set of transitions, where it is very good. Systems understanding first, AI on top of it, not instead of it.
What changes when you test this way
Three things, in my experience.
First, you start finding a category of defect you were not finding before, and the ones you find tend to be severe, because they sit exactly where the product’s promise is made. A crash is a bad day. A deletion that silently did not happen is a user who is exposed while believing she is protected, for as long as nobody looks.
Second, your conversations with engineering change. Instead of arguing about whether a test is flaky, you are showing a trace: here is what the user submitted, here is what reached the backend, here is what went to the broker, here is what came back, here is what the interface said. The divergence is a fact, not an opinion.
Third, your quality reporting stops depending on the status field. When your metrics are built on reconciled state rather than reported state, they survive the question every QA lead eventually gets asked: if everything is green, why did this reach a customer?
The standards already ask for this
If this sounds like something quality standards should cover, they do, up to a point. ISO/IEC 25010 names functional correctness, integrity, and accountability as required product quality characteristics. ISO/IEC 25012 names accuracy, consistency, and traceability as required data quality characteristics. Traceability in particular is the property CoCV verifies and feature-level testing does not. What the standards do not supply is a technique. ISO/IEC/IEEE 29119-4 catalogues test design techniques, and every one of them verifies behaviour inside a defined system boundary. A silent protection failure lives between boundaries. CoCV is my attempt to fill that gap in practice, and I am publishing the methodology and a reference implementation so other teams can test it against their own systems – https://yevheniiasakovets.com/cocv/.
The stakes are also no longer purely a matter of good engineering. Deletion claims are becoming verifiable obligations. California’s Delete Request and Opt-Out Platform opened to consumers in January 2026, and since August 2026 registered data brokers have been required to process and report on deletion requests under penalty. Consumers exercise these rights through software. Whether that software actually did what it said is now a question with a regulatory answer, and someone has to be able to test it.
How to start
You do not need a framework to begin. Pick one protective claim your product makes to the user. Draw the chain: every layer the data crosses between the user’s action and the user’s confirmation. At each handoff, write down what should be true about the data on the far side. Then go and check the far side directly, not through the interface. For the first claim, do it by hand. You will learn more about your system in an afternoon than the regression suite has told you in a year.
When you have found the transitions that matter, instrument them, and only then bring in tooling to compare and classify. If you do it in that order, the automation will be checking the right things. If you do it in the reverse order, you will have a very fast way of confirming what the interface already told you.
References
1. ISO/IEC 25010:2023, Systems and software engineering, Systems and software Quality Requirements and Evaluation (SQuaRE), Product quality model.
2. ISO/IEC 25012:2008, Software engineering, SQuaRE, Data quality model.
3. ISO/IEC/IEEE 29119-4, Software and systems engineering, Software testing, Part 4: Test techniques.
4. California Privacy Protection Agency, Delete Request and Opt-Out Platform (DROP), data broker obligations, https://privacy.ca.gov/data-brokers
5. Yevheniia Sakovets, “QA Metrics That Still Mean Something in the AI Era“, Software Testing Magazine, July 2026 (metrics built on reported versus reconciled state).
About the Author
Yevheniia Sakovets is a quality engineering lead with 13 years of experience in software testing, test automation, and AI-assisted quality engineering across fintech, medical device software, e-commerce, and consumer security. She currently owns quality for consumer privacy software and is the author of the Chain of Custody Verification methodology. She holds a Bachelor’s degree in Computer Science and a Master’s-level degree in Information Systems, and is PMP, ISTQB, and SAFe Agilist certified. She will present “Leading QA in the Age of AI” at PNSQC 2026 in October.
Leave a Reply