Digital evidence: the story and its limits

A log says a file was accessed at 10:03. Before building a story around it, ask which clock produced that time, what “accessed” means in that system, and whether the record is complete.

Provenance: Information about the origin and handling of an item.

Preserve context with the item

A useful evidence record includes source, collection time and method, collector, scope, and handling history. Preserve original material appropriately and work from controlled copies when suitable. Access should be limited to the people who need it.

Volatile data can disappear or change quickly. Collection choices depend on urgency, authority, technical context, and applicable procedures. Improvised changes may alter what you are trying to understand.

A hash answers a narrow question

A cryptographic hash can help compare whether bytes match a recorded value. It does not prove that those bytes were truthful when created, that the source was trustworthy, or that the collector had authority. Integrity and authenticity require surrounding evidence and process.

A handling record supports accountability for transfers and changes. Avoid making universal legal claims about admissibility: requirements depend on jurisdiction and context, and qualified review may be necessary.

Build timelines with uncertainty visible

Record time zones, clock offsets, timestamp meaning, and gaps. A file modification time and an application request time describe different events. Correlate independent sources rather than assuming one record tells the whole story.

Separate observation from interpretation: “the log contains this event” is different from “this person performed the action.” Shared accounts, automated tasks, missing telemetry, and compromised identities can change attribution. State confidence and alternative explanations.

EXPLORE THE CONCEPT

What can you responsibly conclude?

Consider three pieces of fictional evidence.

Two copies have matching recorded hashes

Their bytes match for that comparison. This does not establish that the original content was true.

A single account name appears in a log

It associates the event with an account in that record. It does not alone identify the human responsible.

Two clocks disagree by five minutes

Account for the offset and timestamp semantics before ordering events. Do not silently force a narrative.

A simplified learning model. It connects to no systems and uses no real data.

Read three fictional records carefully

The Cedar community centre is investigating a disputed booking cancellation. These invented records illustrate reasoning, not a real collection procedure. All displayed times claim to be UTC, but the meaning and reliability of each clock still need checking.

Reading the displayed times literally suggests the session preceded the cancellation. However, an independent clock check indicates that the application clock was two minutes fast at the relevant time, with about five seconds of uncertainty. The identity clock was within five seconds of UTC. The application event therefore falls around 10:01:00, before the newly issued session. Preserve the original timestamp and record the adjustment separately so another reviewer can inspect the reasoning.

PredictDoes the corrected order prove that clerk-7 cancelled a booking without a session?

No. An earlier session might have existed; the request might have failed; or the available records might be incomplete. The application record says “submitted,” not “successfully committed.” The collector’s arrival time does not resolve those questions.

Separate observation, interpretation, and next evidence

Write three short statements. Observation: the application recorded a request associated with clerk-7. Interpretation: it may explain the disputed cancellation, but completion and human attribution remain unverified. Next evidence: an authorized review of the booking’s change history and relevant session records could test those claims. Asking for evidence that distinguishes alternatives is more useful than collecting every available record without a question.

A screenshot of a cancellation message can show what was displayed, while a database history may describe the committed change. Neither automatically replaces the other. A screenshot may omit context; a database record may lack the user’s view or reflect later edits. Preserve each item’s source and limits rather than merging them into one stronger claim than either supports.

Decide what to preserve and why

Suppose staff can export a relevant application report, but restarting the service would discard short-lived diagnostic state. The incident lead must balance the value of that state, disruption to users, authority to collect it, and the time required. NIST SP 800-86 treats forensics as part of an organizational process, not an instruction to preserve everything at any cost. A proportionate decision may protect a relevant source first, accept an explicit evidence gap to restore a critical service, or involve a specialist. Record the choice and its reason.

A useful evidence register has an item identifier, source and scope, collection time and method, collector, access restrictions, integrity-check details, and subsequent handling. Store analytical notes as notes; do not silently edit the source to correct spelling or timestamps. Modern cryptographic hashes strongly support an integrity comparison when correctly used, but a matching digest cannot repair an untrustworthy source or prove that an event happened as described.

Finish with a claim that a reader can challenge: “The available application record associates clerk-7 with a cancellation request around 10:01 UTC; successful completion and the person responsible remain unconfirmed.” That precise limitation points to useful work. It is more valuable than confident attribution unsupported by the records.

Turn the idea into a decision

Preserve the evidence and the reasons behind your interpretation. A clear limitation strengthens a report.