The short answer
A chain of custody is the documented, chronological record of who handled each piece of evidence, when, why, and in what state. For video and event logs it needs two parallel proofs: signed, timestamped logs of every access and transfer, plus cryptographic hashes confirming the file never changed. Act in the first hours — freeze overwrite and remote access, define the time window, capture protected copies with SHA-256 hashes recorded separately, and document every step.
Key takeaways
- Chain of custody is a documented history of handling — not merely saving a copy — and it usually determines whether video and logs are admissible.
- Digital evidence needs two parallel proofs: signed access and transfer logs plus cryptographic hashes (e.g., SHA-256) recorded at capture.
- Overwrite schedules and short retention windows destroy evidence faster than any adversary, so freezing sources in the first hours is decisive.
- Store hashes separately from the files they describe, as NIST recommends, so a single compromised repository cannot alter both the data and its integrity record.
- Most broken chains come from documentation gaps — missing signatures, unexplained time holes, working on copies instead of preserving originals — not from dramatic tampering.
- Base procedures on ISO/IEC 27037 and NIST SP 800-86 and build them before an incident, not after the fact.
What a chain of custody is and why video without it fails
A chain of custody is the documented, chronological record of every point at which evidence is handled: who obtained it, when and why, where it was stored, to whom it was transferred, and in what condition at each moment. For a camera clip or an event log, that record has two halves: documentation (paper or electronic) and a mathematical guarantee that the file did not change after capture. The international standard ISO/IEC 27037 lays out exactly these stages — identification, collection, acquisition, and preservation of potentially significant digital evidence.
The stakes go well beyond technique. A party challenging a recording usually does not have to prove the file was faked; it is enough to show the chain left room for that possibility. A missing signature, an unexplained gap in the record, or frames overwritten without a transfer note are common reasons otherwise honest video gets excluded. This is why NIST SP 800-86 embeds forensic rigor into the incident-response lifecycle: treat every log and every recording fragment as potential evidence from the first minute rather than reconstructing documents once lawyers arrive.
- A chain proves continuity of possession from collection to presentation before a court or regulator.
- A gap in the record, not actual tampering, most often undermines trust in a recording.
- Discipline should be preventive: forms are completed at the moment of action, not reconstructed later.
Map the sources: video and event logs
Start with a data map. Video lives not only in recorders and NVRs but also in video management systems (VMS), individual IP cameras, and cloud archives, each with its own retention period and overwrite behavior. Event logs are even more varied: Windows Event Log, Linux system logs and central syslog, application and web-server logs, firewalls, physical access control systems, antivirus, and wireless access points. Some records exist for only a few days, so the inventory of what is still present must be built immediately.
Before copying anything, define the incident's boundaries: which cameras and systems are relevant and over what time interval. Practitioners advise capturing a wider interval than seems necessary — including footage before and after the event — because restoring deleted clips is usually harder than grabbing a little extra up front. Recording metadata (camera time, device identifier, who opened the file) is as valuable as the picture itself, since it lets you reconcile the timeline against logs.
- Video: source files in native format, pre- and post-roll, metadata, and time expressed in UTC.
- Logs: sign-in events, process launches, network connections, privilege changes, and administrator actions.
- Capture with margin: overwritten or deleted data is often unrecoverable.
Act in the first hours: a preservation sequence
Work on the principle preserve first, investigate later. Move assets into a state where they cannot be overwritten: stop automated purge, and where possible disable recording and the network and shield the system from remote access. Record the state before you intervene — screen and clock capture, serial numbers, connections. Only then begin creating copies.
Take copies with write protection where feasible and keep the original untouched. Compute a checksum (for example SHA-256) the moment a copy finishes and enter it into the record. Log every handover between people or systems with signatures and timestamps: who released it, who received it, why, and its condition. Move quickly and overwrite schedules and short log-retention windows stop being the main threat.
- Freeze sources: stop overwrite and remote access before capturing copies.
- Create copies rather than moving originals; leave the original unchanged.
- Record each step immediately, with name, date, time, and reason.
Two proofs of integrity: documentation and cryptography
A signature on a form alone will not protect a file someone quietly alters, and a hash without a signed log proves nothing. A chain rests on two parallel proofs: documented records show who touched the evidence, and a checksum shows the evidence itself did not change. NIST practice recommends storing hash values apart from the files they describe — in a separate system or on paper — so that a single compromised repository cannot distort both the data and the record of its integrity.
A transfer form should carry a unique identifier for the item, a description, date and time, the responsible person's name, the reason for the transfer, and condition before and after. When an error occurs, do not erase it: strike it through, initial it, and add a corrected entry with its own timestamp. Re-verify the hash not only at capture but before presenting the material and at each handover. A mismatch found early becomes a documented observation; one found in court becomes a problem for the whole case.
- Documentation answers who touched it; the hash answers whether it changed.
- Store hashes separately from the data, following NIST guidance.
- Re-verify the checksum at every access, not only at capture.
Common ways chains break
Most broken chains are not the work of a saboteur. They result from ordinary carelessness that only matters when the stakes rise: someone copies a file just to look at it before the examiner arrives, fills in dates from memory, hands over media without a signature, or writes a description that could fit two different devices. Each small slip turns a strong technical case into a paperwork failure.
A separate cluster of errors concerns time: unsynchronized camera and server clocks make footage and logs impossible to reconcile, and a wrong time zone corrupts the timeline. Add to that unclear access rights, so that any employee can open a file, and the absence of regular audits of the access log. The lesson is that procedure must cover everyone who touches the systems, not only forensic specialists.
- Too many hands: every extra transfer is another signature that can go missing.
- Time: synchronize camera and server clocks to UTC and document the time zone.
- Training everyone who touches systems, not only forensics staff, cuts accidental breaches.
- Audit access logs regularly, not only when an investigation begins.
Roles, standards, and limits of applicability
Assign a single evidence custodian to each case: that person maintains the custody log and ensures no access goes unrecorded. Spreading responsibility across everyone creates gaps. Procedures and form templates are best prepared in advance and reviewed with counsel rather than improvised during an incident.
Reference points are ISO/IEC 27037 (identification, collection, acquisition, and preservation of digital evidence), NIST SP 800-86 (integrating forensic techniques into incident response), and NISTIR 8387 (preservation considerations for evidence handlers). These set out general methodology; concrete rules on formatting, retention periods, and admissibility differ by jurisdiction and change over time, so applicability in a specific court or regulatory proceeding should be decided with a specialist. What is said here is general information, not legal advice.
- One named custodian per case avoids diffuse responsibility.
- Procedures and templates are agreed with counsel before an incident.
- ISO/IEC 27037, NIST SP 800-86, and NISTIR 8387 define method, not local filing rules.
Put it into practice
Checklist: the first 60 minutes after an incident
This checklist helps a team preserve video and event logs so the material remains usable in a proceeding. Print it in advance and work through it item by item, giving each step an owner and a timestamp.
- A single evidence custodian is named; others do not touch systems without that person's decision.
- Inventory of relevant sources compiled: recorders, NVR, VMS, cloud archives, log servers, access control.
- Automated overwrite stopped or storage capacity frozen.
- Incident time window defined with margin, and current time recorded in UTC.
- Camera and server clock synchronization checked and, if needed, corrected.
- Copies of video and logs captured; originals left untouched.
- A SHA-256 hash computed for each copy and entered in a separate record.
- Every handover logged with signature, date, and reason; forms stored apart from the media.
- Hash values stored in a system separate from the files they describe.
- Photograph and describe equipment state before intervention.
- Agreement reached with counsel on which material will be handed over and in what form.
Questions people ask
How is a chain of custody different from just saving a copy of the file?
A saved copy by itself proves nothing: without records you cannot say who accessed it or whether it changed. A chain of custody adds two layers to the file — a documented access log (who, when, why) and a checksum confirming it is unchanged. Courts and regulators rely on the documented path of an object from collection to presentation, not merely on the fact that the file exists somewhere.
Which video and logs should I preserve first after an incident?
Preserve whatever will vanish fastest: clips with short retention and automatic overwrite, plus short-lived logs. Practical priorities are footage from cameras covering the incident (with margin before and after), sign-in and access logs, process-launch events, network connections, administrator actions, and physical access control records. Stop overwrite first, then capture copies.
What do I do if the frames I need have already been overwritten?
First document the fact and time of the overwrite — that record is part of the chain and can explain the gap. Check whether backups, a cloud archive, or a log still holds a duplicate of the frames. Recovering overwritten data is possible but difficult, costly, and requires specialized equipment and an expert, so any potentially valuable source is better captured immediately than left to recovery later.
Do I need a hash, and how do I do it properly?
Yes. A hash (for example SHA-256) is a mathematical signature of a file that lets you verify at any point that its content has not changed. Compute it immediately after creating a copy and record it in the transfer form. Keep the hash value separate from the file itself — in another system or on paper, as NIST recommends — and re-verify it at each handover and before presenting the material.
Who should own the chain of custody inside an organization?
Assign one evidence custodian to each case. That person maintains the custody log, records transfers, and makes sure no access goes unmarked. Diffuse responsibility — when anyone can open and copy files — creates gaps. Procedures, form templates, and the list of responsible people should be prepared in advance and reviewed with legal counsel.
What matters more to a court: the paper log or the integrity of the file?
Both matter and they work only together. A signed log shows who handled the evidence but does not protect the file from quiet alteration; a hash confirms the file is unchanged but says nothing about where it came from or who is accountable for it. A defensible chain of custody requires maintaining documentation and checksums in parallel, not choosing one over the other.
Sources and further reading
Sources were checked when this page was generated. Confirm changing dates, rules and prices with the original publisher.
- Guide to Integrating Forensic Techniques Into Incident Response (NIST SP 800-86)National Institute of Standards and Technology
- Digital Evidence Preservation: Considerations for Evidence Handlers (NISTIR 8387)National Institute of Standards and Technology
- ISO/IEC 27037:2012 — Guidelines for identification, collection, acquisition and preservation of digital evidenceInternational Organization for Standardization
- What is chain of custody in cyber security?Computer Forensics Lab
- Best practices for evidence handling: a specialist guideComputer Forensics Lab
- Evidence Trails That Stand Up to Audit: What Industrial Security Must CaptureDetect Technologies
- Designing Chain of Custody for Security Video Evidence in Critical DeploymentsFortSense