Chain of custody for digital evidence
How a forensic practice handles, documents, and preserves digital evidence so that it survives challenge in court — hashing, write-blocking, forensic imaging, and the paper trail that makes a case defensible.
Digital evidence is fragile in ways that physical evidence is not. A physical weapon sitting in an evidence locker degrades slowly, if at all. A hard drive sitting in an evidence locker can be altered by nothing more than powering it on. The operating system you boot from, the files you open, the network connections your computer makes — all of these change the evidence in ways that are difficult to detect and impossible to reverse. The purpose of a chain of custody is to prove, to a court, that the evidence presented is the evidence that was seized, and that it has not been altered from the moment of seizure to the moment of presentation.
This article describes the procedure used in professional digital forensic practice. It is written for instructing solicitors, in-house legal teams, and law-enforcement professionals who need to understand what their expert is doing, why they are doing it, and what the documentation should look like when it is done correctly. It is not a tutorial. It is a description of professional working method.
The ACPO/NPCC Principles
The foundational document for digital evidence handling in the UK is the Association of Chief Police Officers (ACPO) Good Practice Guide for Digital Evidence, now maintained by the National Police Chiefs' Council (NPCC). The guide establishes four principles:
- Principle 1: No action taken by law enforcement agencies, persons employed within them, or their agents should change data which may subsequently be relied upon in court.
- Principle 2: Access to original data must be acquired in a manner that is forensically sound and capable of replication. If a device is accessed and booted, the data on it may be altered. The standard method is to acquire a forensic image of the device using a write-blocker, which prevents any write operations to the device.
- Principle 3: An audit trail or other record of all processes applied to digital evidence should be created and preserved so that a third party could follow the same process and arrive at the same result.
- Principle 4: The person in charge of the investigation has overall responsibility for ensuring that the law and these principles are adhered to.
These principles are not guidelines. They are the standard against which a court will assess whether the evidence has been handled properly. If the evidence has been handled in a way that breaches these principles, the court may exclude the evidence under s.78 of the Police and Criminal Evidence Act 1984 (PACE), or may admit it but give it reduced weight. In civil proceedings, the court will assess the evidence under the Civil Procedure Rules Part 35 and the accompanying Practice Direction, which requires expert evidence to be objective and unbiased.
Seizure and initial handling
When a device is seized, the following documentation should be created at the point of seizure:
- Exhibit reference. A unique identifier for the device. This is typically the case reference number followed by a sequential exhibit number (e.g., AB/1234-001). The exhibit reference is used to track the device throughout its lifecycle in the investigation.
- Photographs. The device is photographed in situ before it is moved. The photographs should show the device's location, any cables connected to it, any peripherals, and the state of any indicators (power, network, USB). If the device is a computer, the screen should be photographed to capture the current state — open applications, running processes, etc. If the device is powered on, the decision to power it down (or not) must be documented.
- Chain of custody form. A form recording the date, time, location, and identity of the person seizing the device. The form is signed by the seizing officer and by any person present (e.g., the owner of the premises). The form is the first entry in the chain of custody record, which must be maintained for the entire lifecycle of the device.
- Hash of the device. If the device is a storage medium (hard drive, USB drive, etc.), a hash of the device is computed at the point of seizure. This is the "fingerprint" of the device's contents at the moment of seizure. The hash is computed using a cryptographic hash function — typically SHA-256 or SHA-512 — and is recorded on the chain of custody form. Any change to the device's contents will produce a different hash, which is how the integrity of the evidence is verified at later stages.
The device is then packaged in evidence packaging, sealed with evidence tape, and the seal is signed by the seizing officer. The packaging is labelled with the exhibit reference, the date, and the seizing officer's identity. The device is then transported to the evidence storage facility, where it is logged into the evidence management system and stored in a secure location with access control.
Forensic imaging
Forensic imaging is the process of creating a bit-for-bit copy of a storage medium. The image is a forensic copy — it is an exact replica of the source, including all data, metadata, and free space. The image is used for all subsequent analysis, and the original device is returned to evidence storage.
The standard tool for forensic imaging is a hardware write-blocker. A write-blocker is a device that sits between the source device and the imaging computer and prevents any write operations from reaching the source. There are two types:
- Hardware write-blocker. A physical device that blocks write operations at the hardware level. The device is typically a USB or SATA blocker that intercepts write commands and blocks them. The device logs all operations, which provides an additional layer of audit trail.
- Software write-blocker. A software tool that mounts the source device in read-only mode. This is less reliable than a hardware blocker because the operating system may still write to the device (e.g., through filesystem metadata updates). A hardware write-blocker is the standard.
The imaging process is as follows:
- Attach the source device to the write-blocker. The source device is connected to the write-blocker, which is connected to the imaging computer. The imaging computer is booted from a clean, write-protected operating system (typically a Linux live USB with the drive mounted read-only).
- Compute the hash of the source device. Before imaging, a hash of the source device is computed. This is the "before" hash. It is recorded in the imaging log.
- Create the forensic image. The imaging tool (typically
dd,dc3dd, orewfacquirewith the Expert Witness Format (E01) format) creates a bit-for-bit copy of the source device. The image is written to a new, blank destination drive. The imaging tool logs all operations, including the source hash, the destination hash, and the time taken. - Compute the hash of the forensic image. After imaging, a hash of the forensic image is computed. This is the "after" hash. It should match the "before" hash. If the hashes do not match, the imaging process has failed and the image is not a faithful copy of the source. The process must be repeated. <5>Verify the image. The image is verified by computing the hash of the image file and comparing it to the hash of the source device. If the hashes match, the image is verified. If they do not match, the image is not verified and must not be used for analysis.
- Document the process. The entire process is documented in an imaging log, which includes the date, time, location, identity of the person performing the imaging, the tools used, the source hash, the destination hash, and the verification result. The log is signed by the person performing the imaging and by any witness.
The imaging process typically takes several hours, depending on the size of the source device. A 1 TB hard drive takes approximately 4-8 hours to image, depending on the interface speed. The imaging tool logs the start time, end time, and throughput, which provides an additional audit trail.
Storage and access control
Once the forensic image is created, it is stored in a secure location with access control. The storage facility should meet the following requirements:
- Physical security. The storage facility is a locked room with access control. Access is logged — who entered, when, and for how long. The facility should have CCTV coverage of the entrance and the storage area.
- Logical security. The forensic images are stored on an encrypted volume (typically LUKS or BitLocker). The encryption key is stored in a secure key management system, separate from the storage system. Access to the key is logged.
- Access logging. Every access to a forensic image is logged — who accessed it, when, what they did, and when they finished. The log is maintained for the entire lifecycle of the case.
- Separation of duties. The person who creates the image is not the person who analyses it. This separation ensures that the person who analyses the image cannot alter it without detection — any change to the image would change the hash, which would be detected by the person who created the image.
Access to the forensic image is granted only to the person who is authorised to analyse it. The authorisation is documented in the case file, which is maintained by the person in charge of the investigation (Principle 4 of the ACPO/NPCC guide).
Analysis
Analysis of the forensic image is performed on a working copy. The working copy is a copy of the forensic image, created using the same process as the original imaging (hash verification, etc.). The original image is never accessed directly — all analysis is performed on the working copy, so that if the working copy is corrupted or altered, the original image is still intact.
The analysis tools used in professional practice include:
- Autopsy. An open-source forensic platform that provides a graphical interface for analyzing disk images. Autopsy can analyze filesystem metadata, deleted files, internet history, email, and other artifacts. It is built on the Sleuth Kit, which is a collection of command-line tools for forensic analysis.
- FTK (Forensic Toolkit). A commercial forensic platform by Exterro. FTK provides similar functionality to Autopsy, with additional features for indexing and searching. FTK is widely used by law enforcement and private practitioners.
- EnCase. A commercial forensic platform by OpenText. EnCase is the standard platform in many law enforcement agencies and is widely accepted in UK courts.
- Volatility. An open-source memory analysis framework. Volatility can analyze RAM dumps to identify running processes, network connections, and malware. It is used in cases involving live systems and malware analysis.
- Cellebrite UFED. A commercial mobile forensic tool. Cellebrite can extract data from mobile phones, including deleted data, and is the standard tool in UK law enforcement for mobile phone analysis.
All analysis is documented in a report. The report includes:
- The exhibits examined
- The tools used, including version numbers
- The methodology used — i.e., what was done, in what order, and why
- The findings — i.e., what was found, with exhibit references
- The limitations of the analysis — i.e., what could not be determined and why
- The expert's conclusions and the basis for them
The report is written in a way that is accessible to a layperson — i.e., the judge and jury. Technical terms are defined, and the methodology is explained in plain English. The report is accompanied by a witness statement, which is the expert's evidence in chief. The expert is then cross-examined on the report and the witness statement.
The chain of custody record
The chain of custody record is the document that tracks the evidence from the moment of seizure to the moment of presentation in court. Every person who handles the evidence, for any reason, must be recorded in the chain of custody. This includes:
- The person who seized the evidence
- The person who transported the evidence to the storage facility
- The person who logged the evidence into the storage facility
- The person who created the forensic image
- The person who analysed the forensic image
- The person who transported the evidence to court
- The person who presented the evidence in court
Every transfer of custody is documented:
- The date and time of the transfer
- The identity of the person transferring custody
- The identity of the person receiving custody
- The reason for the transfer
- The condition of the evidence at the time of transfer (e.g., seals intact, packaging undamaged)
- The signatures of both parties
If there is a gap in the chain of custody — i.e., a period during which the evidence was not accounted for — the court may exclude the evidence or give it reduced weight. The gap does not automatically mean the evidence is inadmissible, but the prosecution must explain the gap and satisfy the court that the evidence has not been tampered with.
Hash verification
Hash verification is the technical control that underpins the chain of custody. The hash is computed at every stage of the process:
- At seizure — the "before" hash
- After imaging — the "after" hash (must match the "before" hash)
- Before analysis — the hash of the working copy (must match the original image)
- After analysis — the hash of the working copy (must not have changed)
- Before presentation in court — the hash of the evidence (must match the original)
If at any stage the hash does not match, the evidence has been altered and the court must be informed. The expert's duty is to the court, not to the party instructing them (Civil Procedure Rules Part 35.3), and the expert must disclose any alteration of the evidence, regardless of whether it benefits or harms the party's case.
The hash function used is SHA-256 or SHA-512. MD5 and SHA-1 are no longer considered secure for forensic purposes, as collision attacks have been demonstrated. The hash is computed using a trusted tool (e.g., sha256sum on a Linux system booted from a clean, write-protected operating system).
Common failures
The following are the most common failures in digital evidence handling that I have seen in practice:
- Booting the device. The most common failure. The device is powered on, and the operating system boots, writing to the hard drive. The writes alter the evidence — they overwrite deleted files, update filesystem metadata, and create log entries. The "before" hash will not match the "after" hash, and the evidence is compromised. The correct procedure is to never power on the device. If the device is powered on, leave it on, photograph the screen, and then pull the power (or, if the device is a laptop, remove the battery). Do not shut down normally — a normal shutdown writes to the hard drive.
- Imaging without a write-blocker. The second most common failure. The device is connected to an imaging computer without a write-blocker. The operating system on the imaging computer writes to the device — e.g., by mounting the filesystem, which updates the journal. The correct procedure is to always use a hardware write-blocker. If a write-blocker is not available, the device should not be imaged.
- Storing the image on the same system as the analysis tools. The image is stored on the same system as the analysis tools, which means that the analysis tools can write to the image. The correct procedure is to store the image on a separate, dedicated storage system, and to access it only through a write-blocked interface.
- Failure to compute hashes at every stage. The hash is computed at seizure and after imaging, but not before and after analysis. This means that if the image is altered during analysis, the alteration is not detected. The correct procedure is to compute the hash at every stage and to verify it at the beginning of each stage.
- Inadequate documentation. The chain of custody record is incomplete — it does not record every transfer of custody, or the signatures are missing. The correct procedure is to maintain a complete and contemporaneous record, with signatures at every stage.
- Use of unverified tools. The analysis tools are used without verification. The correct procedure is to verify the tools — i.e., to test them on known data and to confirm that they produce the expected results. This is typically done by the National Institute of Standards and Technology (NIST) Computer Forensics Tool Testing (CFTT) program, which publishes test results for forensic tools.
The expert's duty to the court
The expert's duty is to the court, not to the party instructing them. This is a fundamental principle of expert evidence, and it is set out in the Civil Procedure Rules Part 35.3:
CPR 35.3: "It is the duty of experts to help the court on matters within their field of expertise. This duty overrides any obligation to the person instructing or employing them."
This duty has several implications:
- Objectivity. The expert must provide an unbiased opinion. The expert must not tailor their opinion to support the case of the party instructing them. If the evidence does not support the party's case, the expert must say so.
- Full disclosure. The expert must disclose all material facts, including those that are adverse to the party's case. The expert must not omit findings that are unhelpful to the party's case.
- Methodology. The expert must use a methodology that is reliable and widely accepted in the relevant field. The methodology must be transparent — i.e., the expert must be able to explain, in terms a layperson can understand, what they did and why.
- Changes of opinion. If the expert's opinion changes during the course of the proceedings — e.g., because new evidence comes to light — the expert must inform the party instructing them and the court immediately. The expert must not continue to advance an opinion that they no longer hold.
- Independence. The expert must not have a financial interest in the outcome of the case. The expert's fee is for their time and expertise, not for a particular opinion.
If the expert breaches their duty to the court, the court may exclude the expert's evidence under s.78 of PACE (in criminal proceedings) or under the Civil Procedure Rules (in civil proceedings). The expert may also be reported to their professional body, which may take disciplinary action, including revocation of their professional accreditation.
Conclusion
Chain of custody for digital evidence is a rigorous, multi-step process designed to ensure that the evidence presented in court is the evidence that was seized, and that it has not been altered from the moment of seizure to the moment of presentation. The process is governed by the ACPO/NPCC principles, the Civil Procedure Rules Part 35, and the expert's duty to the court.
The process is not a set of rules to be followed blindly. It is a framework for ensuring the integrity of the evidence, and the expert must understand the purpose of each step in order to apply it correctly. Where the process cannot be followed — e.g., because the device was powered on before seizure — the expert must document the deviation and explain its impact on the evidence.
If you are instructing a forensic expert, you should ask them to explain their methodology, the tools they use, and the documentation they maintain. A competent expert will be able to explain each step of the process and the documentation that supports it. If the expert cannot, or will not, you should instruct a different expert.
If you are a forensic practitioner reading this, you should ensure that your practice complies with the ACPO/NPCC principles and the Civil Procedure Rules Part 35. The consequences of non-compliance are severe — the evidence may be excluded, the case may be lost, and the practitioner may be reported to their professional body.
Editorial policy: This article is written for instructing solicitors, in-house legal teams, and law-enforcement professionals. It describes how digital forensic examinations are conducted in professional practice. Nothing here constitutes instruction for unqualified individuals. All work is conducted under professional indemnity insurance and is governed by the laws of England and Wales, the Civil Procedure Rules Part 35, and the ACPO/NPCC Principles of Digital Evidence.
© 2026 SolveAssist. All rights reserved.