By Yair Knijn · May 14, 2025

You deleted the data. You just can't prove it. The GDPR trap directors walk into.

An erasure request comes in. The compliance lead opens the customer record, runs a DELETE, closes the ticket. The row is gone, and the line to the regulator writes itself: "we erased it." Except that record arrived as a CSV over SFTP. An ETL job picked it up, dropped it in a staging directory, archived a copy for replay, and forwarded it to a partner whose inbound queue you do not control. Five copies, one delete.

Article 17 is not satisfied by removing the authoritative copy. It is satisfied when every copy is gone and you can demonstrate it. File transfer is the exact layer where copies multiply without anyone noticing, and where "we deleted it" becomes false without anyone noticing either.

Where a transferred file actually lives: staging, archive, partner queue

One inbound file almost never sits in one place. The mover writes it to an ingest folder, copies it to /staging for validation, then promotes it to /processed or /archive so you can replay it during a dispute. Failed transfers retry, and the retries pile up in a dead-letter or .error directory that nobody sweeps. The same payload goes back out to a partner who holds it in their own inbound queue, under their retention policy, not yours.

The application owner who handles the erasure request deletes the record they can see. The folders are invisible to them. They belong to an integration team, or to a server somebody stood up years ago that is now "just working." That is where the subject's personal data quietly outlives a deletion that everyone signed off as complete.

Article 17 erasure versus 'we ran a delete'

Article 17 requires the controller to erase personal data without undue delay. Where the data was disclosed to recipients, Article 19 requires you to communicate that erasure to each recipient, unless doing so proves impossible or disproportionate. A partner endpoint that received the file is a recipient. Forwarding the file and then forgetting you forwarded it does not discharge the obligation.

Supervisory authorities are paying attention to exactly this. The European Data Protection Board has run a coordinated enforcement action centered on the right to erasure across dozens of national regulators, with several opening formal investigations off the back of it. Erasure draws scrutiny because it is one of the most frequently exercised rights and one of the most complained-about. When a regulator asks how you handled a deletion, "we ran a delete on the database" is the answer that invites the follow-up you cannot answer.

What deletion proof and retention evidence look like to a regulator

An auditor is not asking whether you meant to delete. They are asking you to evidence it: an immutable record showing the data existed, where it was copied, and that each copy was destroyed, with timestamps and the identity behind every action. For a transferred file, that proof has to span every hop.

• The original transfer: who sent it, when, which file, into which directory.
• Every derived copy: the staging, archive, error, and outbound queues the file touched.
• The deletion event per copy: timestamp, actor, and the path or endpoint cleared.
• The Article 19 notice: proof you told the partner recipient to erase their copy.

If your retention policy purges inbound files after 90 days, you also need logs proving the purge actually ran, not a cron job that was supposed to. A configured policy states an intention. A log of executed deletions is the evidence.

Retention and proof built into the transfer, not bolted on after

You cannot reconstruct deletion proof for sprawl you never tracked. So make the transfer system the record. Track every file from receipt through each copy it spawns. Enforce retention per route and log the execution. Capture partner forwarding so an Article 19 notice is a query rather than an archaeology project. Once erasure is a search across one audit trail instead of a hunt through mystery folders, "we deleted it" arrives with proof attached.

xEvolve runs your transfers inside one governed Environment where staging, archive, and partner hops share a single audit trail and retention is enforced per route, so an erasure request becomes provable rather than hopeful. See how the audit and retention model handles deletion evidence end to end.