Order of Volatility and Acquisition Choices

CompTIA Security+ SY0-701

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

Current Exam Facts and How Security+ Tests Judgment Domain Weighting and an 8-12 Week Study Plan Practice Questions, PBQs, and the Missed-Question Notebook

2 Domain 1: General Security Concepts (12%)

CIA and Non-Repudiation Control Types and Categories with Scenario Classification Security Principles: Least Privilege, Defense in Depth, Secure by Design, and Zero Trust Change Management and Business Impact

3 Domain 1: Identity, Trust, and Cryptography Basics

AAA and IAM Concepts Authentication Factors and MFA Traps Authorization Models: RBAC, ABAC, MAC, DAC, and Least Privilege Cryptography, Hashes, Signatures, PKI, and Certificate Decision Rules

4 Domain 2: Threat Actors, Vectors, and Social Engineering

Threat Actors and Motivations Attack Vectors and Attack Surface Social Engineering Types and Clues Supply Chain and Insider Threat Scenarios

5 Domain 2: Threats, Vulnerabilities, and Mitigations - Attacks

Malware Behaviors and Indicators Credential and Password Attacks Network and Wireless Attacks Application, API, and Cloud Attacks with Mitigation Mapping

6 Domain 2: Threats, Vulnerabilities, and Mitigations - Vulnerabilities

Vulnerability Types and Misconfiguration Vulnerability Scanning and Prioritization Secure Coding and Application Mitigations Remediation, Compensating Controls, and Risk-Based Decisions

7 Domain 3: Security Architecture - Secure Architecture Models

Architecture Models and Trust Boundaries Cloud Shared Responsibility and Service Models Zero Trust, SASE, and SSE Concepts Secure Design Review Scenarios

8 Domain 3: Security Architecture - Network Security Architecture

Segmentation, VLANs, DMZ, and Microsegmentation Firewalls, WAF, IDS, IPS, and Proxies VPN, Remote Access, and NAC Wireless Security and Enterprise Network Design

9 Domain 3 Part C: Data Protection and Resilience

Data Classification and Handling Encryption at Rest, in Transit, in Use, and Key Management DLP, Privacy, and the Data Lifecycle Backups, RTO, RPO, BCP, DR, and Resilience

10 Domain 4 Part A: Secure Operations for Hosts, Cloud, Mobile, and IoT

Endpoint and Server Hardening Cloud, Container, and Virtualization Operations Mobile, BYOD, and MDM Embedded, IoT, OT, and Physical Device Security

11 IAM Operations and Access Control

Provisioning, Deprovisioning, and Access Reviews PAM, JIT, JEA, and Service Accounts Federation, SSO, SAML, OIDC, and OAuth Account Attacks and IAM Monitoring

12 Logging, Monitoring, and Detection

Log Sources and Telemetry SIEM Correlation and Alert Triage SOAR, Playbooks, and Automation Detection Use Cases and False-Positive Handling

13 Incident Response

IR Phases and Roles Containment, Eradication, and Recovery Decisions Communication, Escalation, Legal, and Regulatory Considerations Post-Incident Lessons Learned and Metrics

14 Digital Forensics and Investigation

Evidence Handling and Chain of Custody Disk, Memory, Network, and Log Artifacts Order of Volatility and Acquisition Choices Forensic Reporting and Anti-Forensics Traps

15 Vulnerability, Patch, Asset, and Automation Operations

Asset Inventory and Data Classification in Ops Vulnerability Lifecycle and CVSS/Risk Priority Patch, Change, and Configuration Management Automation, Orchestration, SCAP, and Security Tooling

16 Governance, Policies, and Risk Management

Governance Documents: Policy, Standard, Procedure, and Baseline Risk Register and Risk Treatment Quantitative/Qualitative Risk and BIA Exceptions, Acceptance, Ownership, and Reporting

17 Third-Party Risk, Compliance, and Privacy

Vendor Risk Lifecycle and Agreements Due Diligence, Questionnaires, and Monitoring Privacy Concepts and Data Rights Compliance Reporting and Consequences

18 Audits, Penetration Testing, and Awareness

Internal and External Audits and Evidence Penetration Test Types and Rules of Engagement Security Awareness, Training, and Phishing Metrics Personnel and Physical Security Program Controls

19 Final Review and PBQ Labs

PBQ Workflow and Timing Ports, Protocols, and Acronyms High-Yield Tables Firewall, IAM, Log, and Risk PBQ Mini-Labs Final 7-Day Review Plan Mixed Exam Strategy and Missed-Question Remediation

Order of Volatility and Acquisition Choices

Key Takeaways Explain This Topic AI

Order of volatility says collect the most fleeting evidence first: CPU cache/registers, RAM, network state, then disk, then archives.

Live acquisition captures volatile state but changes the system; dead-box acquisition protects disk evidence but loses RAM and connections.

Acquisition choice depends on the investigative goal, system state, legal authorization, business impact, and safety.

Always document tools, versions, timestamps, hashes, and known limitations of every acquisition.

Safety-critical or industrial systems can override the ideal evidence order—business and technical owners decide jointly.

Last updated: June 2026

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)

• Rank Evidence Typical lifespan
• 1 CPU registers, cache Microseconds
• 2 Routing table, ARP cache, kernel stats, RAM Until power-off
• 3 Active network connections / running processes Seconds to minutes
• 4 Temporary files, swap/pagefile Until overwritten
• 5 Disk / SSD contents Years (until wiped)
• 6 Remote logging, monitoring data Per retention policy
• 7 Physical configuration, archival media Indefinite

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

• Method When useful Risk / limitation
• Memory capture Fileless malware, keys in RAM, live process state Running the tool itself changes RAM
• Live response Need active connections, logged-in users, processes Commands alter timestamps and state
• Disk image Need deleted files, persistence, file metadata Misses memory-only activity
• Log export Need identity, network, cloud, app timeline Logs may be incomplete or normalized
• Packet capture Need traffic content or protocol detail TLS encryption limits payload visibility
• Snapshot Cloud/virtual systems need fast preservation Consistency depends on platform timing
• 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.