---
{
  "title": "Evidence acquisition",
  "summary": "Collect what is needed while recording unavoidable changes and constraints.",
  "topic": "forensics",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    1
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Integrating Forensic Techniques into Incident Response",
      "url": "https://csrc.nist.gov/pubs/sp/800/86/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

Acquisition is the controlled collection of evidence. Choose a method based on the question, source, system state, authorization, and volatility. Physical images, logical exports, memory captures, and cloud exports preserve different kinds of information. Document tools, versions, times, source identifiers, errors, and integrity values. Collection can affect a live system, so record those effects instead of claiming every method is perfectly nonintrusive.

## In practice

A responder captures approved live records before a short retention period ends, then stores an immutable working copy with an acquisition record.

## A common misunderstanding

A screenshot is not equivalent to a complete structured export. It may omit fields, records, and provenance.

## Check your understanding

What determines the right collection method?

**Think it through:** The required evidence, system constraints, available authority, and the tradeoff between preservation and operational impact.


## Define the question, authority, and collection boundary

Acquisition turns available information into material that can be examined and referenced. Establish the authorized scope, relevant systems, time period, and collection method. Collecting every accessible account or device may create unnecessary privacy and operational impact while still missing the source that answers the actual question. A proportionate plan is more useful than indiscriminate accumulation.

Record how the evidence was obtained, who handled it, source identifiers, tool versions, errors, and relevant integrity checks. Some collection necessarily changes state, especially on live systems. The goal is to minimize avoidable change and explain unavoidable effects, not claim that every method leaves the environment perfectly untouched.

## A fictional cloud-log export

An academy needs identity events for a defined incident window. The collector records the tenant, query scope, time basis, export method, and whether pagination or limits could omit records. The original export is protected, while analysis uses a working copy. A screenshot of the first page would not establish that the full relevant population was collected.

Cloud exports can have delays, retention constraints, and permission-dependent visibility. Document those conditions and consider whether another source is needed. Hashing an exported file helps track its later integrity but does not prove that the service returned every relevant event or that the query was correct.

## Write a collection record

For a fictional application log, specify the question, authorized period, source identity, export steps, storage location, and verification method. Add one possible omission and how you would check it. Then explain who can access the raw evidence. This connects technical collection with reproducibility and responsible handling rather than treating a downloaded file as self-explanatory proof.

## Keep exploring

- [[order-of-volatility]]
- [[disk-imaging]]
- [[cloud-audit-logs]]