The footage exists. Everyone in the room has watched it. The question on the table is not what it shows — it is whether anyone can prove it is the same footage the camera recorded.
That proof is a video chain of custody: the documented, verifiable history of a recording from the moment it was captured to the moment it is presented. Where it was, who could reach it, and evidence that it did not change at any step. The record button creates the file. It creates none of that history.
This is the gap most recording systems quietly leave open, and it is the one that decides whether footage settles a dispute or starts a second one.
What a video chain of custody actually is
Two words get used interchangeably and should not be. Integrity means the file has not changed. Authenticity is broader: SWGDE, the standards body for digital evidence examiners, defines authentication as "the process of substantiating that the data is an accurate representation of what it purports to be." A perfectly intact file can still be the wrong file, from the wrong camera, at the wrong time.
A video chain of custody is how you close that gap. It is not a property of the file at all — it is a record kept about the file, and it has to be kept continuously, because any interval nobody can account for is an interval in which anything could have happened.
That is also why the law treats it the way it does.
What the law asks for, in two jurisdictions
The US and India reach the same place by different routes. What follows is how the rules read, not legal advice for a particular case.
In the US, the starting point is Federal Rule of Evidence 901(a): the proponent must produce "evidence sufficient to support a finding that the item is what the proponent claims it is." For machine-made records, Rule 902 lets that happen without a live witness. Rule 902(14) covers "data copied from an electronic device, storage medium, or file, if authenticated by a process of digital identification," certified by a qualified person — and the Committee Notes say such data is "ordinarily authenticated by 'hash value'."
In India, the Bharatiya Sakshya Adhiniyam, 2023 replaced the Indian Evidence Act, and section 63 now governs electronic records. It makes them admissible "without further proof or production of the original" if conditions are met — including that the output was produced during regular use and the device "was operating properly." The record must come with a certificate in the form set out in the Act's Schedule, and that form asks for "the HASH value/s of the electronic/digital record/s" and the algorithm used, in both the party's part and an expert's part. The same form asks which source the record came from, and lists DVR, Server and Cloud among the options, so footage from CCTV recorders and cloud storage is anticipated on the face of the form.
What is required | United States (FRE) | India (BSA 2023) |
|---|---|---|
The basic test | 901(a): evidence the item is what it is claimed to be | s.63(1): admissible without the original if s.63 conditions are met |
Proof about the system | 901(b)(9): a process or system "that produces an accurate result" | s.63(2): regular use, proper operation, information fed in the ordinary course |
Certification | 902(13)/(14): certification of a qualified person, with written notice to the other side (902(11)) | s.63(4): certificate signed by the person in charge, plus an expert's part |
The number that ties it together | Hash value — "ordinarily," per the 902(14) Committee Notes | Hash value and algorithm — SHA1, SHA256, MD5 or another acceptable standard — in the Schedule |
Read the two columns together and the requirement is the same in both: a description of the process that made the recording, and a hash that proves the copy matches. Neither is something a record button produces.
So where, exactly, does a video chain of custody break?
The four links in a video chain of custody
Every recording passes through the same four stages, whether it is a banking video-KYC session or a clip of a theft in progress. Each stage asks its own question, and each has a version that looks like custody and is not.
Link | The question | What a record button gives you | What custody needs |
|---|---|---|---|
Capture | Was all of it recorded, and when? | A file with a creation date | Numbered segments, recorded gaps, a synchronised clock |
Storage | Could it have changed or disappeared? | A file in a bucket or on a disk | A hash taken at write time; retention nobody can shorten |
Access | Who has seen or copied it? | Perhaps a server log | A log of every view and export that cannot itself be edited |
Export | Is this copy the original? | A download, often re-encoded | Native format, a hash at export, the proof packaged with it |
Capture is where custody is most often lost for good, because it is the one link that cannot be repaired later. A hash computed the week after the incident proves the file has not changed since that week. It says nothing about the days before. The engineering behind each row — manifests, chained hashes, locked retention — is covered in the evidence each pipeline stage has to produce.
Storage is where teams most often believe they are covered when they are not.
Why "it's in the cloud" is not custody
A recording in a managed storage bucket feels safe, and it usually is safe from loss. A video chain of custody asks a different question — safe from whom — and three things undermine the answer.
- The file cannot vouch for itself. SWGDE warns that video metadata "is susceptible to alteration without affecting the playback of the file" and "cannot be relied upon in isolation." Dates and camera names inside the file are claims, not proof.
- Administrators can usually replace it. Anyone with write access to the bucket can overwrite a file with an edited copy that plays identically. Unless a hash was recorded somewhere they cannot reach, nothing shows it happened.
- "Locked" often isn't. S3 Object Lock's governance mode can be overridden by any user granted the s3:BypassGovernanceRetention permission; only compliance mode stops everyone, "including the root user." It is common for the first to be enabled and described as the second — the governance-mode trap.
None of this means cloud storage is unsuitable. It means the storage layer is one link, and the proof has to come from outside it. The retention and jurisdiction side of the same problem is laid out in the compliance trap in recording at scale.
The last link is the one people forget is a link at all.
The copy is the evidence
Nobody presents the original storage volume. They present an export — and the video chain of custody continues through it, or it ends there.
The forensic guidance is direct. SWGDE's best practices for acquiring video from recorders say "a native file format or proprietary file format is likely to provide best evidence for legal authenticity purposes as it is closest to the original manner of recording," and instruct examiners to "create a hash value for any video retrieved." Where a proprietary player is needed, it goes with the files.
In practice that means two copies with two jobs. The native export, hashed at the moment it leaves the system, is the evidence. A convenient MP4 for viewing is a working copy, and should be labelled as one. How timing, retention and export are handled in practice decides whether that native copy holds up months later.
Which leaves the practical question: how do you tell, before you need it, whether a system keeps custody at all?
Six questions to ask of any recording system
Ask them of your own platform, a vendor, or the CCTV estate behind a perimeter. The answers are either specific or they are not.
- Is the recording written as numbered segments with a manifest, and are gaps recorded? If a recorder fails for a minute, you want that minute documented, not missing.
- When is the hash computed — at capture, or at export? Only the first covers the whole life of the file.
- Who, precisely, can delete or overwrite a recording before its retention ends? "Nobody" is a checkable answer. "Only admins" is not custody.
- Is every view and download logged — including inside the application — and can anyone edit that log?
- What does an export contain? Native format, hashes and timing information, or just a re-encoded file.
- Who would sign the certificate, and could they describe the process? Both 901(b)(9) and section 63(2) turn on someone being able to explain how the system works and that it was working properly.
A system that answers all six specifically keeps a video chain of custody. One that answers with a feature name — "we have encryption," "it's WORM" — usually does not.
The Bottom Line
A video chain of custody is a continuous, provable history of a recording, and both US and Indian evidence law ask for the same two things at the end of it: an account of the process that made the file, and a hash showing the copy matches. A record button gives you the file and nothing else.
Custody is decided at capture and lost silently in storage and export. Check those three links before the day someone asks.
What's Next
For what the EU, US and India each require of a recording beyond custody, read video recording compliance across the EU, US and India. For the recorder models and storage tiers underneath it all, see what runs behind the recording pipeline at scale.
Frequently Asked Questions
What is a video chain of custody?
It is the documented, verifiable history of a recording from capture to presentation: where it was stored, who had access, and proof it did not change at each step. It is a record about the file, not a property of the file, and it has to be kept continuously from the moment of capture.
Is a hash value enough to prove video evidence is authentic?
A hash proves a copy matches the file that was hashed, which is why both FRE 902(14) and India's BSA certificate rely on it. It does not prove the hashed file was the original. That needs the rest of the chain — when the hash was taken, how the file was captured and stored, and who could reach it before then.
What does India's section 63 certificate require for video recordings?
Under the Bharatiya Sakshya Adhiniyam, 2023, an electronic record must be accompanied by a certificate identifying the record, describing how it was produced and confirming the device was operating properly. The certificate form in the Schedule asks for the hash value and algorithm, in both the party's part and an expert's part.
Can footage stored in the cloud have a valid chain of custody?
Yes, but storage alone does not provide it. You still need a hash recorded at capture somewhere administrators cannot edit, retention that cannot be shortened, and a log of every access. Check whether any object lock is in compliance mode rather than governance mode, which can be bypassed with one permission.
Why export video in its native format rather than MP4?
Forensic guidance treats the native format as the best evidence because it is closest to how the footage was originally recorded; re-encoding changes the file and can raise questions about what else changed. Keep the hashed native export as evidence and use an MP4 only as a labelled working copy.
Does the video chain of custody break if someone watches the recording?
Not if the viewing is logged and the file is not altered. Custody does not require that nobody touches the footage — it requires that every access is recorded in a log that cannot itself be edited. Unlogged access is what creates a gap.
Can we keep the whole custody chain on our own infrastructure?
Yes, if recording processing and storage run on infrastructure you control. Samvyo works this way: it is based on SFU architecture and keeps recording processing and storage on your side, so the hashes, logs and exports that form the chain stay inside your own boundary. The retention and certification decisions remain yours.
