What is the order of volatility?
The order of volatility is the sequence in which investigators collect digital evidence: the most volatile, shortest-lived data first, and the most durable last. Some evidence disappears the instant a computer loses power, some changes within seconds while the system keeps running, and some lasts for years. Collecting in the wrong order destroys evidence that can never be recovered. The best-known statement of the principle is RFC 3227, Guidelines for Evidence Collection and Archiving.
The order, from most to least volatile
RFC 3227 lists these tiers for a typical system:
- CPU registers and cache: change constantly and are rarely captured in practice.
- Routing table, ARP cache, process table, kernel statistics and memory (RAM): lost at power-off and changing every second.
- Temporary file systems: such as temp directories held in memory or cleared at reboot.
- Disk: survives power-off, but continued use overwrites deleted data and changes timestamps.
- Remote logging and monitoring data: logs on a SIEM or syslog server, subject to retention limits.
- Physical configuration and network topology.
- Archival media: backups and archives, built to last.
Other references arrange the middle tiers slightly differently, for example listing network connections and running processes as separate steps after memory. Network state and the process list live in memory, so a full memory capture preserves much of them. The principle stays the same: collect what you will lose soonest, first.
Example: responding to a running, compromised server
An EDR alert shows a web server running a malicious process that has never written a file to disk. The responder:
- Isolates the server from the network through the EDR console instead of powering it off, so the attacker loses access but RAM is preserved.
- Captures a full memory dump with a trusted tool run from external media, writing the output to an evidence drive, never to the server's own disk.
- Records live network and process state, for example with
netstat -anoandtasklist /von Windows orss -tunapandps auxwwon Linux, saving each output and noting the time. - Images the disk, or takes a snapshot if the server is a virtual machine.
- Exports the relevant logs from the SIEM and secures the backups.
Every item is hashed when collected and logged on a chain of custody form. Each command run on a live system changes it slightly, so responders keep live commands to a minimum and record every one.
Common mistakes
- Pulling the power or rebooting first, which wipes RAM, including fileless malware, encryption keys and live connections.
- Imaging the disk before capturing memory because disk imaging is more familiar.
- Saving tool output to the suspect system's own disk, which can overwrite deleted files in unallocated space.
- Waiting too long to export logs, so the oldest entries roll off under normal retention.
There are exceptions. If ransomware is actively encrypting data and isolation isn't possible, stopping the damage can outweigh preserving memory. The order of volatility guides collection; it doesn't override the need to contain an active threat.
Order of volatility vs. chain of custody
The two are often paired in questions, but they answer different things. The order of volatility decides what to collect first. Chain of custody documents who held each item after it was collected. Hashing proves an item hasn't changed, and a legal hold stops routine deletion when litigation is expected.
Order of volatility on the CompTIA Security+ exam
The order of volatility is tested in objective 4.7 on SY0-801, as part of the investigation phase of incident response, and in objective 4.8, which covers memory dumps, disk images and snapshots. A question that asks what to collect FIRST from a running system wants the most volatile item in the answer list, which is usually memory (RAM), or CPU registers and cache if they are listed. Disk images, logs and backups are the tempting wrong answers because they are familiar, but they will still be there after memory is gone. If a scenario mentions fileless malware, encryption keys in use or a system that is still running, capture memory before anything else.