Not a vulnerabilityA fault in a measurement, not in a system. Nobody is at fault except the measurement, and the party that ends up described as clean may be anything but.
What it is
A capture produces little or no traffic and the conclusion drawn is that the subject collects little or nothing. In fact the run failed: the interception was refused by a pinned connection, the environment was detected, the session was too short, the page never rendered its heavier components because too many captures ran at once, or the traffic arrived but no request bodies were readable. Nothing distinguishes an empty result from a clean subject unless validity is established separately from content.
Why it is a separate entry
A false negative is published as reassurance, and reassurance is harder to withdraw than an accusation. It also breaks comparison: a set in which some runs failed silently ranks the subjects by how well they were measured rather than by what they do.
How it arises
many captures run in parallel, starving the heavier components so they never execute
interception blocked on exactly the channel that carries the sensitive payload, while other channels decrypt normally
a capture from an address the subject treats differently, so a different version of the subject was measured
a session that ends before behaviour that fires on scroll, on login or after a delay
an extraction pattern narrower than the field names in use, so present values are counted as absent
Not to be confused with
A subject that genuinely does nothing observable is a negative finding worth publishing. This entry is about the step before it: whether the run was capable of showing the thing it reports as absent.
How to establish it
A control run of the same subject, in isolation and with the same behaviour performed, produces traffic that the original run does not. Alternatively the capture itself fails a validity check: components present in the delivered code produced no traffic at all, or the capture contains flows but no readable request bodies.
method differentialQoD 90
Requirements on the measurement
record run validity separately from run content: did traffic arrive, was it readable, did the session last long enough, was visitor-like behaviour performed
record concurrency, since parallel captures compete for the same resources and heavy subjects lose
keep an idle baseline of the measurement environment, so traffic belonging to the platform is not charged to the subject
state each negative as a count over valid runs, never as 'not seen'
What would refute it
automatedA control run in isolation produces the same empty result.The negative then stands, and it stands much more strongly for having been tested.finding falls
automatedThe run passed an explicit validity check recorded at the time.finding falls
by handThe subject is known to behave differently for the measurement environment, and that was recorded.Recording it converts a false negative into a stated limit, which is a legitimate finding.weakens
by handThe absence claimed is about a behaviour that had never been observed in the subject even when measurement worked.Establish how often it occurred while present before claiming it stopped. A behaviour that fires in half of sessions needs several runs before a single clean one means anything.weakens
Where this plugs into existing processes
The one question that surfaces itHow do you know your measurement would have seen it if it had been there?
In a DPIA, verify this
Verify that a supporting measurement recorded its own validity before accepting a statement that nothing was found.
As a procurement clause
Measurements delivered by a supplier report the number of valid runs behind every negative statement.
With a complaint, hand over
The number of valid runs, what the run was capable of observing, and a control run of the same subject in isolation.
Reproduction
METHOD.md · by hand · no dedicated reproduction exists yet; follow the general method and the indicator above
Legal framing
eu-gdpr-5-2
Objections, and the answer
“We measured and found nothing.”
Say how many valid runs that was, and what would have shown up had it been there. A count over valid runs is a finding; 'nothing seen' is not.
“The scan is automated, so it is consistent.”
Consistent failure is still failure. Automation makes an invalid run cheap to repeat, which is how a whole set acquires the same blind spot.
“The subject cleaned up after our questions.”
Possibly, and that is worth establishing properly: compare against the party's own machine-readable configuration rather than against the absence of traffic in one run.
What this does not establish
harm; the catalogue standardises a finding so it can be referred to, it does not weigh it
severity; there is no score here, by design. Weighing belongs to whoever applies the entry to a concrete case
unlawfulness; that is for a supervisory authority or a court
intent; a fault is usually a build decision, not a plan
absence: not finding it in one capture is not evidence that it is not there
DPE Catalogue. DPE-2026-0029: Failed capture read as a clean result. Schema 2.0, entry status active. Retrieved from https://totaledigitalewaarborging.nl/register/DPE-2026-0029
Measurement
When you publish a finding, cite the method version alongside the entry: “DPE-2026-0029, established under DPE Measurement Method 1.0”
Identifiers are permanent and are never
reused. An entry that is deprecated keeps its number and its address, with the reason attached, because
references to it exist elsewhere.