Sign In

TR1.8 Chain of Custody and Evidence Integrity

· Module 1 · Free
Operational Objective
The Integrity Question: When the investigation team opens the memory dump or the KAPE collection 3 days after the triage responder captured it, they need to trust that the evidence has not been modified — accidentally or deliberately — since collection. The answer to "can we trust this evidence?" is the chain of custody: a documented record of who had the evidence, when, and whether the integrity hash still matches the original. Without chain of custody, the evidence is a file of unknown provenance — useful for intelligence but not for legal proceedings, regulatory compliance, or definitive investigation conclusions.
Deliverable: The chain-of-custody log template, the SHA256 verification procedure, the evidence transfer protocol, and the integrity verification checklist.
Estimated completion: 20 minutes
EVIDENCE INTEGRITY — HASH AT EVERY TRANSITIONCOLLECTIONSHA256 at captureTRANSFERVerify hash on receiptSTORAGEVerify hash before analysisANALYSISWork on COPY, keep original

Figure TR1.8 — Evidence integrity verification at every transition point. The SHA256 hash computed at collection must match at transfer, storage, and pre-analysis verification. Any mismatch indicates corruption or tampering.

The SHA256 integrity chain

Every evidence file captured during triage must have a SHA256 hash computed at the moment of collection. This hash serves as the file’s fingerprint — any modification to the file (even a single bit change) produces a completely different hash.

Computing hashes at collection time:

1
2
3
4
5

# Linux: hash all files in the evidence directory
sha256sum /IR/*  > /IR/hashes.txt
cat /IR/hashes.txt
# a7c3e1b2d4f5e6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1  /IR/memory.lime
# d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5  /IR/auth.log

1
2
3
4
5

# Windows: hash the KAPE collection
Get-FileHash "E:\IR\DESKTOP-NGE042\KAPE.vhdx" -Algorithm SHA256 | Format-List
# Algorithm : SHA256
# Hash      : A7C3E1B2D4F5E6A7B8C9D0E1F2A3B4C5D6E7F8A9B0C1D2E3F4A5B6C7D8E9F0A1
# Path      : E:\IR\DESKTOP-NGE042\KAPE.vhdx

The production triage script from TR4.10 computes hashes automatically as the final step — the 99_hashes.txt file contains the SHA256 of every collected artifact.

The chain-of-custody log

CHAIN OF CUSTODY LOG

Case Reference: INC-2026-0406-001

#ItemCollected ByDate/Time (UTC)SHA256StorageTransfer ToTransfer DateVerified
1memory.lime (8.0 GiB)R. Osei2026-04-06 15:25a7c3e1…USB WD-123456J. Chen (IR Lead)2026-04-06 16:00✅ Hash matches
2auth.log (847 KB)R. Osei2026-04-06 15:26d4e5f6…USB WD-123456J. Chen (IR Lead)2026-04-06 16:00✅ Hash matches
3catscale.tar.gz (147 MB)R. Osei2026-04-06 15:28b8c9d0…USB WD-123456J. Chen (IR Lead)2026-04-06 16:00✅ Hash matches
4EBS snap-0abc123R. Osei2026-04-06 15:30N/A (cloud)AWS us-east-1--Snapshot verified

At transfer: The receiving party (investigation team lead) verifies the SHA256 hash of each item: sha256sum memory.lime — if the hash matches the collector’s hash, the evidence has not been modified during transfer. Both parties sign (or digitally acknowledge) the transfer.

At analysis: The analyst creates a WORKING COPY of the evidence and analyses the copy — never the original. The original is preserved unmodified with its original hash intact. If the analysis tool accidentally modifies a file (some tools update access timestamps when opening files), only the working copy is affected.

Investigation Finding — IF-2026-TR1-COC-001

Artifact: Chain-of-custody template for NE incident response

Source: Operational standard.

Findings:

Every triage evidence item requires: item description with size, collector identity, collection timestamp (UTC), SHA256 hash at collection, storage location with media identifier, and transfer records with hash verification at each hand-off. The production triage script generates items 1-5 automatically. The transfer log and verification are manual.

  • Proves: The chain-of-custody process satisfies: NIST SP 800-86 (evidence integrity), GDPR Article 33(3)(d) (measures taken), NIS2 Article 23(4)(a) (incident assessment), and common law evidence admissibility requirements (authenticity, integrity, continuity).
  • Does not prove: That the evidence collection itself was legally authorised (requires reference to the IR policy delegation of authority). That the evidence has not been modified before the FIRST hash was computed (the hash verifies integrity from that point forward, not before).
  • Next step: Ensure the chain-of-custody log template is included in the triage USB toolkit and pre-populated with the case reference field.
Try it: practice the hash verification workflow
  1. Create a test file: echo "test evidence" > /tmp/evidence.txt
  2. Hash it: sha256sum /tmp/evidence.txt — record the hash
  3. Copy to another location: cp /tmp/evidence.txt /tmp/evidence_transfer.txt
  4. Verify: sha256sum /tmp/evidence_transfer.txt — does the hash match?
  5. Modify the transferred file: echo "tampered" >> /tmp/evidence_transfer.txt
  6. Re-verify: sha256sum /tmp/evidence_transfer.txt — the hash is COMPLETELY different

This demonstrates that even appending a single word produces a completely different hash — any modification is detectable.

Compliance Myth: "Chain of custody is only needed for law enforcement cases"

The myth: Chain-of-custody documentation is a legal requirement for criminal cases only. Internal incidents handled by the SOC team do not need formal evidence tracking.

The reality: Chain of custody serves multiple purposes beyond criminal prosecution: (1) Regulatory compliance — GDPR Article 33 requires demonstrating the “measures taken to address the breach.” A documented chain of custody proves the organisation handled evidence professionally. (2) Insurance claims — cyber insurance claims require evidence of the incident and the response. Unchained evidence may be challenged by the insurer. (3) Employment actions — if the incident involves an insider threat and leads to disciplinary action, the evidence chain supports the HR process. (4) Investigation integrity — even for purely internal investigations, the investigation team needs to trust that the evidence they are analysing is authentic and unmodified. A 2-minute chain-of-custody entry per evidence item provides this trust. Skipping it saves 2 minutes but undermines every subsequent use of the evidence.

Digital evidence handling procedures

Evidence handling extends beyond hashing. The triage responder must address storage, transfer, and retention requirements for the evidence to remain legally defensible.

Write-protection: USB drives used for evidence storage should be hardware write-protected after collection (physical switch on the drive) or software write-protected. This prevents accidental modification of evidence files. Never store evidence on the compromised system’s local disk — the attacker may modify or delete it, and any writes to the disk may overwrite deleted file evidence in unallocated space.

Encryption in transit: evidence transferred over the network (SCP, SFTP to the analysis workstation) must use encrypted channels. Evidence on USB should use encrypted drives (BitLocker for Windows, LUKS for Linux) with the decryption key documented separately from the physical media. If the USB is lost or stolen, the encryption prevents unauthorised access to the evidence.

Retention: evidence must be retained for the duration required by applicable regulations. GDPR does not specify a minimum retention period, but the supervisory authority may request evidence during their investigation (months to years). NIS2 Article 23 requires retaining incident documentation. The organisation’s IR policy should specify: minimum retention period per incident severity, storage location (physical and logical), access controls (who can access the evidence locker), and destruction procedure after the retention period expires.

At NE, the evidence lifecycle follows: collection (triage responder, 15-30 minutes) then transfer (to investigation team, documented handoff) then analysis (investigation team, days to weeks) then legal hold (if regulatory notification required, indefinite until case closed) then archival (encrypted, locked storage, minimum 3 years) then destruction (secure deletion with verification, documented).

The evidence integrity verification must occur at EVERY transfer point in this lifecycle. When Rachel hands evidence to Marcus (the IR analyst), Marcus verifies the SHA256 hashes match the collection manifest. When Marcus transfers evidence to the legal team for regulatory submission, the legal team re-verifies. Any hash mismatch at any transfer point means the evidence was modified — the modified copy must not be used, and the chain-of-custody log must document the failure.

The triage responder’s specific responsibilities

The triage responder handles evidence for approximately 15-30 minutes (from first collection to handoff). During this window, the responder must: hash all evidence at collection time (the triage scripts from TR3.8 and TR4.10 do this automatically), document the collection in the case log with the 6 required fields (who, what, when, where, how, hash), store evidence on controlled media not connected to the compromised system, and execute the handoff with documented transfer acknowledgment from both parties.

The handoff form at NE: “Evidence transferred from [Collector] to [Recipient] at [timestamp UTC]. Evidence: [media description, serial number]. Files: [count]. SHA256 manifest: [filename] (verified by recipient: YES/NO).” Both parties retain a signed copy.

Troubleshooting

“I forgot to hash the evidence at collection time.” Hash it NOW and document: “Hash computed at [current time], approximately [X minutes] after collection. Evidence was stored on USB WD-123456 in the SOC evidence cabinet during the gap.” The late hash is less ideal than an immediate hash (it cannot prove the evidence was unmodified during the gap), but it still proves integrity from this point forward. Better a late hash than no hash.

Beyond this investigation: Chain of custody connects to TR0.6 (where the legal and regulatory context for evidence handling is established), Practical Incident Response IR22 (where the chain-of-custody log becomes an appendix to the formal incident report), and Practical GRC (where evidence handling procedures are documented as part of the incident response plan for ISO 27001 and SOC 2 compliance).
Operational Artifact — Chain of Custody Template

Per evidence item: Description + size | Collector | Timestamp (UTC) | SHA256 | Storage location At transfer: Receiving party verifies SHA256 matches. Both parties acknowledge. At analysis: Work on a COPY. Preserve the original unmodified. Automated: The triage script produces hashes.txt with SHA256 for every collected file. Manual: Collector identity, storage location, transfer log.

© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.

You're reading the free modules of this course

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.

View Pricing See Full Syllabus
← TR1.7 The Preservation Decision Tree TR1.9 Cross-Environment Evidence Correlation →