Volatility and fragility

Digital evidence does not wait. Memory empties when power is lost, logs overwrite themselves, phones receive messages and remote wipe commands, and solid-state drives clean up deleted data on their own. Even the examiner changes a system the moment they touch it. This lesson explains why digital evidence is volatile and fragile, the order in which volatile data is usually preserved, and the decisions that follow. How devices are seized is covered in Module 3, and how copies are made in Module 4.

Volatile and fragile are not the same

• Volatile data disappears when a device loses power or a process ends: the contents of memory (RAM), running processes, open network connections, encryption keys held while a disk is unlocked.
• Fragile data survives a power cut but changes easily: files, logs and timestamps that are altered by normal use, by automatic maintenance or by careless handling.

Both lead to the same rule: decide early what could be lost, preserve it in a sensible order, and record what you did and why.

The order of volatility

RFC 3227, "Guidelines for Evidence Collection and Archiving", published in 2002, proposes collecting evidence from the most volatile to the least volatile. Its order is still the standard reference:

1. Registers and cache
2. Routing table, ARP cache, process table, kernel statistics and memory
3. Temporary file systems
4. Disk
5. Remote logging and monitoring data relevant to the system
6. Physical configuration and network topology
7. Archival media

In practice, registers and caches cannot be captured on their own; what examiners can preserve is the content of memory and the live state that the operating system reports, such as running processes and network connections. The principle is what matters: if two sources are at risk, start with the one that will vanish first.

What changes digital evidence

Timestamps deserve a special mention. Opening a file, browsing a folder or simply booting an operating system can update timestamps and system records. On Windows, for example, connecting a USB device to examine it creates new entries in the registry and setup logs. Data on the original device should be examined through verified copies, not by browsing it.

Every action leaves a trace

A principle attributed to the criminologist Edmond Locard says that every contact leaves a trace. It applies to examiners too. Running a memory capture tool loads that tool into the memory you are capturing; plugging in a storage device writes records about it; typing commands on a live system creates new processes. These changes cannot always be avoided. What makes them acceptable is that they are kept to a minimum, chosen deliberately, and documented so that anyone can tell the examiner's traces apart from the user's.

Power, encryption and connectivity

Three questions shape the first minutes with any device.

Is it on or off?

A device found switched off is normally left off: switching it on starts the operating system, which changes data. A device found running holds volatile data that may be valuable, and a decision is needed about whether to preserve it before power is removed.

Is the data encrypted?

Full-disk encryption, such as BitLocker on Windows, FileVault on macOS or LUKS on Linux, protects data at rest. While the system is running and unlocked, the data is readable and the keys may be in memory. Switching the system off can make the data unreadable without the password or recovery key. Recognizing encryption on a running system is therefore one of the most important early observations.

Is it connected?

Phones, laptops and cloud-synchronized folders keep changing while they are connected. A remote wipe, a new message or a synchronization can alter or destroy evidence. Isolating the device from mobile networks, Wi-Fi and Bluetooth, for example with airplane mode or a radio-frequency shielded bag, stops these changes, but each method has side effects that are covered in Module 3.

Volatility beyond the device

Some of the most valuable evidence never sits on the device in front of you.

• Network traffic exists only while it travels. Unless someone was already capturing it, what remains are records about it: firewall, proxy and DNS logs, flow records, and the connections listed on a running system.
• Logs on servers and online services are kept for a limited time. Retention periods vary from days to months and depend on the provider, the service plan and the organization's own settings.
• Shared and synchronized data can be changed from anywhere. A file deleted on one device may disappear from the cloud and from every other device linked to the account.

For these sources, the first step is often a request rather than a tool: ask the system owner or the service provider to preserve the relevant records before they expire, and record when and how that request was made. Organizations that plan ahead, by keeping logs centrally and for long enough, make later investigations far easier.

There is rarely a perfect choice

Volatility forces trade-offs. Capturing memory changes a little of the system but saves what would otherwise be lost; pulling the plug preserves the disk exactly but loses memory and may lock an encrypted volume. There is no single correct answer for every case. ISO/IEC 27037 asks for justifiability: the decision must be explainable as the best option in the circumstances, considering the goal of the investigation, the risks and the authorization. Writing down the reasons at the time is what turns a judgement call into a defensible one.

Exam focus: Know the difference between volatile and fragile data, the order of volatility from RFC 3227 (memory before disk, disk before remote logs and archival media), and why SSD TRIM and garbage collection, log rotation and remote wipe threaten evidence. Expect scenario questions on encrypted running systems, isolating phones from networks, and why examiners must minimize and document the changes they cause.