Overview
Evidence is the factual proof that supports every statement in an incident report — the logs, artifacts, and data that show what actually happened, handled in a way that keeps it trustworthy.
Learning objectives
- Explain the role of evidence in an incident report.
- Identify common types of incident evidence and where they come from.
- Describe the basics of handling evidence so it stays reliable.
Core concept
Evidence is the collected proof underpinning the incident's findings — the data that shows the attacker's activity actually occurred as described. It backs the timeline (previous lesson), the impact assessment, and the root-cause analysis (later lessons), so that conclusions are demonstrable rather than asserted. Common evidence includes logs (system, application, authentication — module 4), SIEM events, EDR telemetry and process trees (module 12), network data (flows, DNS, IDS logs — module 11), memory and disk images captured during containment, and IOCs (module 7). Because evidence may be relied upon for decisions — and, in some cases, legal or regulatory processes — it must be collected and preserved carefully: captured before it is destroyed (recall isolation-over-shutdown, module 15), stored securely, and documented so its origin and integrity are clear. Reliable evidence is what separates a defensible incident report from an opinion.
How it works
Evidence collection begins during response, not after: the SOC captures volatile data (memory, active connections) before it is lost, images disks where needed, and preserves relevant logs before retention expires — which is why isolation (module 15) is preferred over powering a host off. Each piece of evidence is documented: what it is, where and when it was collected, and by whom, so its provenance is clear. To keep evidence trustworthy, the SOC protects its integrity (e.g. secure storage, and where appropriate cryptographic hashes to show it was not altered) and maintains a clear record of handling — a chain of custody — especially when the incident may involve legal, HR, or regulatory action. In the report, findings cite their supporting evidence so each claim in the timeline, impact, and root-cause sections is verifiable. Poorly handled evidence — collected late, undocumented, or altered — weakens or invalidates conclusions, so disciplined handling is part of good response, not an afterthought.
Practical example
Throughout the intrusion response, the SOC gathered evidence: EDR telemetry and the process trees showing the malicious task's creation and parent process; authentication logs proving lateral movement across hosts; network flow records of the connection to attacker infrastructure; and memory/disk images of the affected hosts captured (via isolation, not shutdown) before rebuild. Each item was documented with its source and collection time and stored securely, with hashes recorded to demonstrate integrity. In the report, every timeline entry and impact statement cites the specific evidence supporting it — the 03:01 persistence event points to the endpoint log that recorded it. Because evidence was captured promptly and handled carefully, the report's conclusions are demonstrable and would hold up if the incident escalated to legal or regulatory review. Had the hosts simply been wiped without imaging, that proof would be gone.
Cybersecurity relevance
Evidence is what makes an incident report credible and defensible: it turns the timeline, impact, and root-cause sections from claims into demonstrable facts, and it may be essential if the incident leads to legal, regulatory, HR, or insurance processes. Careful, timely collection (preserving volatile data, imaging before rebuild) and disciplined handling (documentation, integrity protection, chain of custody) — building on the logging, EDR, network, and preserve-while-contain skills from across the path — ensure conclusions can be trusted and withstand scrutiny. Weak evidence handling can render even a correct investigation indefensible, so it is a core response competency.
Common mistakes
- Collecting evidence too late — losing volatile data or logs (e.g. wiping a host before imaging it).
- Failing to document or protect integrity, leaving evidence provenance unclear or its trustworthiness in doubt.
- Making claims without citing evidence, so report conclusions cannot be verified.
Key takeaways
- Evidence is the collected proof (logs, SIEM/EDR data, process trees, network data, memory/disk images, IOCs) that supports every finding in the report.
- It must be captured promptly (before destruction), documented, and integrity-protected, with chain of custody where legal/regulatory action is possible.
- Report findings cite their evidence so the timeline, impact, and root-cause conclusions are verifiable and defensible.
Check your understanding
- What types of evidence support an incident report, and why must volatile data be captured early?
- Why do disciplined documentation and integrity handling matter for evidence, and what can weak handling cost?