Glossary
Order of Volatility
The principle of collecting digital evidence from the most short-lived source to the most persistent, from CPU state and RAM down to archived media.
The order of volatility is the sequence in which evidence should be collected, starting with data that disappears fastest. It is formalised in RFC 3227, "Guidelines for Evidence Collection and Archiving", and remains the backbone of any incident response plan. The idea is simple: every minute you wait and every command you run destroys some state, so capture the fragile material before the durable material.
On a Linux host the practical order is roughly: CPU registers and cache (rarely collectable), physical memory, network connections and routing state, running processes and their /proc entries, logged-in users and open files, temporary filesystems such as /tmp, /dev/shm and /run, then disk contents, remote logs, and finally backups and archival media.
RAM > network state > processes > /proc, tmpfs > disk > remote logs > backups
The principle is a guide, not a rigid script. Collecting memory with a tool that barely touches the system may be worth doing before a quick network capture, and on a cloud VM a volume snapshot can be taken in parallel. What matters is that you consciously decide, document the order you used and the reasons, and avoid actions such as rebooting or running heavy scans that wipe volatile evidence. See acquiring Linux evidence and live response through /proc.