# Forensic Evidence Record: [Case ID] [Evidence item]

> Acquisition log and chain of custody record for one item of
> potential digital evidence, from identification to return or
> disposal. It records who handled the item, when, why and how, the
> acquisition method and tool, the hash values that prove the copy is
> unchanged, and every transfer between custodians. Structure aligned
> with ISO/IEC 27037:2012 (identification, collection, acquisition and
> preservation of digital evidence, cited by name only) and based on
> NIST SP 800-86 and IETF RFC 3227 (BCP 55). Replace every
> `[bracketed]` value and every row marked *Example*. Rules on
> admissibility differ by jurisdiction: this is a documentation format,
> not legal advice. Check the current official text and a qualified
> professional.

<!--
Guidance: How to use this template
- Use one record per evidence item (a laptop, a disk image, a memory
  capture, a log export). A case usually has several records linked by
  the case ID.
- Start the record before you touch the item and write entries at the
  time of each action, not afterwards from memory.
- Never leave a gap in the custody log: every hand-over has a giver, a
  receiver, a date and time with time zone, and a reason.
- Work on verified copies. The original is acquired once, hashed,
  sealed and stored; analysis runs on a working copy whose hash
  matches.
- If the matter may go to court, a regulator or a disciplinary
  hearing, involve legal counsel early. Internal investigations of
  employees also raise privacy and employment-law questions.
- Common pitfall: switching off or rebooting a running system before
  capturing volatile data, which destroys memory, network state and
  running processes (RFC 3227 section 2.2).
-->

## Document control

<!-- Guidance: The evidence ID is written on the seal and the label, and must match this record exactly. Restrict access to the record; it may contain personal data. -->

| Field | Value |
|---|---|
| Case ID | [CASE-YYYY-NNN] |
| Evidence ID | [EV-YYYY-NNN-NN] |
| Incident or matter reference | [INC-ID / legal matter] |
| Version | [0.1] |
| Status | [Open / In storage / In analysis / Returned / Disposed] |
| Case lead | [@case-lead] |
| First responder | [@first-responder] |
| Legal counsel | [@counsel] |
| Legal hold in place? | [Yes, reference / No] |
| Time zone used in this record | [UTC] |
| Classification | [Restricted] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Case lead | [@name] | [Record complete and accurate] | YYYY-MM-DD |
| Evidence custodian | [@name] | [Storage and custody confirmed] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Record opened at identification |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Acquisition complete, item sealed and stored |

## 1. Authority and scope

<!-- Guidance: Record why you may collect this item. Without authority, evidence can be excluded and collectors exposed. Note any limits, for example personal folders or privileged legal material. -->

| Item | Value |
|---|---|
| Authority to collect | *Example:* Incident INC-2026-0412 declared by the CISO under the incident management procedure; acceptable use policy allows inspection of company devices |
| Approved by | [@name, role], YYYY-MM-DD |
| Purpose | *Example:* Determine how the attacker gained access to the finance workstation and what data left it |
| Scope limits | *Example:* Exclude the user's personal cloud storage; legal counsel reviews any privileged emails |
| Applicable rules checked | [Internal policy, employment law, evidence rules of the likely forum] |

## 2. Item identification

<!-- Guidance: Describe the item so that someone else can recognise it without doubt: make, model, serial number, condition and where it was found. Photograph it in place before moving it. -->

| Field | Value |
|---|---|
| Description | *Example:* Laptop, finance team, asset tag NRW-LT-2291 |
| Make, model, serial number | *Example:* [Make, model], serial [number] |
| Storage media inside | *Example:* One NVMe SSD 512 GB, full-disk encryption enabled |
| Location found | *Example:* Desk F3-12, Norrowind Retail head office, powered on, screen locked |
| State on arrival | [Powered on / off / sleeping], [network connected / disconnected] |
| Photographs | *Example:* EV-2026-012-01-P01 to P06 |
| Identified by | [@first-responder], YYYY-MM-DD hh:mm UTC |

## 3. Acquisition log

<!-- Guidance: Record every action in time order, including mistakes. Follow the order of volatility from RFC 3227 section 2.1: memory and network state before disk. Write down the tool name and version, and verify tools before use. -->

| Step | Time (UTC) | Action | Tool and version | By | Witness |
|---|---|---|---|---|---|
| 1 *(Example)* | 2026-10-12 09:41 | Photographed screen and connections | Camera, case kit 2 | [@first-responder] | [@witness] |
| 2 *(Example)* | 2026-10-12 09:48 | Captured volatile memory to sterile external drive EV-2026-012-02 | [Memory capture tool, version] | [@first-responder] | [@witness] |
| 3 *(Example)* | 2026-10-12 10:05 | Recorded network connections and running processes | [Live response script, version] | [@first-responder] | [@witness] |
| 4 *(Example)* | 2026-10-12 10:20 | Retrieved recovery key from key escrow, then shut down | Key escrow ticket KR-5521 | [@first-responder] | [@witness] |
| 5 *(Example)* | 2026-10-12 13:10 | Created physical image of SSD through hardware write blocker | [Write blocker model], [imaging tool, version] | [@forensic-analyst] | [@witness] |

## 4. Integrity verification

<!-- Guidance: Hash the source and the image with at least one strong algorithm (SHA-256 or stronger). Record the full value. Re-verify every time the item leaves storage or a copy is made. A mismatch is recorded and explained, never hidden. -->

| Object | Algorithm | Hash value | Computed at (UTC) | By | Match |
|---|---|---|---|---|---|
| Memory capture file *(Example)* | SHA-256 | [64 hexadecimal characters] | 2026-10-12 09:57 | [@first-responder] | Reference |
| SSD source, hashed by the imaging tool during acquisition through the write blocker *(Example)* | SHA-256 | [64 hexadecimal characters] | 2026-10-12 15:40 | [@forensic-analyst] | Reference |
| SSD image *(Example)* | SHA-256 | [64 hexadecimal characters] | 2026-10-12 15:42 | [@forensic-analyst] | Yes, equals source |
| Working copy 1 *(Example)* | SHA-256 | [64 hexadecimal characters] | 2026-10-13 08:15 | [@forensic-analyst] | Yes, equals image |

## 5. Chain of custody

<!-- Guidance: One row per transfer or storage event, signed by both parties. The chain must be continuous from collection to final disposal. Record seal numbers, and note whether the seal was intact on receipt. -->

| Entry | Date and time (UTC) | Released by | Received by | Purpose | Seal number and condition | Location |
|---|---|---|---|---|---|---|
| C-01 *(Example)* | 2026-10-12 10:30 | [@first-responder] | [@forensic-analyst] | Imaging | SB-77310, applied | Forensic lab bench 2 |
| C-02 *(Example)* | 2026-10-12 16:05 | [@forensic-analyst] | [@evidence-custodian] | Storage | SB-77311, applied after imaging | Evidence safe S1, shelf 3 |
| C-03 *(Example)* | 2026-10-20 11:00 | [@evidence-custodian] | [@external-examiner] | Independent examination | SB-77311, intact | Courier with tamper-evident bag |

```mermaid
sequenceDiagram
  participant FR as First responder
  participant FA as Forensic analyst
  participant EC as Evidence custodian
  participant EX as External examiner
  FR->>FA: Hand over laptop, seal SB-77310 (C-01)
  FA->>FA: Image SSD, verify hashes
  FA->>EC: Hand over sealed original, seal SB-77311 (C-02)
  EC->>EX: Release for independent examination (C-03)
```

## 6. Storage and handling

<!-- Guidance: Describe where the original and the copies are kept and who can access them. Protect against tampering, heat, magnetism, static and loss of power for battery-dependent devices. Keep an access log for the storage location. -->

| Item | Value |
|---|---|
| Original stored at | *Example:* Evidence safe S1, access logged, two custodians |
| Images stored at | *Example:* Encrypted evidence store, write-once bucket, access limited to case team |
| Retention period | [Per legal hold or retention schedule] |
| Special handling | *Example:* Mobile devices kept in a signal-blocking bag and charged |

## 7. Disposition

<!-- Guidance: Close the record only when legal counsel confirms the hold is lifted. Record how the item was returned or destroyed and who witnessed it. -->

| Field | Value |
|---|---|
| Disposition | [Returned to owner / Destroyed / Transferred to authority] |
| Date and time (UTC) | YYYY-MM-DD hh:mm |
| Authorised by | [@counsel] |
| Performed by and witness | [@name], [@witness] |
| Certificate or receipt | [Reference] |

## 8. Jurisdiction notes

<!-- Guidance: Name the rules of the forum where the evidence may be used and confirm them with counsel. The examples below are dated and may change. -->

| Jurisdiction | Example rule | Status as checked |
|---|---|---|
| United States (federal courts) | Federal Rules of Evidence, Rule 902(14): data copied from an electronic device can be self-authenticating when identified by a digital process such as a hash and certified by a qualified person | Checked 2026-10-30 at https://www.law.cornell.edu/rules/fre/rule_902 |
| United Kingdom (England and Wales) | Forensic Science Regulator statutory Code of Practice, version 2, published 5 June 2025, in force 2 October 2025, sets quality requirements for forensic science activities in criminal investigations | Checked 2026-10-30 at https://www.gov.uk/government/publications/forensic-science-activities-statutory-code-of-practice-version-2 |
| European Union | Rules of evidence are set mainly by each member state's procedural law; ask counsel in the member state concerned | Not applicable |

## 9. Glossary and references

<!-- Guidance: Keep terms consistent with the incident management procedure. -->

| Term | Meaning |
|---|---|
| Potential digital evidence | Data that may later be relied on to establish facts |
| Acquisition | Making a copy of data, with the method documented |
| Write blocker | Device or software that prevents writes to the source media |
| Hash value | Fixed-length value computed from data; any change to the data changes it |
| Chain of custody | Continuous record of who held the evidence, when and why |
| Order of volatility | Sequence of collection from the most short-lived data to the most persistent |

References (check the current official versions):

- ISO/IEC 27037:2012 Guidelines for identification, collection, acquisition and preservation of digital evidence (first edition; the ISO catalogue showed stage 90.60, close of systematic review, in October 2026, so check for a revision). Official text: ISO, purchase or licensed access: https://www.iso.org/standard/44381.html
- NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response (August 2006), phases of collection, examination, analysis and reporting: https://csrc.nist.gov/pubs/sp/800/86/final
- IETF RFC 3227 (BCP 55), Guidelines for Evidence Collection and Archiving (February 2002), sections 2.1, 2.2 and 4.1: https://www.rfc-editor.org/rfc/rfc3227.html
- Related templates: ops/incident-management-procedure, security/soc-playbook, security/security-logging-standard, compliance/asset-inventory

## Standard and licence note

Structure aligned with ISO/IEC 27037:2012, cited by name and process
names only; no text of the standard is reproduced. Official text: ISO,
purchase or licensed access at https://www.iso.org/standard/44381.html.
Based on NIST SP 800-86 (a US government publication) and IETF RFC
3227 (BCP 55), summarised in original wording. The rule descriptions in
section 8 are short summaries, not legal advice: check the current
official text and a qualified professional. All organisations, people
and identifiers in examples are fictional. Template licence: MIT.