Your signed-off data-flow diagram shows personal data leaving the EU through exactly one named processor. A platform team then adds a tracing agent that captures request bodies on error, and its collector exports to a log store in another region with 400-day retention. What happens, step by step, and what stops it?

What happens, step by step

1. The agent is rolled out as a platform change. It touches no application code and appears in no application design review, so no artefact anybody consults has changed.
2. On error, request bodies are attached to spans. A minority of requests carry email addresses, names or addresses in the body, so the sampled error traffic carries personal data even though the happy path does not.
3. The collector's exporter is configured per environment. One of those configurations points at a shared log account in another region, which is where the data crosses the boundary the diagram says it cannot cross.
4. Retention is 400 days, which is longer than the application's own retention for the same fields, so the copy outlives the record it was copied from. A deletion request satisfied against the application leaves the traces intact.
5. Nothing alerts. The diagram, the register and the processor list all remain internally consistent and all describe a system that no longer exists.

Where it amplifies

The log store is shared, so access is broader than the application database's: support engineers, platform engineers, and anything with a read role for debugging. A flow that was one processor under contract becomes an unbounded internal audience, which is usually the more serious finding. Backups and cross-region replicas of the log store multiply copies, and if an index is rebuilt the data is re-derived from the raw store rather than from the application, so purging the source does not purge the derivative.

What the user sees

Nothing, ever. There is no latency change, no error, no failed request. This class of problem has no operational symptom at all, which is why it is normally found by an auditor, a subject-access request that comes back inconsistent, or a penetration test. That is between months and years after it started, with 400 days of accumulated data.

Why the diagram was not wrong

This matters for how you fix it. The diagram was an accurate description of the application, and the system changed outside the application's change process. Any control that lives in application design review cannot catch it. Telemetry, backups, analytics exports and support tooling are the four flows data-flow diagrams systematically omit, for the same reason: they are added by platform teams to many applications at once.

What stops it

• Treat telemetry as a flow on the diagram, with its store, its region and its retention written on it. If it is not on the picture, it is not in anybody's mental model.
• Reconcile the diagram against the egress path rather than against memory. The destinations in network flow logs or the collectors' exporter configuration, grouped by destination region, are machine-readable and complete. Any destination region not on the diagram is a finding. This is a weekly job, not a yearly one.
• Structural prevention beats detection: strip or hash at the agent so bodies never enter the pipeline, pin collector exporters to in-region stores by policy so the configuration cannot point out of region, and set telemetry retention below the application's for the same fields.
• Put the telemetry pipeline's owner on the diagram's review list. The diagram's reviewers are currently the wrong people.

When this is the wrong answer

For a system holding no personal data and no regulated content, this discipline is overhead; the tracing agent is an unambiguous win and the retention is a cost question. The moment one field is personal or contractual, the telemetry pipeline inherits the same obligations as the database, and teams almost never notice the moment that happens because it arrives with a product feature rather than with an architecture change.