Order of Volatility: The Collection Sequence That Preserves Evidence

Order of volatility is the rule that evidence should be collected most perishable first. Some data disappears in microseconds, some survives a reboot, some sits on tape for years. Collect in the wrong sequence and the volatile material is gone before you reach it, which is why this is one of the most reliably tested concepts in incident response.

The sequence

From most to least volatile:

CPU registers and cache change with every instruction. In practice they are captured as part of a memory image rather than separately.

Routing tables, ARP cache, process table, kernel statistics, and active network connections live in memory and change constantly. The ARP cache expires entries in minutes; network connections close.

System memory is the big one. RAM holds running processes, injected code, decrypted data, encryption keys, clipboard contents, unsaved documents, and network activity that never touched disk. It is lost entirely on power-off.

Temporary file systems — swap, page files, temp directories — survive somewhat longer but are overwritten during normal operation.

Disk storage persists across reboots. Deleted files often remain recoverable, and this is where the bulk of traditional forensic analysis happens.

Remote logging and monitoring data sits on other systems and is stable, though subject to retention limits — a good reason to centralize logs into a SIEM where they are out of the attacker's reach.

Physical configuration and network topology is documentation-level, and archived media such as backups and tape is the least volatile of all.

Why memory before disk

Memory is where the incident is actually visible. Fileless malware exists only in memory by design. Injected code shows in a process image and nowhere on disk. Encryption keys extracted from RAM may be the only way to read an encrypted volume afterward. Network connections in memory reveal command-and-control that ended before any log was written.

This overturns older guidance to pull the plug immediately. Powering off destroys everything above the disk line, and that is frequently where the answer lives. Current practice is to capture memory first on a running system, then decide about isolation and shutdown.

Isolation is the compromise: disconnect the network to stop the attacker while leaving the system powered so memory survives. Note that disconnecting is itself a change, and some malware reacts to losing connectivity — document the decision and the time.

Where an EDR agent is already deployed, some of this volatile picture has been recorded continuously and survives on the management console even after the host is powered down — process trees, network connections, and command lines. That telemetry supplements a memory image; it does not replace one, because the agent recorded what it was configured to record and nothing else.

Collection changes the scene

There is no way to capture memory from a live system without running something on it, which allocates memory and alters what you are collecting. Forensics accepts this and manages it: use the smallest possible tool, run it from external media, write the image to external storage rather than the local disk, and document exactly what was run, by whom, and when.

Disk acquisition uses a write blocker so the source is never modified, and analysis happens on a verified copy. Booting the subject from external media into a controlled environment is a common way to image a drive without starting the installed operating system — the same mechanism described under offline boot environments, used here deliberately rather than against you. Hash the image at acquisition and re-hash before each analysis session, so you can demonstrate the evidence did not change in your custody.

Chain of custody

Technically perfect collection is worthless if custody cannot be demonstrated. Record who collected each item, when, from where, and every transfer of possession afterward, with signatures at each handoff. Keep evidence in controlled storage with access logged.

Timestamps matter more than people expect. Record the system clock and its offset from a reliable reference at collection time, because correlating a workstation against logs from a dozen other sources depends on knowing how wrong each clock was.

When volatility is not the only priority

The order is a default, not an absolute. Life safety always outranks evidence. Legal preservation obligations, regulatory notification deadlines, and the business decision to restore service can all take precedence — and the lawful authority to collect must exist before you start. Document the reasoning whenever you deviate; a defensible investigation is one whose decisions are explained, not one that never departed from the textbook.

Exam angles

Be ready to place a list of sources in volatility order. Registers and cache first, then ARP and routing and process tables, then RAM, then temporary files, then disk, then remote logs, then archived media. Know that memory capture precedes disk imaging, that write blockers protect the source during acquisition, and that hashing plus chain of custody establishes integrity. When a scenario asks what to collect first from a running compromised host, the answer is volatile memory — not a disk image, and not a reboot.