1. Foundations
Read this first. It sets out the purpose of the work, the legal footing, the four activities that must be kept apart, the labels every statement in your notes and report must carry, and the ordered lifecycle the rest of the guide follows.
In this chapter
- Introduction to digital forensics
Four activities, kept apart
Examiners talk about four distinct activities. Keeping them separate stops you from analysing the original evidence, or from acquiring before the scene is preserved.
- Preservation. Stopping evidence from being changed, lost or destroyed. Securing the scene, isolating devices from networks, deciding what to leave powered on.
- Acquisition. Making a complete, verified copy of the evidence: a memory capture, a physical image of a drive, an export from a server or cloud platform.
- Analysis. Examining verified copies for what happened: which files existed, what was done with them, and when. Analysis never happens on the original.
- Documentation. Recording every action, every person and every hand-over, from the moment you arrive to the moment the findings are presented. This runs through all three of the others.
Each section below is labelled with the activity it belongs to.
The language of findings
A report that blurs what was seen with what was inferred will not survive cross-examination. From the first note to the final report, label each statement as one of the following:
- Observed fact. Something you saw, measured or read directly and could show to another person: a screen photograph, a hash value, a partition table entry, a timestamp in an intact metadata record.
- Tool-reported information. What a tool says about the evidence: a parser's file listing, a carver's output, an imager's hash, a decoder's error position. It is an observation about the tool's output, not about the evidence, until the examiner has checked it against the underlying bytes or a second tool. Tools mis-parse damaged structures, assume contiguity and silently tolerate errors; a report that repeats a tool's output as fact has not examined anything.
- Examiner interpretation. What you understand an observed fact or a tool report to mean, based on documented knowledge of how the system behaves. "The USB device key records a first connection on that date" is fact; "the device was first connected to this machine on that date" is interpretation, and depends on the clock being right and the key being intact.
- Inference or investigative hypothesis. A proposed explanation you are testing, not a finding. Hypotheses belong in your notes and shape what you look for; they appear in a report only as hypotheses, with what supported and what contradicted them.
- Recovered evidence. Data obtained from the evidence with no examiner construction: a file read from an intact filesystem, a deleted file whose allocation record is intact, a record parsed from a log.
- Reconstructed or derived artefact. Something the examiner assembled or computed: a file carved from unallocated space, fragments joined by hand, a timeline built from several sources, a decrypted volume. Derived artefacts are always reported as such, with the method and the inputs.
- Conclusion with a stated confidence. An answer to an investigative question, graded on the scale in section 23 (confirmed, strongly supported, probable, possible) and never stronger than the weakest link in the chain of evidence that supports it.
Never present a reconstructed artefact as equivalent to an untouched original. The two look identical on screen. They are not the same evidence.
The lifecycle
The whole method reduces to one ordered sequence, and the order is the point: preserve, acquire, verify, examine, recover, correlate, validate, report. Preservation before acquisition, because an unpreserved scene cannot be acquired faithfully. Verification before examination, because an unverified copy proves nothing. Recovery and correlation before validation, because a reconstruction is a hypothesis until it is tested. Validation before reporting, because the report states confidence, and confidence is what validation produces.
The chapters follow that sequence. The scene and Identifying and prioritising evidence preserve; Volatile evidence, Storage acquisition and integrity, Custody and contingencies and Beyond the workstation acquire and verify; Encryption, the Windows, Linux and macOS chapters, Hidden data and Reconstruction and recovery examine and recover; Analysis and correlation correlates; Validation validates; Confidence, reporting and defensibility reports; and Practice condenses all of it into checklists.
Two further principles run through every chapter. Use validated tools, meaning tools whose behaviour on the kind of input you are giving them you have tested and recorded, and for every significant action record the tool name, version, configuration, command, timestamps, the operator, and any error or warning encountered. Nothing in this guide works without that record.
1. Documentation, preservation
Introduction to digital forensics
Purpose
Digital forensics is the disciplined recovery and examination of data from computers, phones, storage and online services so that it can be relied on to establish facts. The facts usually concern who did what, when, and with which data: was a file copied to removable media, was a message sent, did a program run, was a volume encrypted after a particular date, and can each of those be shown?
The output is not a hunch. It is a set of findings, each traceable back to a specific artefact at a specific location in a specific image, that a court, a tribunal, a regulator or a board can rely on and that another examiner could reproduce.
Why evidence integrity and legal compliance matter
Evidence is only useful if it can be shown to be complete, unaltered and lawfully obtained. Lose any one of those and the other side does not need to prove you are wrong, only that you might be.
- Integrity. If a file's timestamp changes because someone opened it to "have a look", you can no longer say when it was last accessed. A single careless action can poison a whole device as evidence.
- Repeatability. Another examiner, given your notes and your image, must be able to reach the same result. That is what makes a finding evidence rather than an opinion.
- Authority. Searching a device or an account without the right to do so can be a criminal offence, a breach of data protection law and grounds for the evidence to be excluded. In the UK the Computer Misuse Act, UK GDPR, the Police and Criminal Evidence Act and employment law all bear on what may be inspected and by whom. Get the authority in writing before you touch anything, and stay within its scope.
The four principles from the UK's long-standing good practice guide for digital evidence (originally published by ACPO, the Association of Chief Police Officers) remain the best summary: no action should change data that may later be relied on; anyone who must access original data must be competent and able to explain the relevance and implications of their actions; there must be an audit trail a third party could follow to the same result; and the person in charge of the investigation is responsible for making sure all of this happens. ISO/IEC 27037 covers the same ground internationally, and in England and Wales the Forensic Science Regulator's Code of Practice sets the standard that court-facing digital forensic work is measured against.
Example. An IT manager, asked to "check" a departing employee's laptop, logs in and browses the Downloads folder. Windows updates access times, the browser writes its own history, and a sync client uploads a batch of changes. Nothing has been deleted, but the state of the machine on the day the employee left can no longer be reconstructed with confidence. The right first move was to leave it alone and hand it to someone trained to preserve and image it.