By Yair Knijn · February 13, 2026

Your retention policy says 90 days. The SFTP archive has files from 2019.

You are the GRC lead. You wrote the data retention policy, got it signed off, and filed it in the ISMS. It says regulated payment and PII files live for 90 days, then get deleted. Buried in that one sentence is an assumption: that "the policy says 90 days" and "the system enforces 90 days" describe the same fact. They do not.

Then a litigation hold lands. Counsel asks for everything you hold on a counterparty, someone runs a recursive listing on the SFTP server, and the oldest file is dated 2019. You are now sitting on six years of regulated data your own policy says you destroyed, and your signature is on the document that proves you knew the rule.

Policy on paper versus enforced lifecycle on disk

A retention policy is a control objective. It becomes a control only when something on disk acts on it. The gap between those two states is where the trap lives. Nobody wrote a deletion job, because deletion felt like an operations task. Operations never read the policy, because it lived in a GRC tool they do not open. So the /inbound and /archive directories just grow, since the default behaviour of any file-transfer server is to keep what it receives.

That is the worst posture available to you. A policy documenting 90-day retention while the disk holds years is not a partial control. It is evidence. You have written down the standard you failed to meet, in language a regulator or opposing counsel can read straight back to you. No policy at all is a gap. A policy you provably never enforced is closer to an admission.

How transfer archives turn into unbounded data hoards

File-transfer systems hoard for dull, structural reasons. Files arrive faster than anyone audits them. Archive directories exist so a failed batch can be re-pulled, and then nobody prunes them. An operator adds a "keep a copy just in case" rule and never defines the "in case". Backup snapshots quietly fork a second, longer-lived copy of everything the live system ever held.

That last one is where most programs go blind. Recent EU coordinated enforcement work on the right to erasure found a recurring theme: controllers with no procedure for erasing personal data from backup systems, and in some cases no erasure from backups at all. You can ship a clean 90-day delete on the live SFTP tree and still over-retain for years inside snapshots nobody mapped. GDPR Article 5(1)(e), storage limitation, does not care which copy it is. If the data is still identifiable, it still counts against you.

Over-retention is the discovery risk, not a safety margin

Keeping files past their purpose is not free insurance. Every extra file is one more thing that is discoverable, one more thing inside the blast radius of a breach, one more thing a regulator can cite as a storage-limitation violation with no breach required. A litigation hold sharpens all of this: the hold has to preserve specific data tied to a specific matter, but you cannot scope it cleanly across an archive whose contents you never inventoried. So legal preserves everything, the hold never lifts, and the hoard ratchets up again.

The defensible position runs the other way. You delete on schedule, by default, and you keep proof that you did. When a hold arrives, you suspend deletion for the named scope only, and you can show exactly what stayed and why. That demands a lifecycle living in the transfer layer, not in a PDF.

Automated retention and deletion proof at the transfer layer

Enforcement at the transfer layer means three concrete things, and you should be able to demonstrate every one on demand:

• A per-route retention rule that runs on its own. Files in a regulated /inbound path expire on a clock, not on someone remembering.
• A deletion event in the audit log for every removed file, so "we deleted it" is a record rather than a claim.
• A hold mechanism that suspends expiry for a scoped set without freezing every other route into the same unbounded archive.

If you cannot produce the deletion log, you did not enforce the policy, whatever the document says. xEvolve attaches retention rules to the transfer route inside an Environment, expires files without an operator in the loop, and writes every deletion to the same unified audit trail as the transfer itself, so the proof and the act are one record. See how the lifecycle is wired on the security page.