Scope the Incident and Preserve Useful Evidence
Determine what is affected, what may be related, what evidence is needed, and how to preserve it without collecting indiscriminately.
In this lesson, you will learn to:
- Develop a scoped investigation plan that identifies relevant assets, identities, time windows, evidence sources, limitations, and preservation needs.
Scope the Incident and Preserve Useful Evidence
This lesson gives learners an evidence-led method for expanding or narrowing incident scope while retaining traceability and respecting operational limits.
Scope with hypotheses and evidence pivots, not a single assumed story
Incident scope is the current, evidence-supported understanding of what was affected, how activity may have occurred, and what remains uncertain. It changes as new evidence arrives. Treat early scope as a hypothesis that must be tested, not as a final declaration based on the first compromised account or host.
Build a timeline around the initial signal. Identify associated accounts, devices, applications, networks, cloud resources, data stores, processes, and external services. Look for evidence before and after the detected event: authentication changes, unusual process execution, new persistence, network connections, file access, privilege changes, data transfer, deployment actions, and alert suppression. The exact sources depend on the environment and authorization.
Use pivots deliberately. An account event may lead to authenticator changes, mailbox rules, OAuth grants, VPN records, endpoint activity, cloud-control events, or a set of resources accessed through the same token. A malicious file may lead to its parent process, download source, child processes, persistence mechanisms, network destinations, and other hosts with the same behavior. Each pivot should answer a question, not simply expand the data volume.
State limitations. Missing logs, clock differences, retention gaps, unmanaged devices, encrypted traffic, or unavailable services constrain confidence. Recording what cannot be known is a strength because it tells decision makers which risks remain and what compensating actions may be appropriate.
Preserve evidence with traceability and a purpose
Evidence preservation protects the ability to understand, remediate, and communicate an incident. It can include logs, alerts, audit records, volatile memory, disk artifacts, cloud snapshots, mailbox rules, identity settings, network captures, configuration exports, and a record of responder actions. The appropriate method depends on the incident, systems, authorization, and legal or policy requirements.
Preserve the original source where practical and record how, when, by whom, and with what tooling or access the evidence was collected. Keep relevant time zones, identifiers, query logic, hashes, and context. For a log search, this may mean saving the exact query, time window, source, and result reference. For an endpoint image, it may mean recording the device state, collection method, integrity value, storage location, and custody transfers.
Avoid altering the system unnecessarily. Running unknown tools, rebooting a host, deleting a file, or resetting an account can destroy volatile or contextual evidence. At the same time, security and safety may require prompt action. Coordinate collection and containment so that the rationale and trade-offs are explicit.
Protect the case record itself. Limit access to people with a defined need, retain records according to policy, and keep sensitive personal or business data out of informal channels. A defensible investigation is not only technically correct; it handles evidence responsibly.
Resources
- NIST SP 800-86 Guide to Integrating Forensic Techniques into Incident Response — Use this NIST guide to understand evidence sources, forensic process considerations, and the relationship between technical investigation and incident response.