The report looked official. It had pages, conclusions, and the comfortable weight of something that could be placed in an exhibit binder.
What it did not have was a documented device, a repeatable method, native evidence, search terms, tool information, or file hashes. The files it discussed had been printed instead of produced in their original format.
That is not a minor reporting problem. It is the difference between an opinion another examiner can test and a conclusion everyone else is expected to take on faith.
In brief: A defensible digital-forensic report should identify the evidence, question, methods, tools, relevant artifacts, results, limitations, and integrity checks. In this insurance matter, the prior report omitted those foundations and reduced native files to printouts, preventing meaningful review of their metadata and internal PDF objects.
This case study omits identifying details. It explains forensic reporting principles, not the admissibility or legal weight of evidence in any jurisdiction.
The assignment given to the computer shop
The opposing side had asked a small computer shop to examine a computer for versions of two disputed documents. The assignment also included determining whether digitally signed versions existed and whether “metadata scrubbers” were present.
Those can be legitimate forensic questions. They require more than opening File Explorer and printing whatever looks relevant.
A proper examination begins by defining:
- What device or data source was examined
- How the data was acquired
- Whether the acquisition preserved the source
- What files, locations, accounts, and time periods were in scope
- Which tools and versions were used
- What searches or filters were run
- What artifacts supported each conclusion
- What limitations remained
NIST describes digital forensics as the retrieval, storage, and analysis of electronic data and emphasizes methods that capture data reliably without altering it. NIST's Computer Forensic Tool Testing program exists because tool capabilities and reliability must be tested rather than assumed. NIST: Digital evidence
The report could not identify its own evidence
The report did not adequately document the device examined. It did not provide a forensic image identifier, acquisition method, hash, storage details, or chain-of-custody information.
That omission made the rest of the report unstable. If another examiner cannot tell what was analyzed, the work cannot be repeated against the same evidence.
Think of it as a recipe that says “cook the thing until it looks right” but never names the ingredients, temperature, pan, or time. You may get dinner. You do not get reproducibility.
The report also failed to explain its searches. It did not identify search terms, paths, file types, date filters, software, or validation steps used to locate the documents. A statement that files were “found” is not enough when the assignment concerns versions, origins, signatures, and possible metadata removal.
Printing the files discarded the evidence needed for review
The most damaging choice was also the simplest: the located files were printed rather than produced in native format.
A printed PDF can show words, lines, and images. It generally cannot preserve the complete internal structure that may include:
- Text and form fields
- Annotation objects
- Embedded images
- Certificate-based signature fields
- XMP metadata
- Native PDF date strings
- Object references and incremental updates
- Producer and creator indicators
Adobe notes that PDFs can carry document properties and deeper metadata about a file's history and characteristics. Adobe: Document properties and metadata Adobe also provides functions that sanitize hidden information and flatten layers or annotations, illustrating why a visually similar output may have a very different internal structure. Adobe: Sanitize PDFs
Once the computer shop handed over paper, the metadata was no longer available for independent analysis. A printout may be useful as a visual exhibit. It is a poor substitute for native digital evidence.
What reproducibility looks like in a forensic report
Reproducibility does not mean every examiner will phrase an opinion identically. It means a qualified examiner can work from the same evidence and documented method, observe the same underlying artifacts, and understand how the conclusion was reached.
A useful report should contain at least the following.
1. Evidence identification
Identify each device, image, file, email container, cloud export, or other source. Record serial numbers or other identifiers where appropriate, acquisition dates, custody, and cryptographic hashes.
NIST defines a hash value as a numerical string used to substantiate digital-evidence integrity or compare an item against a known value set. NIST: Hash value A hash is not decorative technical seasoning. It connects the evidence discussed in the report to the evidence another examiner receives.
2. The question presented
State the task clearly. “Look at the computer” is not a forensic question. “Determine whether native versions of these named documents exist and identify evidence bearing on their creation, modification, and signing history” is much closer.
3. Acquisition and preservation method
Explain whether the examiner created a forensic image, performed a targeted collection, reviewed a live system, or received exported files. Identify write protection, validation, exclusions, and any unavoidable changes to the source.
4. Tools and methods
List relevant tool names and versions, but do not stop there. Explain how they were used: search terms, parsers, filters, artifact locations, extraction steps, manual validation, and cross-checks.
5. Results tied to artifacts
For each important finding, identify where the supporting data was found. A conclusion should point back to a file, object, record, log, registry key, database row, email, or other examinable artifact.
6. Limitations and alternative explanations
Explain what the evidence cannot establish. Missing files may have been deleted, excluded, never synchronized, or stored elsewhere. A username may reflect an application profile rather than the human at the keyboard. Metadata may be genuine, changed, regenerated, or stripped.
An examiner who admits a limitation is not weakening the report. The examiner is showing where the guardrails are.
“Metadata scrubber” is not one precise category
The prior assignment asked whether the computer contained “metadata scrubbers.” That phrase can describe very different things:
- Privacy or cleanup utilities that delete activity traces
- Document-specific tools that remove metadata
- PDF sanitization functions
- Flattening or optimization workflows that combine formerly separate objects
- Printing or exporting to a new PDF, which can produce a derivative file with less internal history
Adobe documents both metadata sanitization and flattening as ordinary product functions. Flattening can make comments, markups, fields, or layers permanent and non-editable; sanitization can remove metadata and other hidden information. Adobe: Share a flattened PDF
Therefore, the absence of metadata does not prove that a malicious scrubber was used. It tells the examiner to investigate the workflow and source device. Words matter here. Calling every conversion a “scrubber” is as useful as calling every wrench an engine repair.
What the better examination found
When we examined the native PDFs, the internal objects supplied evidence the printed pages could not:
- Evidence Item 1 contained 14 dated instances of user activity, including text fields, line annotations, and highlights in July and September 2022, plus a January 2023 top-level creation date.
- Evidence Item 2 contained XML metadata centered on September 7, 2022, more than a year after its asserted date.
- Evidence Item 2 contained separate logo and signature image objects.
- Comparison indicated that the Item 2 signature image likely came from the signature in Item 1, was modified, and was placed into the second PDF.
Those findings did not identify the editor. They did show that the native files carried evidence inconsistent with the simple wet-sign-and-scan account.
The source computer remained important. With a forensically sound acquisition, an examiner might find alternate versions, source images, email attachments, browser and application artifacts, or cloud history that clarifies origin. “Might” is doing honest work in that sentence. No examiner should promise artifacts that have not been collected.
A report-review checklist for attorneys
Before relying on a digital-forensic report, ask:
- Does it identify every device and file examined?
- Does it explain acquisition and preservation?
- Are hashes provided for relevant evidence?
- Is the task or question clearly stated?
- Are tools, versions, searches, and methods documented?
- Can the findings be traced to specific artifacts?
- Were native files produced, not merely screenshots or printouts?
- Are limitations and alternative explanations addressed?
- Could another qualified examiner repeat the work?
- Does the report distinguish observation from inference and inference from opinion?
If the answer to several of these is no, the report may still contain useful leads. It is not yet a reliable forensic roadmap.
The lesson from this case
The expensive mistake was not choosing the wrong PDF tool. It was treating a computer search as a forensic examination without preserving the evidence or documenting the method.
Native evidence keeps the doors open. A printout closes most of them.
When documents may affect an insurance claim, contempt allegation, contract dispute, or other litigation, involve a qualified forensic examiner early enough to preserve the source data. Cyber Agents provides evidence review, digital-forensic analysis, and expert consultation for counsel on either side of a matter. Data does not take sides; neither should the examination. Learn about expert testimony and trial consulting, then contact Cyber Agents to discuss the evidence that may still be available.