Breaks in Custody: Finding and Handling Gaps

The trail is clean for five hops and then it simply stops. You are reconstructing a file's journey — for an auditor, a partner, your own peace of mind. The log shows the file leaving a folder. The next confirmed sighting is somewhere it should not have been able to reach on its own. Between the two points: nothing. No session, no hash check, no named account. A hole in the story, and a colleague behind you offering that it must have been the network.

That hole is a break in custody, and every organization that moves files has them — usually more than anyone admits. Breaks are rarely sinister. They are made of workarounds, improvisations, and tooling gaps, performed by well-meaning people on deadline. Motive does not repair the record, though: an interval nobody can account for stays unaccountable forever, however innocent it probably was.

This article — part of our Chain of Custody series — is the honest field guide. It covers the classic ways custody actually breaks and a gap incident followed from discovery to resolution. It covers techniques for finding breaks before outsiders do, and what to do with a gap once found. It explains how to repair the process without turning the exercise into a blame hunt. If the underlying concept is fuzzy, the foundation article defines it; here we deal with the chain's failure modes.

What Counts as a Break

A break is any interval in a file's life where the custody questions — who had it, when, did it change — cannot be answered from records. The definition is stricter than intuition wants it to be. "Dan had it on his laptop, he's completely trustworthy" is not custody; it is character reference. "The file sat in the shared folder overnight and nobody would have touched it" is not custody; it is optimism. The test is mechanical: for this interval, can you name the identities that had access and show whether the content changed? If the answer leans on probably, the chain is broken there.

One distinction holds through everything that follows: a break is not evidence of tampering. It is the absence of evidence of anything — which is precisely the problem. Nothing wrong may have happened during the gap, but nothing can be ruled out either, and every conclusion drawn from the file afterward carries that asterisk. This asymmetry — gaps merely need to exist, tampering must be proven — is why gaps do more damage to trust than actual incidents with intact records.

The Classic Breaks

The diagram below shows the shape common to all of them: a managed path with logging at every hop, and a detour through territory that writes no records. The details vary; the broken link is always the same.

The USB-stick detour. The transfer is slow, the deadline is now, and a USB stick physically walks the file across the building. From the record's point of view the file teleported. It vanished from one system and appeared on another with no attributable path. Everything that happened on the stick — including where else it was plugged in — is unknowable. (The stick, when it turns up, has a sticky note on it that says FINAL.)

The personal-email hop. "I'll just email it to myself and send it from home." The file now exists in a personal mailbox outside organizational control and has crossed infrastructure with no business logging. It has an unmanaged copy that will outlive everyone's memory of the shortcut. Custody does not resume cleanly afterward, because the copy count is now unknown.

The shared-folder mystery edit. A file waits in a folder that a whole team can modify. Its timestamp changes at some point during the wait. Which of eleven people changed it, and what changed? Wide write permissions plus no per-file auditing equals an interval that can never be attributed — a standing custody break built into the folder itself. The blast radius way of thinking applies to folders too.

The shared login. Every session is logged, beautifully, as ftpuser. The record is complete and useless at the same time: it attributes every action to a crowd. Shared credentials do not create a gap in the timeline — they create something arguably worse, a timeline whose every line answers "who" with "someone."

The log that rolled away. The flow was fine; the evidence was not retained. A ninety-day rollover met a question that arrived after a year, and the interval is now unaccountable. That is not because nobody logged it, but because nobody kept it. Retention that outlives dispute windows is custody work as much as logging is. The rollover settings that quietly decide it are the subject of log growth and service logs health. Ninety days is a long time for a log and a short time for a dispute.

The clock that lied. One server's clock drifted eleven minutes. Nothing was unlogged, but the assembled timeline shows a file arriving before it departed. A hostile reader gets to ask what else in the record cannot be trusted. Unsynchronized clocks quietly corrode every timestamp they touch — the full story is in timestamps and evidence.

The helpful manual fix. The partner rejects a file over a malformed header. Someone opens the delivered copy, fixes the header by hand, and re-sends it. Now the delivered content matches no recorded hash, and the "fix" itself is undocumented. The record shows two deliveries of differing content with no explanation. Helpfulness plus no procedure equals a break with your best people's fingerprints on it.

A Custody-Gap Incident, Start to Finish

A break surfaces like this, in a composite drawn from very typical parts. Northfield sends Meridian Bank a quarterly benefits adjustment file. Weeks later, the bank reports that its processed figures disagree with Northfield's HR system for about forty employees. Both sides suspect the other's data. Priya, the infrastructure admin, is asked to walk the file's journey.

The early chain is pristine. The export job's log shows the file created by svc_ledger, origin hash recorded. The transfer server's activity log shows the upload, and the arrival verification logged MATCH. Then the trail stops. The first theory, offered within minutes, is that it must have been the network. The network, as usual, has an alibi, and the alibi is the activity log. The outbound job's history shows no run that night — it had failed with a connection error, because the partner's SFTP endpoint was down for maintenance. The next entry involving the file is in the transfer server's activity log: a download at 17:42 by dan.wheeler, a benefits analyst. After that: nothing, anywhere, until the bank's systems show a file processed the next morning. It was submitted at 08:03 through the bank's web portal, a path that produces no receipt and touches none of Northfield's logging.

Fourteen hours on a personal laptop, then an upload nobody can inspect. The gap is real, and Priya documents it exactly as found: last confirmed custody event, first confirmed reappearance, and the unaccountable interval between. Then she does the one thing that can still shrink the gap — content comparison. The bank exports the file it processed; its SHA-256 does not match the recorded origin hash. Diffing the two shows the processed file is an older draft. Dan, working from home under deadline, had grabbed the wrong file from his laptop's download folder. The previous week's draft sat beside the final version with a near-identical name. The forty discrepancies are exactly the rows that changed between draft and final.

Resolution: the correct file is re-sent through the managed path with hash verification, and the bank reprocesses. The custody record for the original transfer is closed with the gap documented, not disguised. It states what is known, what is not, and how the content question was settled by hashes. Nobody is disciplined. Dan improvised because the sanctioned path failed silently at the worst possible hour and the portal fallback had no procedure. That diagnosis — the process failed before the person did — is what the repair section below is about. What made the reconstruction possible at all was decided long before that night. Named accounts and server-side session logging meant the download at 17:42 was attributable. A recorded origin hash meant the content dispute ended in arithmetic instead of argument. Neither existed by luck. The transfer server recorded every session, login, upload, and download as a matter of configuration. That is the always-on activity logging a server like Sysax Multi Server writes to file and database. The hash step ran inside the export job. The gap was fourteen hours long instead of end-to-end because the surrounding flow was built to remember. The draft with the near-identical name did more damage that quarter than anyone in the building.

Detecting Gaps Honestly

Breaks rarely announce themselves; they surface when someone walks a chain with intent to find them. Make that walk a habit — quarterly on your regulated flows, and always before anyone external does it for you. The moves:

• Walk the intervals, not the events. Log lines draw the eye to what happened; custody fails in the spaces between. For each interval between recorded events, ask who had access to the file where it sat. An interval in a locked-down folder is covered; an interval in a team-writable share is a soft break waiting to be named.
• Follow the hashes. Any hop where the fingerprint was never checked is unverified territory. Any mismatch that was logged and never investigated is a flag planted on a problem. The recording discipline that makes this walk possible is hashes as custody evidence.
• Look for impossible timelines. Arrivals before departures, verifications before uploads — clock skew or worse. Either way the record needs attention before a challenger finds it first.
• Look for the wrong kind of actor. A human account appearing mid-flow in an automated pipeline is the single most reliable gap signal in transfer logs. Think of dan.wheeler in a svc_ world. Fluency in spotting it comes from reading transfer logs. The overlap with deliberate misuse is covered in insider risk.
• Check the record's own custody. Look for logs that anyone can edit, hash files stored beside the payloads they attest, and retention shorter than dispute windows. Breaks in the evidence layer are breaks in the chain, even when the file's journey was perfect.

Condensed into a checklist you can paste into the flow's runbook and run per flow:

GAP HUNT — flow: ______________   reviewer: ______________   date of walk: ______
[ ] Every interval between events: who could access the file there? (permissions pulled, not assumed)
[ ] Every hop: hash verified and result recorded? unverified hops listed
[ ] Timeline sane in UTC? no arrivals before departures, no verification before upload
[ ] Actors as expected? human accounts in automated segments investigated
[ ] Any hop outside managed logging (portal, email, media)? listed with dates
[ ] Evidence layer: logs protected, hash records separate, retention outlives disputes
[ ] Findings written down, owner assigned, fix dated — "all clean" only if truly clean

Handling a Gap You've Found

Whether the gap turned up in your own review or mid-dispute, the sequence is the same, and the guiding principle is: preserve what exists, add nothing fake.

1. Freeze and preserve. Secure the surviving evidence — logs, hashes, receipts, the file copies themselves — before anything rolls over or gets "tidied."
2. Bracket the gap. Establish the last fully-attested event before it and the first after. The gap is now a defined interval with edges, not a fog over the whole journey.
3. Shrink it with content evidence. If an origin hash exists, compare it against the file after the gap. A match rules out alteration during the gap even though possession stays unaccounted for — that is a much smaller wound. A mismatch, as in Dan's incident, converts the mystery into a concrete diff you can investigate.
4. Write the gap into the record. The custody record states the interval, what is unknown, and what was done about it. A documented gap reads as diligence; a discovered concealment destroys the credibility of everything else in the record.
5. Escalate the significance question. Whether the gap matters — to the assessment, to the dispute, to a case — is not the admin's call. Legal teams typically treat gaps as matters of weight, argued over and weighed against the surrounding evidence, rather than automatic disqualification. Your documented bracketing is exactly what they weigh. Hand it over and let them.
6. Feed it to process repair. Every gap is a free diagnosis of where the flow made the wrong thing easy. Which brings us to the last section.

Repairing Process, Not Assigning Blame

Run the repair like a blameless postmortem: the question is never "who broke custody?" but "what made breaking custody the path of least resistance?" People detour when the sanctioned path is slower, harder, or broken at the moment of need. Dan's incident yields the pattern: the job failed silently, nobody was alerted, the deadline stood, and the fallback was whatever Dan could improvise. Punishing Dan fixes none of that and teaches the team to hide the next improvisation. That converts future gaps from visible to invisible, the worst possible trade. I have made that trade once, early on, and spent the following year learning about workarounds from the audit instead of from the team.

The fixes that actually work attack the temptation:

• Make failures loud. A silent overnight failure invites improvisation; an alert invites a controlled response. Retry logic plus failure notifications turn "the job died and nobody knew" into "the job retried, then told humans at once." In a scheduled-transfer tool like Sysax FTP Automation, retry and error handling with email notifications are standard job features.
• Give the emergency a procedure. The portal fallback existed; only the custody steps were missing. A written fallback keeps custody intact even off the main path. Verify the origin hash before sending, note the submission time and account in the ticket, and confirm content with the partner after.
• Close the standing breaks. Shared logins get replaced with named accounts; team-writable staging folders get tightened; log retention gets extended to match dispute windows. Each is a one-time fix that removes a whole category of future gap.
• Put the rules where people can find them. Which methods are sanctioned, which are forbidden, and what to do when the sanctioned one fails belongs in a written policy people have actually read. The craft of writing rules that get followed is its own series: file transfer policy.

Above all, make the right way the easy way — flows designed so the logged, hashed, receipted path is also the fastest one available. That design discipline is the next and final article: custody by design.

Putting It Together

Custody breaks are ordinary: detours, shortcuts, shared identities, expired logs, drifting clocks, helpful fixes. Their common shape is an interval nobody can account for, and their common cost is doubt that never fully leaves. Hunt for them deliberately — walk the intervals, follow the hashes, watch for the human account in the automated flow. When you find one, bracket it, shrink it with content evidence, document it honestly, and let the people who own the significance question own it. Then repair the process that made the detour attractive, without theater and without scapegoats. A worked example of what the intact version of the record looks like is in documenting a file's journey — the standard your repaired flow should meet by default. And when someone says it must have been the network, ask the network; it keeps a log.

Frequently Asked Questions