Appendix F — Chain of Custody and Report Templates

Purpose. Ready-to-use, fill-in-the-blank forms — an evidence intake form, an evidence label, a chain-of-custody log, and a complete forensic report — that you can copy to your case folder and adapt, so the paperwork that makes your technical work admissible is never improvised at 2 a.m. on a deadline.

This appendix is the companion to the documentation discipline taught in Chapter 5 — The Forensic Process, deepened in Chapter 14 — Forensic Acquisition, and brought to its full form in Chapter 26 — The Forensic Report. Those chapters explain why each field exists and what it defends against; this appendix gives you the artifact to fill in. Use them together: a template you do not understand is a template you cannot defend on the stand.

Two worked examples run through this appendix so you can see a blank form and a completed one side by side. The intake/label/custody examples use the courtroom anchor case (case 2026-0142, the Dell Latitude 5420 — handled, as everywhere in this book, strictly at the level of device handling and procedure, never content). The full report example uses the civil Meridian Health Analytics (MHA) matter — the progressive-project case you build from Chapter 5 onward — because reporting findings requires substance, and that matter is non-sensitive. All hashes, serials, and offsets in the filled examples are illustrative but internally consistent with the chapters that introduced them.

Legal Note. These are templates, not legal advice. Your lab's accredited standard operating procedures (SOPs), your jurisdiction, and — in litigation — the governing rules (the Federal Rules of Civil Procedure and Evidence in U.S. federal court; the equivalents elsewhere) control the required contents and wording. Where a court, agency, or accreditation body (ISO/IEC 17025, ASCLD/LAB) mandates a specific form, theirs wins. Adapt these to that authority; do not substitute them for it. The legal framework itself is owned by Chapter 25 and tabulated in Appendix E.

F.1 How the documents fit together

These are not four unrelated forms; they are one continuous record of a piece of evidence from the moment you first touch it to the moment a court reads your conclusions. Each picks up where the last leaves off, and the same case number, item number, and acquisition hash thread through all of them so a reader can tie any sentence in the final report back to the sealed original.

   THE DOCUMENTATION TRAIL  (one item, four documents, no gaps)

   INTAKE  ─────▶  LABEL  ─────▶  CHAIN-OF-CUSTODY LOG  ─────▶  REPORT
   (F.3)           (F.4)          (F.5)                         (F.6)
   what arrived,   the item's     every hand-off: date/time,    findings,
   from whom,      identity       handler, action, location;    method,
   in what state   stuck to the   two signatures per transfer   hashes,
   + first hash    bag/item                                     conclusions
       │               │                  │                         │
       └───────────────┴──────────────────┴─────────────────────────┘
        case # + item # + acquisition hash appear on EVERY document
        (map to the Chapter-5 phases: IDENTIFY → PRESERVE → ANALYZE → REPORT)

Chain of Custody. The thread that binds these documents is the acquisition hash. It is computed once (at imaging), and it then appears on the intake form, the label, the custody log, the report's evidence inventory, the methodology, and every finding that rests on the image. If the hash in your finding does not match the hash in your inventory, you have handed opposing counsel a day of cross-examination — so generate the exhibit hash list mechanically (F.7) and copy-paste the value everywhere rather than retyping it.

F.2 Conventions used in every template

Apply these uniformly; consistency is itself a credibility signal.

• Placeholders appear in [SQUARE BRACKETS]. Replace every one. A bracket left in a released document is an error a reviewer should catch (see the checklist in F.7).
• Dates and times: ISO 8601 with an explicit timezone, e.g. 2026-06-25T08:05:00Z (the Z = UTC) or 2026-06-25 08:05 UTC. Prefer UTC for anything that feeds a timeline (the MACB-timestamp reasons are owned by Chapter 21). An unstated timezone is a finding waiting to be impeached.
• Hashes: record MD5 and SHA-256 (dual-hashing defeats the "MD5 is broken" cross-examination — see Chapter 5). FTK Imager emits MD5 + SHA-1 by default; if policy requires SHA-256, generate it with hashdeep/sha256sum/Guymager. When you abbreviate a hash in prose (9a1c…2e8) the full value must appear at least once in the inventory and the exhibit hash list (F.7).
• Signatures: every custody transfer is a two-signature event — released-by and received-by. Electronic equivalents (see F.5) must be attributable and tamper-evident.
• Contemporaneous, not reconstructed: fill these in as the action happens, not from memory at end of day. "If it isn't documented, it didn't happen."
• Container hash vs. acquisition (bitstream) hash: the SHA-256 of an .E01 file on disk (transit integrity) is not the same number as the hash of the acquired bitstream stored inside it (acquisition integrity). Label which is which; the distinction is established in Chapter 5 and reappears in the report inventory (F.6 §4).

F.3 Evidence intake form

The intake form is the first entry in an item's life. It records what physically arrived, from whom, when, and in what condition — before you open anything. It is the anchor the entire chain of custody hangs from.

How to fill it out. Complete it on receipt, before breaking any seal. Photograph the item as-received (sealed bag, labels, serials, condition) and reference the photo filenames. Record the device precisely — "a black laptop" is useless six months later in a deposition; make, model, serial, and capacity are defensible. Reconcile what arrived against the authority (warrant scope, consent, or work order) and against any pre-existing seal number. Leave the acquisition hash blank here — it is added after imaging — but reserve the field so the same form carries the value forward. Note radios/wireless capability (it decides whether the item needs a Faraday bag, per Chapter 14).

   EVIDENCE INTAKE FORM                                        Page ___ of ___
   ─────────────────────────────────────────────────────────────────────────
   Case / matter number ......... [CASE-NO]
   Item / exhibit number ........ [ITEM-NO]            Intake form # [INTAKE-NO]
   Received by (examiner/tech) .. [NAME, ROLE, ID]
   Date/time received ........... [YYYY-MM-DDThh:mm:ssZ]
   Received from ................ [NAME / AGENCY / COURIER]   Tracking # [____]

   AUTHORITY FOR EXAMINATION  (tie to Ch. 25 / Appendix E)
   [ ] Search warrant #[____], [issuing court], dated [____], offense [____]
   [ ] Written consent (scope: [____]; from [name, authority over device])
   [ ] Corporate authority (AUP + monitoring banner on file: [Y/N])
   [ ] Subpoena / court order #[____]      [ ] Other: [____]

   ITEM DESCRIPTION
   Type ......................... [laptop / desktop / HDD / SSD / phone / USB / SD / other]
   Make / model ................. [____]
   Serial / service tag ......... [____]
   Capacity (stated) ............ [____ GB/TB]
   Internal media (if host) ..... [make/model/serial of internal drive(s)]
   Wireless-capable? ............ [Y/N]  ->  Faraday bag required? [Y/N]
   Power state on receipt ....... [OFF / ON / UNKNOWN]  (if ON, see Ch. 15 triage)

   CONDITION ON RECEIPT
   Seal intact? ................. [Y/N]  Existing seal #[____]
   Tamper-evident bag #[____]   Anti-static bag? [Y/N]   Faraday bag? [Y/N]
   Physical condition / damage .. [e.g., lid scratched; no visible damage]
   Photographs taken ............ [Y/N]  File refs: [____]

   ACQUISITION (completed after imaging — see Ch. 14)
   Imaged? [Y/N]   Date/time [____]   Tool + version [____]   Format [E01/dd/AFF4]
   Write-blocker (make/model/fw) [____]   Validated this session? [Y/N]
   Acquisition hash  MD5 [________]  SHA-256 [________]  Source==image VERIFIED? [Y/N]

   Storage location assigned .... [evidence locker / shelf / safe ID]
   Intake signature ............. [signature]               Date [____]
   ─────────────────────────────────────────────────────────────────────────

Field reference.

Filled example (case 2026-0142 — device handling only):

   EVIDENCE INTAKE FORM                                        Page 1 of 1
   ─────────────────────────────────────────────────────────────────────────
   Case / matter number ......... 2026-0142
   Item / exhibit number ........ 01                          Intake form # 0142-I01
   Received by (examiner/tech) .. [Examiner], Forensic Examiner, ID [____]
   Date/time received ........... 2026-06-24T11:40:00Z
   Received from ................ Det. A. [badge], hand-delivered

   AUTHORITY FOR EXAMINATION
   [x] Search warrant #[2026-SW-1188], [County Superior Court], dated 2026-06-23,
       offense as named in the warrant.

   ITEM DESCRIPTION
   Type ......................... Laptop (with internal SSD)
   Make / model ................. Dell Latitude 5420
   Serial / service tag ......... 7F2X9Q3
   Capacity (stated) ............ 256 GB
   Internal media ............... Samsung MZVLB256HBHQ NVMe SSD, S/N S3TPNX0M412345,
                                  500,118,192 sectors x 512 = 256,060,514,304 bytes
   Wireless-capable? ............ Y (Wi-Fi/BT) -> Faraday bag required? Y
   Power state on receipt ....... OFF

   CONDITION ON RECEIPT
   Seal intact? ................. Y   Existing seal #SB-4471
   Tamper-evident bag #SB-4471   Anti-static bag? Y   Faraday bag? Y
   Physical condition ........... Lid scratched; no other visible damage
   Photographs taken ............ Y   File refs: 0142-IMG-001..014

   ACQUISITION
   Imaged? Y   Date/time 2026-06-25T08:05:00Z   Tool Guymager 0.8.13   Format E01
   Write-blocker .. Tableau T7u (NVMe), fw 2.x   Validated this session? Y
   Acquisition hash  MD5 9a1c0e6b4f7d2a83c5e10f9b6d4a72e8
                     SHA-256 4e1d8b9a6c0f23e7d5a1b4c8f02e96d3a7b5c1e0f8d2a4b6c9e3f1a07d5b2c8e
   Source==image VERIFIED? Y
   Storage location assigned .... Evidence locker B, shelf 3, bin 0142
   Intake signature ............. [signature]               Date 2026-06-24
   ─────────────────────────────────────────────────────────────────────────

F.4 Evidence label / exhibit tag

The label is the item's identity. It travels on the outside of the tamper-evident bag (or affixed to the item) so anyone can identify it without opening the seal. Keep it short — it is an identifier, not a record — and make sure every value on it matches the intake form and custody log exactly.

How to fill it out. Print one per item. Use the same case and item numbers as everywhere else. Write legibly and in indelible ink (or print). Add the acquisition hash once imaging is done (an abbreviated form is fine on the label as long as the full value lives on the intake form and exhibit hash list). For litigation, a Bates/exhibit number may be assigned later — reserve a line. Sign across the seal of the bag, not just on the label, so any later opening is visible and attributable (Ch. 14).

   ┌───────────────────────────  EVIDENCE  ───────────────────────────┐
   │  CASE / MATTER:  [CASE-NO]                ITEM #: [ITEM-NO]        │
   │  DESCRIPTION:    [make / model / type]                            │
   │  SERIAL:         [device serial]                                  │
   │  SEIZED/RECEIVED:[YYYY-MM-DD hh:mm UTC]   BY: [name / badge]      │
   │  LOCATION:       [scene ref / address]                            │
   │  SEAL #:         [tamper-evident bag #]                           │
   │  ACQ. HASH:      SHA-256 [abbrev…]   MD5 [abbrev…]   (full on file)│
   │  EXHIBIT/BATES #:[assigned at litigation]                         │
   │  HANDLED BY:     [initials]      ⚠ DO NOT OPEN EXCEPT PER LOG     │
   └──────────────────────────────────────────────────────────────────┘

Filled example (case 2026-0142):

   ┌───────────────────────────  EVIDENCE  ───────────────────────────┐
   │  CASE / MATTER:  2026-0142                ITEM #: 01              │
   │  DESCRIPTION:    Dell Latitude 5420 laptop (internal NVMe SSD)    │
   │  SERIAL:         7F2X9Q3  (SSD S/N S3TPNX0M412345)               │
   │  SEIZED/RECEIVED:2026-06-24 09:14 UTC     BY: Det. A. [badge]    │
   │  LOCATION:       [scene reference per warrant]                    │
   │  SEAL #:         SB-4471                                          │
   │  ACQ. HASH:      SHA-256 4e1d…c8e   MD5 9a1c…2e8                  │
   │  EXHIBIT/BATES #:[to be assigned]                                 │
   │  HANDLED BY:     [initials]      ⚠ DO NOT OPEN EXCEPT PER LOG     │
   └──────────────────────────────────────────────────────────────────┘

Tool Tip. If you must open a sealed, labeled item to work on it, record the existing seal number, open, then reseal with a new numbered tamper-evident seal and log both the opening and the new seal as custody entries. The label then shows the current seal; the log shows the full history of seals. Never reuse a seal number.

F.5 Chain-of-custody log

The custody log is the chronological, gap-free record of everyone who handled the item and what they did. It is the half of admissibility the hash cannot provide: the hash proves the bits did not change; the log proves people controlled the item the whole time. Courts require both (Ch. 14).

It has two parts: a one-time identity block (which item this log governs) and a running transfer log (one row per hand-off). Each transfer records date/time, who released it, who received it, the action/purpose, the location, and two signatures — matching exactly what the prompt for this appendix asks of a custody log (date/time, handler, action, location), with the released/received split that makes each line a true hand-off.

How to fill it out. Start it at seizure/receipt and never leave a gap. Every time the item — or its sealed original — changes hands, location, or custody status, add a row, contemporaneously. "Action/purpose" is specific: seizure, intake/storage, forensic imaging, return to storage, released to defense expert, transport to court, disposition. Both parties sign every transfer. The original is sealed after imaging and worked from copies; each time it leaves or returns to the locker, that is a logged transfer too. There is no such thing as a silent move.

Identity block (head of the log):

   CHAIN-OF-CUSTODY LOG                                         Page ___ of ___
   ─────────────────────────────────────────────────────────────────────────
   Case / matter number ..... [CASE-NO]        Item / exhibit number .. [ITEM-NO]
   Description .............. [make / model / type / serial]
   Seized / received by ..... [name / badge]   Date/time .. [YYYY-MM-DDThh:mmZ]
   Location seized .......... [scene ref / address]
   Acquisition hash ......... SHA-256 [____]   MD5 [____]   (added [date])
   ─────────────────────────────────────────────────────────────────────────

Transfer log (printable blank — copy rows as needed):

   TRANSFER LOG  (every hand-off; no gaps; two signatures per row)
   ┌──────────────────┬───────────────┬───────────────┬────────────────────┬───────────────┬─────────┐
   │ Date/Time (UTC)  │ Released by    │ Received by    │ Action / Purpose   │ Location      │ Sigs    │
   ├──────────────────┼───────────────┼───────────────┼────────────────────┼───────────────┼─────────┤
   │ [____T__:__Z]    │ [name]        │ [name]        │ [____]             │ [____]        │ R:__ V:__│
   │ [____T__:__Z]    │ [name]        │ [name]        │ [____]             │ [____]        │ R:__ V:__│
   │ [____T__:__Z]    │ [name]        │ [name]        │ [____]             │ [____]        │ R:__ V:__│
   │ [____T__:__Z]    │ [name]        │ [name]        │ [____]             │ [____]        │ R:__ V:__│
   └──────────────────┴───────────────┴───────────────┴────────────────────┴───────────────┴─────────┘
        R = released-by signature   V = received-by signature   (both required)

Filled example (case 2026-0142) — rendered as a table for readability:

Field reference.

Chain of Custody. The most common failure is not dramatic tampering — it is mundane sloppiness: a drive left out overnight, a colleague who "just took a quick look," an undocumented hour. Each is a gap a competent defense will turn into reasonable doubt about whether the evidence can be trusted at all. A gap does not automatically exclude evidence, but it shifts the fight from what the evidence shows to whether it can be believed — a fight you avoid with a pen, not an argument.

Tool Tip — electronic custody logs. A digital custody log is acceptable (often preferable) if it is attributable and tamper-evident: per-entry user authentication, immutable timestamps, an append-only audit trail, and ideally a running hash chain (each entry includes the hash of the previous entry, so any later edit is detectable). Many evidence-management systems (and lab LIMS) do this. Whatever the medium, the same six data points per transfer are mandatory, and the system's own audit log becomes part of the record you may have to produce.

F.6 The forensic report template

This is the centerpiece. The report is the only part of your work anyone else will see; its anatomy and the craft of writing it are owned by Chapter 26. Below is a fill-in-the-blank template for every section Chapter 26 promised this appendix would provide, with short guidance, followed by filled excerpts from the MHA matter.

How to use it. Copy the whole skeleton (end of this section) into your report editor, then expand each section using the per-section templates. Write the executive summary last, when you actually know what the report concludes. Keep the interpretive ladder visible — label facts, inferences, and opinions distinctly and never let one masquerade as another. Tie every finding to a reproducible coordinate (path, offset, MFT entry, hash, timestamp, exhibit). Document negative findings. Pin every tool to a version. Run the F.7 review checklist before release.

Cover page

   ════════════════════════════════════════════════════════════════════════
                       FORENSIC EXAMINATION REPORT
   ════════════════════════════════════════════════════════════════════════
   Case / matter ......... [CASE-NO]   (internal matter [____])
   Report title .......... [e.g., Report of Digital Forensic Examination]
   Prepared for .......... [retaining party / agency / counsel]
   Prepared by ........... [examiner name, title, certifications]
   Laboratory ............ [lab name, accreditation # if any]
   Report version ........ [v1.0]      Status: [DRAFT / PRELIMINARY / FINAL]
   Report date ........... [YYYY-MM-DD]
   Pages ................. [N]   Distribution: [named recipients only]
   ════════════════════════════════════════════════════════════════════════
   CONFIDENTIAL — prepared in anticipation of [litigation / proceeding].
   Contains [PII / privileged] material; handle per [protective order / policy].

Tip. Label drafts clearly as drafts and control distribution. A "preliminary" finding you later revise is defensible; a "final" conclusion you must walk back is a credibility wound. An early draft with a half-formed conclusion is exactly the document opposing counsel hopes to find.

§1 Administrative / case information

Establishes who, what, when, and by what authority. Dull and essential — an error here undermines everything after it.

   1. ADMINISTRATIVE / CASE INFORMATION
   Case / matter number ......... [CASE-NO]
   Requesting party ............. [agency / attorney / client + contact]
   Examiner ..................... [name, title, certifications, ID]
   Laboratory ................... [name, accreditation]
   Key dates:   request [____]   evidence received [____]
                examination [____ to ____]   report [____]
   Report version / status ...... [vN.N / DRAFT|PRELIMINARY|FINAL]
   Related reports .............. [prior versions, co-examiner reports]

§2 Executive summary

One page, plain language, written last, read first. The bottom line a busy decision-maker can act on in ninety seconds — including bad news. No jargon, no byte offsets, no overstatement.

   2. EXECUTIVE SUMMARY
   You were asked to [the assignment, in one sentence].
   In summary, the examination found that [the principal findings in plain
   language — what the evidence establishes and, where relevant, what it does
   NOT establish]. [State any material limitation or bad news here, not buried
   later.] Details, methods, and supporting exhibits follow.

§3 Scope and authorization

What you were authorized to examine, what you were asked to determine, and what you deliberately did NOT examine. Your defense against the accusation that you exceeded your authority.

   3. SCOPE AND AUTHORIZATION
   Authority .................... [warrant #/court/offense | consent + scope |
                                  corporate authority (AUP + monitoring banner)
                                  | subpoena/order #]   (see Ch. 25 / Appendix E)
   In scope ..................... [the questions/artifacts you were asked to examine]
   Out of scope ................. [what you deliberately did not examine, and why]
   Assumptions affecting scope .. [e.g., examination limited to the provided image]

§4 Evidence inventory (with hashes)

Every item, described so precisely no one can confuse it with another device on earth, each carrying its acquisition hashes. The hashes here tie every later finding to a provably unaltered source.

   4. EVIDENCE INVENTORY
   Item [ITEM-NO]:
     Description ........ [make/model/type; internal media make/model/serial]
     Serial ............. [____]   Capacity .. [____ bytes (____ sectors x ____)]
     Condition on receipt [____]   Received .. [date]   from [____]
     Acquired ........... [date] using [tool + version] to [E01/dd/AFF4]
     Write-blocker ...... [make/model/fw; validated this session Y/N]
     Acquisition (bitstream) hash:  MD5 [____]   SHA-256 [____]
       Source == image VERIFIED? [Y/N]
     Container (.E01 file) hash:    SHA-256 [____]   (transit integrity)
     Working copy re-verified before analysis? [Y/N]

Filled excerpt (MHA matter):

   4. EVIDENCE INVENTORY
   Item MHA-2026-001:
     Description ........ HP EliteBook 840 G7 laptop; internal Samsung PM981a
                          NVMe SSD, S/N S4GXNX0R612345
     Serial ............. 5CG0XXYYZZ
     Capacity ........... 512,110,190,592 bytes (1,000,215,216 sectors x 512)
     Condition .......... No visible damage; received sealed (bag MHA-EB-0007)
     Received ........... 2026-06-24T14:30:00Z from MHA IT, via counsel
     Acquired ........... 2026-06-25 using Guymager 0.8.13 to compressed E01
                          (image set: mha-laptop.E01)
     Write-blocker ...... Tableau T356789u SATA/NVMe bridge, fw 1.2.3 (validated)
     Acquisition (bitstream) hash:
                          MD5    e7c4a1b9f2d6038a5c1e9b4d7f0a2c63
                          SHA-256 2a5f8c1e9b4d7a0c3f6e2b5d8a1c4f7092e5b8d1a4c7f0e3b6d9a2c5f8e1b4d7
                          Source == image VERIFIED.
     Container (.E01) hash:
                          SHA-256 b7e0c3f6a9d2b5e8a3f5c9d2b8e14f6079c2d5a8b1e4f7c0d3a6b9e2c5f8a1d4
     Working copy re-verified before each analysis session: Yes.

§5 Tools and methodology

How you did the work, in enough detail that an independent examiner could repeat it and reach the same result — the reproducibility Daubert demands. Pin exact versions; note validation; describe the process at a level a peer can replay.

   5. TOOLS AND METHODOLOGY
   5.1 Tool version block (pin EVERY tool; note last validation)
       [tool]  [exact version]  [build/hash if any]  [validated against ____ on ____]
       ...
   5.2 Process (reproducible, in order)
       - Verified write-blocker on scratch media before acquisition.
       - Acquired Item [__] via [tool/version]; dual-hash; source==image verified.
       - Mounted image read-only / loaded into [tool]; re-verified working-copy hash.
       - [recovered deleted files / carved unallocated / parsed registry / built
          timeline / extracted artifacts ...] — each step with tool + version.
       - Identified known files by hash-set match where applicable (no unnecessary
          visual review — see Ch. 28).
   5.3 Validation & standards
       - Tools used are [NIST CFTT-tested / validated in-house on ____].
       - Methodology consistent with [NIST SP 800-86; ISO/IEC 27037 (acquisition);
          ISO/IEC 27042 (analysis); SWGDE; lab SOP #____].

Filled excerpt — tool version block (MHA):

   5.1 Tool version block
       Guymager            0.8.13        acquisition (E01), dual-hash
       The Sleuth Kit      4.12.1        fls / icat / istat — deleted-file recovery
       Autopsy             4.21.0        GUI over TSK; artifact parsing
       RegRipper           3.0           registry hive parsing (USBSTOR, MountedDevices)
       plaso / log2timeline 20240308     super-timeline (Ch. 21)
       bulk_extractor      2.1.1         email/URL feature extraction
       ExifTool            12.x          document/photo metadata
       Python              3.12          Appendix B helpers
       (each validated against the NIST CFReDS Hacking Case image on 2026-06-01)

§6 Findings

The substantive core. Organize by evidence item OR by investigative question; either way, tie every finding to its evidence. Each finding has four parts — observation (fact), supporting artifacts (reproducible coordinates), interpretation (qualified inference/opinion), and limitation. Skip a part and the finding wobbles.

   6. FINDINGS
   Finding F-[NNN]: [short, neutral, descriptive title]
     Exhibit/item ...... [which item/file this rests on]
     Observation (fact): [the verifiable observation — what the data shows]
     Supporting artifacts (reproducible — see appendices):
        - [path / MFT or inode entry / byte offset / signature]
        - [hash of the file or artifact; exhibit reference]
        - [timestamp(s) with source: $SI / $FN / log / registry; timezone]
     Interpretation (supported inference/opinion, with confidence language):
        [the reasonable reading of the facts; label opinion as opinion]
     Limitation:
        [what this finding does NOT establish]
   (repeat per finding; INCLUDE negative findings)

Filled finding — positive (MHA):

   Finding F-003: Mass-storage USB device connected; proprietary files copied
     Exhibit/item ...... Item MHA-2026-001 (mha-laptop.E01), Exhibits 3a–3d
     Observation (fact):
        A USB mass-storage device (SanDisk Ultra, iSerialNumber
        4C530001230919115201) was connected to the system; LNK (shortcut)
        artifacts reference files on its volume; a deleted spreadsheet matching
        the company dataset was recovered from the user profile.
     Supporting artifacts (reproducible):
        - Registry: HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR\
          Disk&Ven_SanDisk&Prod_Ultra&Rev_1.00\4C530001230919115201
        - First/last connect: C:\Windows\INF\setupapi.dev.log; last connected
          2026-06-18T21:09:00Z; volume serial 1A2B-3C4D (HKLM\SYSTEM\MountedDevices),
          mounted as drive E:
        - LNK files in C:\Users\jokafor\AppData\Roaming\Microsoft\Windows\Recent
          target E:\client_export_FINAL.xlsx (Ch. 16 owns these artifacts)
        - Recovered file: client_export_FINAL.xlsx, MFT entry 5830 (deleted),
          extracted via TSK `icat -o 1024000 mha-laptop.E01 5830-128-3`;
          SHA-256 7c9a4f1e2b8d5a0c3f6e9b2d5a8c1f4079e2b5d8a1c4f7e0b3d6a9c2f5e8b1d4
          (Exhibit 3c; exhibit hash list, Appendix C of this report)
        - Timeline: creation 2026-06-18T21:14:07Z ($FN, App. D; method per Ch. 21)
     Interpretation (supported):
        The artifacts are consistent with the proprietary dataset having been
        copied to the removable device E: on 2026-06-18, in the week before the
        custodian's departure. The recovery location (unallocated/deleted MFT
        entry) indicates the file was deleted prior to imaging.
     Limitation:
        Establishes the device connection, the file's presence/recovery, and the
        recorded dates. Does NOT, by itself, establish which individual operated
        the device, or that the copying was unauthorized as a legal matter.

Filled finding — negative (MHA):

   Finding F-007: No evidence of anti-forensic wiping tools or timestamp tampering
     Exhibit/item ...... Item MHA-2026-001 (mha-laptop.E01)
     Observation (fact):
        A search for common anti-forensic utilities and for timestamp manipulation
        returned no indicators.
     Supporting artifacts (reproducible):
        - No CCleaner / BleachBit / SDelete execution in AmCache.hve, Prefetch
          (C:\Windows\Prefetch\*.pf), or registry Uninstall keys.
        - $STANDARD_INFORMATION vs $FILE_NAME timestamp comparison on the files in
          F-003 showed no backdating/timestomping (method per Ch. 21).
        - No evidence of secure-deletion patterns over the relevant clusters.
     Interpretation (supported):
        The absence of anti-forensic tooling and of timestamp anomalies is
        consistent with the file-system metadata in F-003 reflecting genuine
        events. (Theme: the absence of a trace is itself a trace.)
     Limitation:
        Absence of detected anti-forensic activity does not prove none occurred by
        a method that leaves no artifact; it establishes only that none was found.

Ethics Note. Documenting negative findings is not optional padding — it is how you discharge your duty to report exculpatory evidence as rigorously as inculpatory evidence, and how you pre-empt the cross-examination "did you even check for X?" An examiner who reports only the half that helps the retaining side is an advocate, and a court will eventually treat them as one. In the courtroom anchor case, the same discipline that can support a charge is what protects an innocent person from a wrongful one (Ch. 28).

§7 Conclusions

What the findings, taken together, establish — supported, proportionate, qualified, never speculative. State what the evidence shows and not one inch more. A legal verdict ("the defendant stole the data") is the trier of fact's, not yours.

   7. CONCLUSIONS
   Based on the findings above, [the supported conclusion(s), proportionate to the
   evidence and qualified where the evidence permits more than one reading]. Where
   the evidence is insufficient to reach a conclusion on a question, that is stated.

Filled excerpt (MHA):

   7. CONCLUSIONS
   The file-system metadata, removable-media artifacts, and timeline (Findings
   F-003 through F-006) are consistent with copying of the MHA patient-analytics
   dataset and related source code to a removable USB device on 2026-06-18, prior
   to the custodian's departure. No evidence of malware, remote access, or an
   automated synchronization process that would account for the files' presence
   was identified (Finding F-005, a negative finding). The forensic evidence does
   not, by itself, identify the individual who operated the device.

§8 Limitations and assumptions

What your examination could NOT determine and what your conclusions rest on. This reads as strength, not weakness; an examiner candid about limits is harder to impeach than one feigning certainty.

   8. LIMITATIONS AND ASSUMPTIONS
   - This examination was limited to [the provided image / items in scope].
   - The evidence establishes [what], but does NOT establish [who operated the
     device / intent / events off-image].
   - A matching hash proves integrity, not authorship, origin, or intent.
   - [Encryption / damaged regions / TRIM / missing logs] limited [____].
   - Conclusions assume [____].

§9 Examiner qualifications

Establishes that you are competent to give the opinions in the report. A short statement here; the full CV is an attached exhibit. In U.S. federal civil litigation this expands into the FRCP 26(a)(2)(B) disclosures (F.7).

   9. EXAMINER QUALIFICATIONS
   Name / title ................. [____]
   Education .................... [degrees, field, institution]
   Certifications .............. [EnCE, GCFA, GCFE, GNFA, CCE, CFCE, CHFI — see
                                  Appendix I for what each attests]
   Experience .................. [years; nature of casework; # examinations]
   Relevant training ........... [courses, vendor/tool certifications]
   Prior testimony ............. [see Exhibit — testimony list]
   Publications ................ [see Exhibit — publications list]
   Full CV ..................... [attached as Exhibit ____]

§10 Appendices and exhibits to the report

The proof the skeptical reader (the opposing expert) lives in. Body asserts; appendices prove.

   10. APPENDICES / EXHIBITS
   A. Chain-of-custody record for each item (F.5)
   B. Acquisition logs (tool .info/.log; verification output)
   C. Exhibit hash list (mechanically generated — F.7)
   D. Timeline / supporting tables
   E. Raw tool output / screenshots (referenced exhibits)
   F. Glossary of technical terms (cross-ref Appendix Glossary)
   G. Examiner curriculum vitae; testimony and publication lists

Certification and signature block

Closes the report with the examiner's attestation. Use the declaration language when the report is sworn (a declaration under 28 U.S.C. §1746 needs no notary; an affidavit is sworn before a notary).

   CERTIFICATION
   I certify that the statements in this report are true and accurate to the best
   of my knowledge and belief; that the examination was conducted in accordance
   with accepted forensic practice and applicable lab procedures; and that the
   opinions expressed are my own, based on the facts and data described herein.

   [If sworn — declaration:]
   I declare under penalty of perjury under the laws of the United States of
   America that the foregoing is true and correct.   (28 U.S.C. § 1746)

   ____________________________            Date: ______________
   [Examiner name, title, certifications]

The complete report skeleton (copy this)

   FORENSIC EXAMINATION REPORT — [CASE-NO]            v[N.N] [DRAFT/FINAL]
   0.  Cover page (case, parties, examiner, version/status, confidentiality)
   1.  Administrative / case information
   2.  Executive summary                      (written last; plain language)
   3.  Scope and authorization                (authority; in/out of scope)
   4.  Evidence inventory                      (every item + acquisition hashes)
   5.  Tools and methodology                   (5.1 version block; 5.2 process;
                                                5.3 validation & standards)
   6.  Findings F-001..F-NNN                   (4-part each; INCLUDE negatives)
   7.  Conclusions                             (supported; proportionate)
   8.  Limitations and assumptions
   9.  Examiner qualifications                 (full CV as exhibit)
   10. Appendices / exhibits                    (CoC, hashes, logs, glossary, CV)
   Certification & signature                   (declaration if sworn)

F.7 Companion templates and checklists

F.7.1 Exhibit hash list (generate it mechanically)

Build the report's exhibit hash appendix from the exhibits themselves so it can never disagree with the findings that cite it. Hash every file you report on; paste the output as Appendix C of the report.

# Linux/macOS — hash every exhibit, both algorithms, recursively
hashdeep -c md5,sha256 -r /cases/2026-0207/exhibits/ > exhibit-hash-list.txt

# or, per-file, with sha256sum (append to the same list)
sha256sum /cases/2026-0207/exhibits/* >> exhibit-hash-list.txt

# Windows equivalent
Get-ChildItem -Recurse 'D:\cases\2026-0207\exhibits' -File |
    Get-FileHash -Algorithm SHA256 |
    Select-Object Hash, Path | Format-Table -AutoSize

   EXHIBIT HASH LIST — case 2026-0207 (Appendix C to the report)   [generated YYYY-MM-DD]
   ┌───────────┬──────────────────────────────┬──────────────────────────────────────┐
   │ Exhibit   │ File                         │ SHA-256                                │
   ├───────────┼──────────────────────────────┼──────────────────────────────────────┤
   │ 3c        │ client_export_FINAL.xlsx     │ 7c9a4f1e…b1d4                          │
   │ ...       │ ...                          │ ...                                    │
   └───────────┴──────────────────────────────┴──────────────────────────────────────┘
   (full 64-hex values in the generated text file; abbreviations here for the body)

F.7.2 FRCP 26(a)(2)(B) expert-report addendum

When you are a retained testifying expert in U.S. federal civil litigation, the report-of-examination expands to meet Federal Rule of Civil Procedure 26(a)(2)(B). Miss an opinion here and you may be barred from offering it at trial. Add these to §6/§9.

   FRCP 26(a)(2)(B) DISCLOSURES — checklist for the expert report
   [ ] (i)   A complete statement of ALL opinions to be expressed, and the
             basis and reasons for each.
   [ ] (ii)  The facts or data considered in forming the opinions.
   [ ] (iii) Any exhibits used to summarize or support the opinions.
   [ ] (iv)  The witness's qualifications, INCLUDING all publications authored
             in the previous 10 years.
   [ ] (v)   A list of all other cases in which the witness testified as an
             expert (trial or deposition) in the previous 4 years.
   [ ] (vi)  A statement of the compensation paid for the study and testimony.

Legal Note. Other report types carry their own form. A declaration is signed under penalty of perjury (28 U.S.C. §1746, no notary); an affidavit is sworn before a notary; both are shorter and more pointed than a full report but every word is sworn. An incident-response report (Ch. 26) optimizes for timely decisions but should be written as if it will become evidence. A recovery report (the 💾 deliverable for a client/insurer) drops chain of custody and culpability opinions but keeps the same honesty about what was and was not recoverable. The framework is owned by Chapter 25 and Chapter 26.

F.7.3 Pre-release review checklist (full version)

Chapter 26 carries an abbreviated form of this checklist and points here for the complete one. No report should leave a professional lab on one person's judgment; run technical and editorial review before release.

   PRE-RELEASE REVIEW CHECKLIST
   ─────────────────────────────────────────────────────────────────────────
   TECHNICAL REVIEW (a second qualified examiner verifies SUBSTANCE)
   [ ] Acquisition hash identical across inventory, methodology, findings, CoC
   [ ] Container hash vs. acquisition hash correctly distinguished/labeled
   [ ] Every finding cites its exhibit (path / offset / MFT-inode / hash / time)
   [ ] Every conclusion is supported by cited findings (no unsupported rung)
   [ ] Facts, inferences, and opinions kept on distinct, labeled rungs
   [ ] Account is NOT conflated with the person (operator not over-claimed)
   [ ] Negative findings documented (anti-forensics, malware, alternatives)
   [ ] All tools listed WITH exact versions; validation noted
   [ ] Methodology is reproducible by an independent examiner
   [ ] Key findings independently re-examined on the image (gold standard)
   [ ] Limitations honest and complete; "insufficient to conclude" where true
   [ ] Hash-set identification used for sensitive material (no needless viewing)

   EDITORIAL / COMMUNICATION REVIEW (clarity for non-experts)
   [ ] Executive summary stands alone in plain language (incl. bad news)
   [ ] No jargon undefined on first use (or pushed to glossary)
   [ ] Neutral, non-pejorative language (no "maliciously", "obviously")
   [ ] No speculation; no legal verdicts (guilt/innocence/liability)
   [ ] All sections present and numbered; all exhibits referenced
   [ ] Dates ISO 8601 with timezone stated everywhere (UTC preferred)
   [ ] Version / draft status labeled; distribution list correct
   [ ] No placeholders ([____] / [BRACKETS]) left in the released document
   [ ] CV / qualifications attached; signature/certification block complete
   ─────────────────────────────────────────────────────────────────────────
   Technical reviewer: __________  Date: ______   Editorial reviewer: __________  Date: ______

Tool Tip — language self-review. Before any draft reaches a reviewer, scan it for words that mark a slide from fact into speculation or advocacy — obviously, clearly, must have, would have, intended, knew, the suspect/defendant/user [verb]. Chapter 26 gives a small Python helper for this first pass; the reusable version lives in Appendix B. The script is not the work — your judgment is — but mechanizing the easy catches frees your attention for whether each conclusion is truly supported.

F.7.4 Evidence disposition / return record

When a matter closes, the evidence's life must end as documented as it began — returned, retained, or destroyed per court order or policy. This is the final custody entry.

   EVIDENCE DISPOSITION RECORD
   Case / matter ........ [CASE-NO]      Item ........ [ITEM-NO]
   Authority for disposition .. [court order #/date | policy | client instruction]
   Disposition .......... [ ] returned to [____]  [ ] retained until [____]
                          [ ] destroyed (method: [wipe/shred]; per [standard])
   Working images/copies disposition .. [retained per litigation hold / wiped]
   Performed by ......... [name]   Witnessed by ... [name]
   Date/time ............ [YYYY-MM-DDThh:mmZ]   Signatures ... R:__  W:__

Limitation. Do not destroy or wipe anything while a litigation hold or retention obligation is in force — spoliation of evidence carries severe sanctions. Confirm the authority for disposition in writing before acting, and log it as the last line of the chain of custody.

F.8 Quick field reference and common mistakes

Retention. Keep case files, custody logs, acquisition logs, and reports per your lab's retention schedule and any litigation hold — often years after a matter closes, because you may be recalled to testify long after memory fades. What is written stands; what is not written cannot be defended.

Related chapters and appendices

• Chapter 5 — The Forensic Process: why the original is sacred, hashing, and the chain of custody as concept.
• Chapter 14 — Forensic Acquisition: imaging, write-blocking, seals/bags/storage, and the custody log in practice.
• Chapter 16 — Windows Forensics: the registry/LNK/Prefetch artifacts cited in the example findings.
• Chapter 21 — Timeline Analysis: MACB timestamps and $STANDARD_INFORMATION` vs. `$FILE_NAME (timestomping detection).
• Chapter 25 — The Legal Framework: authority, warrants, consent, FRCP/FRE.
• Chapter 26 — The Forensic Report: the craft behind every section of the report template above.
• Chapter 27 — Expert Testimony: defending, under oath, the report you wrote with these templates.
• Chapter 28 — Ethics: exculpatory duty, mandatory reporting, and examiner well-being.
• Chapter 38 — The Capstone Investigation: assembles the MHA case file these documents build.
• Appendix B — Python Forensics Toolkit: hashing and language-review helpers.
• Appendix C — Tool Reference · Appendix D — Forensic Artifact Locations · Appendix E — Legal Frameworks Reference · Appendix H — Command-Line Reference · Appendix I — Certification Roadmap · Glossary.