From the audit · Pipelines

The quiet version of a privacy problem

Nothing was leaked. No attacker was involved, no bucket was public, and every access was authenticated and logged. What the audit found was narrower and more ordinary: 50 log sources were sending records containing email addresses in cleartext, roughly 30.7 million records a day, into a store that anyone with query access could search.

That is not a headline. It is, however, personal data processed without anyone having decided to process it, retained for as long as the bucket says, and searchable by a population wider than anybody had thought about — which is the definition of the problem that regulators actually encounter.

Why it is almost always the default

Application logs are written for debugging, and an email address is the single most useful debugging key there is. Nobody adds it to a log line as a data-processing decision; they add it because the alternative is a support ticket that cannot be traced to an account.

Ingest is where that becomes a platform decision rather than a developer one — and ingest configuration is usually set up once, for the first few sources, and then inherited by every source added afterwards without review.

What the check does and does not do

It counts pattern matches per source and reports the source and the rate. It does not extract the matched values, does not store them, does not transmit them, and the report quotes none of them. A finding that had to quote the data in order to prove the data existed would be a worse problem than the one it describes.

It also does not tell you whether you have a legal problem. We are not lawyers and the report does not offer an opinion; it establishes what is arriving, where, and at what rate, which is the input your privacy counsel needs and currently does not have.

The shape of the query

Counting matches per source without reading them — this is the logic behind the finding:

The fix is upstream, and it is cheap

A masking rule at ingest stops new personal data landing in queryable storage, and it applies from the moment it is saved. It is the cheapest control in the platform and the one most often missing, because it protects against something that has never visibly gone wrong.

What masking does not do is anything about the records already stored — that is a retention question, and it lands in a different domain of the audit with a different, harder decision attached. Fix the inflow first; it is the half you can fix today.

The finding behind this piece

The takeaway

Personal data in logs is not usually a failure of care. It is the absence of a rule that nobody was ever prompted to write.

More from the series

The $91,576 question: Full-Stack hosts with nothing monitored on them From the audit · FinOps The Grail bucket nobody chose: 462 days of retention From the audit · Grail 1,617 maintenance windows: how alerting goes quiet without anyone deciding From the audit · Alerting What actually lands on a DPS invoice From the audit · FinOps

An audit takes one run. The findings take one meeting. What you do with them is up to you.

Certified Dynatrace experts

Send

Obzervability

Privacy Terms of use Accessibility