Evidence Handling and Chain of Custody Guide: Collecting Digital Evidence That Holds Up

Digital evidence that cannot show where it came from, who touched it and that it has not changed is worth little to a court, a regulator, an insurer or a disciplinary panel. This template gives [Organisation] a ready-to-adopt procedure for identifying, collecting, preserving and handing over digital evidence during any security incident: endpoint images, memory captures, triage collections, cloud snapshots, log exports and SaaS audit records. It is written for incident responders, forensic analysts, cloud and IT administrators who may be first on scene, and the legal, HR and privacy staff who rely on the result. It draws on RFC 3227, NIST SP 800-86 and ISO/IEC 27037 in general terms. Technique depth sits in the Digital Forensics (DFIR) Guide; this page is the procedure and the forms. Replace every [bracketed] placeholder and exercise it before you need it.

How to use this template

• Adopt, then tailor: attach sections 1 to 8 to your incident response plan as the evidence procedure that every incident playbook calls, including the Data Exfiltration Playbook and the Incident Response Plan Template.
• Decide the evidential standard per incident: internal only, civil or disciplinary, or possible criminal proceedings. Section 1.3 sets the default; legal counsel can raise it, never lower it once collection has started.
• Copy the custody form in 3.4 into your case management tool or keep it as a printed form in the response kit.
• Treat evidence as sensitive data: images and log exports hold personal data, credentials and secrets. Section 4 controls access, and section 6 controls retention and disposal.
• Review annually and after any case where evidence was challenged. Owner: [DFIR Lead].

1. Scope and triggers

1.1 This procedure applies to any data collected by or for [Organisation] to establish what happened in a security incident, investigation or legal matter, on company devices, servers, cloud accounts, SaaS tenants and network systems. Personal devices are collected only with consent or legal authority, on the advice of [General Counsel].

1.2 Triggers: declaration of a High or Critical incident; any incident that may involve personal data, fraud, insider activity or extortion; a request from legal, HR, an insurer or law enforcement; a litigation hold notice.

1.3 Evidential standards.

1.4 RFC 3227 describes the qualities evidence needs: admissible, authentic, complete, reliable and believable. Every step below exists to protect one of them.

2. Roles and contacts

2.1 Record 24/7 contacts for the incident response retainer, cloud provider support and the law enforcement cyber unit. See the Incident Response Retainer Buyer's Guide.

3. Detection and triage

3.1 Identify before you collect. List candidate sources: hosts, accounts, cloud resources, logs and their retention clocks. Short-retention sources go first (for example, Microsoft Purview Audit Standard keeps records for 180 days by default, and some firewall or proxy logs roll in days).

3.2 Record the clock. Note the system time against a trusted UTC source before collecting, and write every time in the case log in UTC with the offset.

3.3 Collect in order of volatility. RFC 3227 orders sources from most to least volatile: registers and cache; routing table, ARP cache, process table, kernel statistics and memory; temporary file systems; disk; remote logging and monitoring data; physical configuration and network topology; archival media. In practice for enterprise response:

1. Memory capture of the live host (see the Memory Forensics Guide).
2. Triage collection of high-value artefacts with a tested tool such as KAPE or Velociraptor (see the KAPE and Triage Collection Guide and the Velociraptor Guide).
3. Full disk image where the standard in 1.3 or the questions need it.
4. Log exports from SIEM, EDR, cloud and SaaS before retention expires.
5. Configuration and topology exports, then backups and archives.

Decision point A: live response versus power-off. RFC 3227 advises not to shut down before collection is complete, and not to trust programs on the suspect system. Run tools from trusted media or a signed agent. Power off without memory capture only if the host is actively destroying data and cannot be isolated.

3.4 Chain of custody form. Complete one per evidence item. The fields follow what RFC 3227 section 4.1 says must be describable: where, when and by whom evidence was found, collected, handled and examined; who held it and how it was stored; and when and how custody changed.

4. Containment

In this procedure, containment means containing the evidence: protecting it from change, loss and unauthorised access.

1. Isolate rather than unplug: use EDR network containment so the host stays reachable for collection. RFC 3227 warns that disconnecting a system can itself trigger destructive actions.
2. Block writes: attach physical media through a hardware write blocker or a tested software blocker, and image to forensically wiped, verified media.
3. Hash at acquisition and on every copy: use SHA-256 as the primary digest; SP 800-86 (2006) names MD5 and SHA-1, which are no longer collision-resistant. See the Hashing Guide.
4. Preserve cloud evidence in place, then copy: take volume snapshots (an Amazon EBS snapshot is a point-in-time copy from which a new volume starts as an exact replica), copy them to a dedicated forensic account, export logs, and record resource IDs and API calls. See the Cloud Forensics Guide.
5. Lock storage: write evidence to WORM storage. With S3 Object Lock, compliance mode blocks deletion by any user including root, and a legal hold stays in force until explicitly removed, independently of the retention period.
6. Restrict access: named examiners only, every access logged, and the storage separate from the production identity plane so a compromised admin cannot reach it.

Decision point B: collect a full image or a targeted triage set. Choose full images for criminal-standard cases and hosts at the centre of the incident; triage for breadth across many hosts.

Decision point C: place a legal hold on mailboxes, SaaS data and storage when legal counsel expects litigation or regulatory inquiry. See the eDiscovery and Legal Hold Guide.

5. Eradication

5.1 No system is wiped, reimaged, rotated or deleted until the Evidence Custodian confirms that the items in the register for it are acquired and verified. Incident playbooks must call this check before their eradication step.

5.2 Credential and NHI evidence before resets. Before rotating keys and tokens, export the key or token identifiers, creation and last-used times, the audit log of their use and any OAuth consent records. A reset can remove the last-used data that shows when a key was abused. Record the secrets themselves only if legal counsel needs them, encrypted, never in the case log. See the Windows Forensic Artefacts Guide for host-side credential artefacts.

6. Recovery

1. Analyse working copies only; re-verify the master hash before and after each examination session.
2. Keep evidence for the period set by [Organisation]'s retention schedule: [12] months for internal cases, and until legal counsel releases it for disciplinary, civil or criminal matters.
3. Dispose of evidence by secure erasure or destruction, authorised by legal counsel and recorded on the custody form.
4. Release legal holds in writing when the matter closes.

7. Communication and notification

7.1 Handover to third parties. Law enforcement, regulators, insurers and outside counsel receive verified copies with a copy of the custody form; the transfer is logged. Legal counsel approves every external disclosure.

7.2 Privacy of evidence. Evidence often contains personal data of staff, customers and third parties. The DPO records the lawful basis, collection is limited to what the investigation needs, and access is restricted to named people. Employee monitoring evidence must align with [Organisation]'s acceptable use and monitoring notices. See the UK GDPR and Data Protection Act 2018 Guide.

7.3 Privilege. Where counsel directs the investigation, mark reports and notes as instructed and keep factual evidence separate from legal advice.

8. Post-incident review

8.1 Within [10] business days of case closure, review: was any evidence lost to retention or premature reimaging; were hashes verified at every transfer; did any custody gaps arise; how long from declaration to first acquisition.

8.2 Feed findings into the Post-Incident Review and Root Cause Analysis Template and update log retention where evidence was missing.

Implementation guidance

Evidence sources and how to preserve them.

Rollout.

1. Build a response kit: write blockers, wiped and verified drives, trusted tool media, printed custody forms, evidence bags and seals.
2. Pre-create a forensic cloud account per provider with WORM storage, cross-account snapshot copy permissions and restricted access.
3. Validate tools (record version and test against a known image) and keep the validation record. The NIST Computer Forensics Tool Testing programme publishes test results that help.
4. Train first responders on section 3 and 4 only: what not to do matters most.
5. Exercise with a mock case through to handover, then audit the custody record. Rollback: if a collection step fails, record the failure and the retry; never overwrite or quietly replace an entry.

Small vs large organisations. A small organisation can rely on its retainer for acquisition, but must still own first response, log exports and the custody form, and agree in the contract who holds evidence. A large organisation needs an evidence register system, trained first responders per region and documented cross-border transfer rules for evidence containing personal data.

Metrics. Time from incident declaration to first verified acquisition; percentage of items with complete custody forms; hash verification failures; evidence lost to retention or reimaging per quarter; percentage of critical systems whose logs meet the retention target.

Framework mapping.

Standards and references

• IETF: RFC 3227 Guidelines for Evidence Collection and Archiving
• NIST: SP 800-86 Guide to Integrating Forensic Techniques into Incident Response
• ISO: ISO/IEC 27037 Guidelines for identification, collection, acquisition and preservation of digital evidence
• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• AWS: Locking objects with Object Lock
• AWS: Amazon EBS snapshots
• Microsoft Learn: Manage audit log retention policies

Related NHI Mgmt Group resources: Digital Forensics (DFIR) Guide · Memory Forensics Guide · Cloud Forensics Guide · KAPE and Triage Collection Guide · Digital Forensics Tools Buyer's Guide