An excellent forensic analysis can lose all its value if the report describing it is confused, incomplete or incomprehensible. The report is the final product of the work: it is what the judge, the lawyers, the other side and the company will read. It must let a non-technical reader understand what was found and a technical reader verify every step. Balancing these two needs is the real challenge.
Who it is for
A report has at least two audiences:
- those who decide, who need clear answers to the questions and to understand how solid they are;
- those who verify, meaning other technical experts, who must be able to repeat the operations and check the results.
The solution is a layered structure: a readable body with the conclusions highlighted, and detailed technical attachments for those who want to go deeper.
A proven structure
1. Introduction and engagement
Who gave the engagement, when and with which questions. The questions should be quoted verbatim, because the whole report must answer them.
2. Summary of conclusions
One page, at the start, answering each question in a few lines. Many readers will read only this part: it must be accurate and no stronger than the rest of the report justifies.
3. Material examined
A list of exhibits and sources, with description, identifiers, condition on receipt and chain of custody. For every copy, the hash value.
4. Method
How acquisitions and analyses were carried out, with which tools and which versions. It does not need to be a manual, but it needs enough detail for another expert to repeat the work.
5. Analysis and findings
The heart of the report, organised by question. For each one:
- what was searched for and where;
- what was found, with precise references to the attachments;
- how it should be interpreted.
6. Limits
What could not be verified and why: encrypted data, damaged media, unavailable logs, time elapsed. Many people leave this section out, yet it strengthens the report.
7. Conclusions
The answers to the questions, with reasons, and the degree of certainty of each.
8. Attachments
Extractions, full tables, timelines, screenshots, file lists with hashes, records.
Language
- Short sentences and explained terms: the first time a technical term appears, one line explains it. "The Prefetch file, a file Windows creates to start a program faster, shows that…".
- Facts separated from interpretation: "The registry shows a USB device connected at 10:42" is a fact. "The user copied the files to the device" is an interpretation that must be justified.
- Explicit degrees of certainty: expressions such as "it is proven", "it is consistent with", "it cannot be established" should be used consistently.
- No unnecessary adjectives: "an obvious manipulation" is less convincing than a precise description of what was changed.
- Times with time zones: every time with its time zone, or an opening note that applies to the whole document.
Tables, images and timelines
A well-made table is worth many pages of text. For example:
| Date and time (UTC+1) | Event | Source | Attachment |
|---|---|---|---|
| 14/02 10:42 | USB stick connected, serial number recorded | Registry | A3 |
| 14/02 10:44 | Customers folder opened | ShellBags | A4 |
| 14/02 10:51 | USB stick removed | Event log | A5 |
Screenshots and photos help, as long as they come with a caption explaining what they show and where they come from.
Mistakes to avoid
- Conclusions stronger than the data: this is the error the other side will exploit first.
- Unexplained jargon: decision-makers cannot assess what they do not understand.
- Attachments not linked to the text: every statement must point to a verifiable item.
- Omitting unfavourable findings: if they emerge, report them; their discovery by others destroys credibility.
- Boilerplate text: reports full of generic paragraphs, identical for every case, are spotted immediately.
Before delivery
Reread the report as if you were the other side's expert looking for weak points, and then as a reader with no IT background. If the first finds an unsupported statement, fix it. If the second does not understand a conclusion, rewrite it. Finally, check that every hash listed matches the files delivered.
In short
- The report must be readable by those who decide and verifiable by those who check.
- A clear structure starts from the questions and puts the summary of conclusions first.
- Facts and interpretations must be separated, with explicit degrees of certainty.
- The analysis's limits must be stated, and unfavourable findings must not be omitted.
- Every statement must point to a verifiable attachment.