Chain of Custody, Explained for File Transfers

"Can you prove nobody changed it?" The question arrives in a meeting you were added to twenty minutes ago. A partner insists the payroll feed they processed is not the one your finance team exported. A compliance officer asks who touched a spreadsheet of patient results between the lab system and the archive. A lawyer asks, carefully, whether anyone could have altered a document on its way through your servers. Under every version is the same request: account for this file's journey — completely, with names and times — or admit that you can't.

That request has a name. Chain of custody is the documented, unbroken record of who had an item and when they had it. It records what — if anything — happened to it at each step. The idea comes from evidence handling, where it has been standard practice for generations, and it transfers to files with almost no modification. A file with an intact chain of custody can be trusted, defended, and handed to skeptical outsiders. A file without one invites a doubt that no amount of after-the-fact explanation removes.

This article is the foundation of our Chain of Custody series. It covers what a custody record contains and how custody differs from integrity and non-repudiation. It explains why a gap in the record does more damage than actual tampering. It also shows where in ordinary admin work these demands show up. The later articles build the record itself; this one makes sure the concept is solid first.

Where the Idea Comes From

Picture a physical evidence room. An officer collects an item at a scene, seals it in a bag, and signs a label: name, date, time. The bag goes to a clerk, who signs it in. An analyst signs it out to examine it, notes what was done, and signs it back in. Every handoff adds a line to a log that travels with the item. When the item is finally produced somewhere it matters, that log answers the skeptic's question. Is this the same item, in the same condition, and not something swapped, altered, or contaminated along the way?

What makes the system work is not the seal on the bag — seals can be discussed and disputed — but the continuity of the record. At no point does the item sit unaccounted for. Every interval of time belongs to a named person or a named place, and every transition between them is written down. The log does not prove the item was never touched; it proves that if it was touched, the record shows by whom and when.

Files deserve the same treatment the moment they matter, and the translation is direct. The evidence bag becomes the file. The signatures become authenticated accounts in transfer logs. The examination notes become hash values that show whether the content changed. The clerk's ledger becomes the logging on your transfer servers. Nothing about the concept is new. What is new for most admins is realizing that the materials already flow through systems they run every day. The record assembles cleanly or not depending on how those systems are set up.

The Three Questions a Custody Record Answers

Strip away the ceremony and a chain of custody answers three questions, continuously, for the whole life of the file.

Who had it? At every moment, the file was in the possession of someone or something you can name. That might be a named user account, a named service account running a scheduled job, a named server, or a named partner endpoint. "Possession" for a file means the ability to read or change it. So this question is really about which identities had access during each interval. An account called svc_ledger owned by a documented job is an answer. An account called ftpuser shared by an entire department is not, because it names a crowd, not a custodian. A custodian — the person or system responsible for the item during an interval — must be singular to mean anything. A crowd has never signed for anything.

When? Every event in the record carries a timestamp, and the timestamps line up into a continuous timeline with no unexplained intervals. This is where clock discipline quietly becomes evidence quality. If your origin server's clock runs four minutes ahead of your transfer server's, your own record appears to show a file arriving before it left. Our companion article on timestamps, clocks, and evidence covers why synchronized clocks and UTC logging turn timestamps from decoration into proof.

What changed? Between any two points in the journey, you can show whether the file's content is identical or different. The working tool here is the cryptographic hash — a short fingerprint computed from the file's bytes. It comes out identical only if the bytes are identical. Hash at the origin, verify at each hop, and the "what changed" question has a mathematical answer instead of a shrug. If hashing is new to you, read our plain-words explanation of hashes first. The custody-specific discipline of recording and storing those hash results is covered later in this series in using hashes as custody evidence.

The diagram below shows the shape you are building: a chain of intervals, each with a custodian, each handoff a recorded event. The chain is only as strong as its weakest link — and a missing link is the weakest of all.

Custody Is Not Integrity, and Not Non-Repudiation

Three ideas live close together in this territory, and admins who blur them end up with evidence that answers the wrong question.

Integrity asks: are these bytes the same bytes? Hashes answer it. A matching hash between origin and destination proves the content did not change in between — nothing more. Integrity is a property of the file at two moments in time. Our file integrity series covers the mechanics end to end.

Non-repudiation asks: can the party who sent or received this deny it later? Digital signatures and delivery receipts answer it. A signature binds a party's identity to specific content in a way that is hard to disown. That is a property of a single handoff, and the signatures and non-repudiation series is about exactly that.

Custody asks the bigger, connecting question: account for the whole journey, continuously. Integrity checks and signed receipts are the strongest individual links in a custody chain, but neither is the chain. You can have perfect hashes at both ends and still have a custody problem. A matching hash says nothing about who held the file for the six unlogged hours in the middle. During those six hours it could have been read, copied, or exfiltrated without a single byte changing. Custody is the narrative that strings the point-in-time proofs together and covers the intervals between them. I have produced that exact record once — hashes gleaming at both ends, six hours of nothing in the middle — and watched a room go quiet.

Why Gaps Destroy Trust Faster Than Tampering

Custody is unforgiving because of an asymmetry. Actual tampering is an accusation that has to be proven — someone must show that the content changed, when, and plausibly by whom. A gap — an interval the record cannot account for — has to merely exist. Nobody needs to show anything happened during the gap. They only need to ask, "can you show that nothing did?" and if the honest answer is no, the doubt is permanent.

A challenger attacking a file's history is rarely claiming to know it was altered; they are probing for any interval where alteration cannot be ruled out. A file may have spent an afternoon on a USB stick in someone's bag or passed through a personal email account. It may have sat in a shared folder that thirty people can write to. Each case offers exactly that interval. It does not matter that the person involved is trustworthy and the file almost certainly untouched. "Almost certainly" is precisely what custody exists to replace. Once a gap is on the table, every conclusion drawn from the file inherits the words "assuming nothing happened during the gap."

Northgate Retail learned the asymmetry the slow way. A supplier disputed a price file. The admin on the ticket could show the export, the upload, and the delivery, all logged and timed — with one exception. For forty minutes the file had sat in a shared "outgoing" folder the whole merchandising team could write to. Nobody believed anyone had touched it. Nobody could show it either. The dispute was settled by re-sending the file and re-running the supplier's import: two days, and one very quiet meeting. The following week the folder had two writers, both service accounts, and forty minutes stopped being a question.

The practical goal of custody work is therefore not tamper-proofing — no process makes tampering impossible — but gap elimination. That means designing the journey so that every interval is attributable and every handoff leaves a record automatically. An honest gap, found and documented, is also handled very differently from a hidden one. How custody breaks in real organizations, and what to do when you find a hole, gets a full article in breaks in custody.

Where Working Admins Actually Meet Custody Demands

Custody questions arrive through five ordinary doors, and the person expected to answer is whoever runs the transfer systems — not a forensic specialist, whatever the courtroom vocabulary suggests.

Partner disputes. The most common by far. A partner processed your file and got results you both dislike — wrong totals, missing records, duplicated entries — and each side suspects the other's copy. The resolution is a custody exercise: what did we send, exactly, and when, and what did they acknowledge receiving? Transfer logs plus an origin hash usually settle it in an hour. Without them, it becomes a week of email archaeology. The receipt side of this story is covered in proof-of-delivery patterns.

Regulated data flows. Health information, cardholder data, and financial reporting feeds all travel under frameworks — HIPAA, PCI DSS, SOX. Their assessors ask custody-shaped questions: who can access this data in motion, and how do you know? You are not asked to cite the regulations; you are asked to produce the record. What each context expects — receipts, named accountability, four-eyes handling — gets its own article later in this series.

Legal matters. When files become relevant to a dispute or an investigation, legal teams typically ask for two things from IT. Preserve the files and everything that documents their history. Be able to explain that history step by step. The division of labor keeps your job sane: the admin documents and preserves. The lawyers decide what to argue from it and fight about what a court will accept. Your record does not have to win the argument. It has to exist, be complete, and be honest. I have never been asked to win the argument; I have been asked, more than once, whether the log still exists.

Internal investigations. An HR or security matter turns on when a file left a folder and which account moved it. Here custody overlaps with insider risk, and the quality of your answer depends entirely on whether accounts are named and logging was on before the question arose.

Incident response. After a compromise, custody runs in reverse. Instead of proving a file's journey was clean, you are reconstructing which files an intruder touched, copied, or staged. The same record answers both directions — which is a good argument for building it before you need it in either.

What a Custody Record Is Actually Made Of

Nothing exotic. A custody record is assembled from four kinds of material, all of which your systems either already produce or could with modest effort.

• Transfer and access logs — the backbone. Every session, login, upload, and download, with account names and timestamps. What a transfer service should record is covered in what to log. A server product like Sysax Multi Server writes this activity to log files and optionally a database, with rollover. That is exactly the raw material custody reconstruction feeds on.
• Hash values — content fingerprints recorded at origin and at each hop, so "what changed" has a checkable answer.
• Receipts and acknowledgments — the far side's confirmation: an acknowledgment file, a signed receipt, a partner's log extract.
• Context records — the human layer: the ticket that requested the transfer, the run history of the scheduled job, the notification email the job sent when it finished.

Assembled in time order, those materials read like the evidence-room ledger. A one-file record in miniature, of the kind the next article builds in full:

Jun 14 01:52:07 UTC  created    payroll_jun14.csv by nightly-export job (svc_ledger)
                     sha256 recorded at origin: 3c9d1a44...e0b7
Jun 14 02:10:33 UTC  uploaded   to transfer01 via SFTP, account svc_ledger, 48,211 bytes
Jun 14 02:11:05 UTC  verified   sha256 match on transfer01, checked by xferbot job
Jun 14 02:14:41 UTC  delivered  to sftp.meridianbank.example, account northfield-payroll
Jun 14 02:15:02 UTC  receipt    payroll_jun14.ack retrieved from partner ack folder

Five lines, and the three questions are answered for the whole journey: named actors throughout, a continuous timeline, and content verified between hops. The full walkthrough of building this from real logs — including the messy parts — is in documenting a file's journey.

The Standard You Are Aiming For

How good does a custody record have to be? There is no universal statute to quote, and this library does not give legal advice. But the practical bar that satisfies auditors, partners, and legal teams alike is consistent enough to write down as a checklist. A custody record holds up when it is:

• Continuous — every interval from creation to final disposition is covered; no unexplained hours.
• Named — every event attributes to a singular identity: a person's account or a documented service account, never a shared login.
• Timestamped consistently — synchronized clocks, logged in UTC, so events from different systems interleave correctly.
• Content-verified — hash recorded at origin and checked at each hop, so alteration claims meet mathematics instead of memory.
• Corroborated — key events appear in more than one independent source: your log and the partner's receipt; the job history and the server's session record.
• Contemporaneous — written by systems at the time of the event, not reconstructed from recollection afterward. Records made after a dispute starts are worth a fraction of records made before.
• Preserved — kept for as long as a question could plausibly arrive, under retention rules that someone has actually thought about (our retention series covers that decision).

Where Custody Comes From, Day to Day

None of that checklist can be bolted on after the question arrives. Custody is a property of how the flow runs on ordinary days, which is why the two highest-leverage habits are configuration decisions, not documentation ones.

Named identities everywhere. The single cheapest custody upgrade in most shops is deleting the shared transfer login. When every person and every scheduled job authenticates as itself, every log line becomes attributable for free. That can mean named accounts, directory-integrated accounts, or per-system public keys, all of which Sysax Multi Server supports. A record full of ftpuser answers "who had it?" with "someone," which is no answer at all. Shared logins are the custody form in the drawer: filled in, filed, and signed by nobody.

One automated path instead of many manual ones. Files moved by hand accumulate gaps: a download to a laptop here, a paste into a shared folder there. A scheduled job can watch a folder and move files over one sanctioned route. That is the kind of flow a tool like Sysax FTP Automation exists to run. Such a job produces the same log lines, in the same order, every night, and never takes a USB-stick detour. Designing flows where the custody record assembles itself is the payoff article of this series: custody by design. (No scheduled job has ever been found in a coat pocket.)

The Version to Tell a Colleague

Chain of custody is the evidence-room idea applied to files. It is a continuous, named, timestamped record of who had a file and what changed, from creation to final resting place. It is built from materials you already have — transfer logs, hashes, receipts — connected into an unbroken timeline. Hashes prove content; signatures prove parties; custody is the chain that connects those proofs and covers everything between them. And the enemy is not the tamperer, who must be proven, but the gap, which merely has to exist. One unlogged afternoon undoes a thousand clean log lines. Forty minutes in a shared folder will do it too.

From here, read documenting a file's journey to build a real record from real logs. Read hashes as custody evidence for the verification discipline that anchors it.

Frequently Asked Questions