· Yair Knijn
A chain of custody for file transfers that survives an audit
It is a Friday afternoon. A counterparty emails asking for the data room contents the team sent them three months ago, and adds, by the way, can you prove exactly what was in the zip, who opened it, and from which IP. The answer, in most regulated firms, is a screenshot of a sent folder, a vague memory that the zip was password-protected, and a hope that the recipient's IT will find the file in a mailbox somewhere. That is not a chain of custody. It is a story.
Chain of custody is a term borrowed from evidence handling, and it means the same thing in a file transfer: a record that can be replayed, in order, by someone who was not in the room. It needs to be tamper-evident, because the moment the auditor suspects a backfill, the record loses its value. And it has to exist for the period of retention, not just for the moment of transfer.
What "we emailed it" actually produces
Email produces a copy of the message. It does not produce a proof of receipt. It does not produce a record of which device fetched the attachment. It does not produce a content fingerprint at the moment of access. It does not produce anything once the recipient deletes the message, which retention policies on the other side will eventually do. It produces, at best, the moment of sending. Chain of custody is a sequence; email is a single event.
Consumer file shares are slightly better but have the same shape. A link was created. A link was clicked. There is no per-file access log tied to a strong identity, and there is no signed acknowledgement that the recipient accepted the file as the version intended. When the auditor asks, the export is a CSV with click counts and a vague notion of "users" who may or may not be the people named on the engagement letter.
The five fields a custody record needs
A custody record that holds up under review has five fields, in this order, every time.
Who. The strong identity that requested the file, the strong identity that received it, and the environment or contract the exchange is bound to. Display names and email aliases are not enough. The record carries the directory object, the SSO subject, or the equivalent.
When. Server-side timestamps in UTC, captured at the moment the file was uploaded, the moment the recipient was granted access, the moment the recipient fetched the file, and the moment the retention window closed. The clock is one you control, not one the recipient can dispute.
From where. The IP address and, where the protocol offers it, the device fingerprint. Recipients can argue about the device, but the IP at access time is a hard fact, and the access log is the place to put it.
Which file. A content hash, computed at upload and recomputed at download, plus the manifest of what the recipient was supposed to receive. A signed manifest closes the gap between "a file was sent" and "this specific file was sent".
Signed receipt. A cryptographic acknowledgement from the recipient's session that they received the manifest and the file. This is the field that most platforms skip, and it is the one that converts a log into evidence.
Retention is not legal hold
Retention and legal hold are different things, and the distinction matters in evidence review. Retention is the default: a file lives for the period the policy says it should. Legal hold is the override: the file lives longer, immutably, because a matter is open. A custody record has to distinguish the two, because the moment a hold is lifted, the file is not destroyed; it falls back to its retention clock, and the audit trail has to show that hand-off.
A common failure mode is a platform that stores the file under one retention rule and the metadata under another. The file is held, the access log is pruned, and the auditor is told that yes, the file is available, but you cannot tell them who accessed it. That is the case where a year of legal counsel is wasted on a logging problem.
How xEvolve records it
xEvolve organises exchanges into Environments. Each Environment carries its own encryption keys, its own list of authorised recipients, and its own retention and legal-hold state. Files uploaded to an Environment are encrypted, and per-recipient access is enforced against that Environment rather than against a global share.
At delivery, xEvolve produces a signed delivery receipt and a download manifest. The manifest lists each file with its content hash, the recipient identity, the access time, and the source IP. The receipt is bound to the recipient's session and stored alongside the file's audit record.
For ISO 27001 A.8.10 (information deletion) and A.8.12 (data leakage prevention), xEvolve exports an audit pack per Environment, on demand. The pack includes the access log with actor, IP, and Environment context, the retention state at any historical date, and any legal-hold events that overrode that retention. SSO is available via Entra ID, Okta, and OIDC, so the identity in the custody record matches the identity in the directory the auditor already trusts.
What xEvolve does not do is decide retention for you. The period and the hold policy are choices the firm makes, and the platform records the choice with the file. The job is to make the record hold up; the policy is yours to set.