Order of Volatility and Acquisition Choices

The Principle

Order of volatility means collecting the most temporary evidence first because it disappears fastest. CPU cache and registers survive microseconds; RAM is gone at power-off; disk files persist for years; archived backups last longest. The investigator prioritizes what is most likely to vanish, while still weighing authorization, safety, and business impact. This concept is codified in RFC 3227 (Guidelines for Evidence Collection and Archiving), a frequent Security+ reference.

Volatility Ranking (most to least)

SY0-701 questions rarely demand tool syntax. They test whether you grasp that memory, running processes, and active connections must be captured before powering off or reimaging.

Acquisition Choices

PBQ-Style Scenario

A server is powered on. EDR flags a suspicious process; firewall logs show active outbound connections. Legal has approved collection. The system is not safety-critical.

1. Photograph / record visible state and basic system details.
2. Capture volatile data: memory, processes, logged-in users, network connections.
3. Export relevant logs (endpoint, identity, firewall, application).
4. Acquire a forensic disk image or platform snapshot.
5. Hash and securely store all collected evidence.
6. Analyze only verified copies.

If that same server controlled life-safety or industrial equipment, the decision could change. Safety and operational continuity may override ideal evidence order, which is exactly why incident response is a joint business-and-technical decision rather than a pure forensics call.

Live Versus Dead-Box

Live acquisition collects from a running system: ideal for encryption keys held in RAM, injected processes, and active connections, but every action alters the machine. Dead-box acquisition powers down (or pulls the media) and images offline: it protects disk evidence but throws away all volatile state. The right choice flows from the investigative question. If you need volatile data, capture it live first. If a system is already off, do not casually power it on to look around — booting it changes timestamps, mounts the file system, and can overwrite slack space.

Cloud and Mobile Notes

In cloud environments you rarely image a host directly; you take an EBS/volume snapshot or rely on provider audit logs (such as AWS CloudTrail or Azure Activity Log). Cloud acquisition raises two SY0-701 themes: the data may reside in another country, triggering data sovereignty and jurisdiction questions, and you may need a right-to-audit clause or provider cooperation to obtain it. For phones, place the device in a Faraday bag before acquisition; this blocks cellular, Wi-Fi, and Bluetooth so an attacker cannot trigger a remote wipe of the evidence while it is in your custody.

Why the Order Is Not Optional

A frequent misconception is that order of volatility is merely a best practice you can skip when busy. On the exam it is treated as a defensibility requirement: if you image the disk first and the suspect process exits, you have permanently lost the memory evidence and the active connections, and no later step can recover them. Conversely, capturing volatile data costs only minutes and rarely harms the disk image you take afterward. So the default for any powered-on, authorized, non-safety-critical system is: volatile first, persistent second.

Deviating from that order is allowed, but the report must explain why — for example, a hospital monitor that cannot be paused for memory capture without patient risk. Documenting the deviation and its justification is what keeps the evidence usable.

Tooling and Validation

Whatever method you choose, record the tool name, exact version, command line, operator, and timestamp, and hash the output immediately. Validation means demonstrating the tool produces reliable results — for court-grade work, examiners favor tools with documented testing (for example, NIST's Computer Forensics Tool Testing program). For Security+ you do not need to memorize product names; you need to recognize that an undocumented, unvalidated, ad-hoc collection is far weaker than a documented one using a known-good tool.

Common Traps

• Pulling the plug before considering memory and active connections.
• Running many unapproved tools on the original system without logging them.
• Imaging the disk but forgetting the cloud logs where the activity actually occurred.
• Failing to record tool versions and timestamps.
• Assuming acquisition is perfect and never documenting limitations.
• Powering on a seized laptop without a forensic plan.