When a security breach alarm goes off, the first few hours determine whether the organisation manages a controlled incident or an open-ended crisis. Incident Response (IR) and digital forensics are the disciplines that convert that initial chaos into an ordered process: containing the damage, understanding what happened, and preserving evidence in a form that carries legal and probative weight. This article covers the IR lifecycle, the forensic principles that underpin the chain of custody, and the legal notification obligations that in 2026 make reporting a regulated requirement, not an option.
The incident response lifecycle
The most widely adopted framework is that of the NIST, published in Special Publication 800-61, which structures IR into four iterative phases: preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. SANS describes six phases with a similar level of detail. What matters is not the precise number of stages but the understanding that IR is a loop: lessons learned from one incident feed preparation for the next.
- Preparation: the most valuable and most neglected phase. It includes the written plan, playbooks by threat type, team training (CSIRT), asset inventory, and telemetry instrumentation. A team that improvises during an incident has already lost.
- Detection and analysis (triage): distinguishing the real event from the flood of alerts. Priority is set by business impact and breadth of compromise.
- Containment, eradication, and recovery: isolating what has been affected, removing attacker persistence, and restoring service while verifying the threat is no longer present.
- Lessons learned: the blame-free post-mortem meeting that documents what failed and what controls to add.
Triage: prioritising under pressure
Triage is the art of making fast decisions with incomplete information. Three questions guide prioritisation: which systems are affected and how critical are they to the business; is the attacker still active inside the network; and are personal or regulated data involved? A ransomware infection on a production file server holding customer data is a maximum-severity incident; a malware beacon on an isolated test machine is not. The severity matrix must be defined during the preparation phase, because calibrating it under fire leads to costly errors. A key operational principle is not to shut down compromised machines immediately: doing so destroys volatile memory, where the most valuable evidence often resides.
Digital forensics and the order of volatility
Digital forensics acquires, preserves, and analyses electronic evidence in a manner that is admissible and reproducible. Its guiding principle is the order of volatility, defined in RFC 3227: the most ephemeral data is collected first. The standard hierarchy is:
| Priority | Evidence source | Volatility | Typical tool |
|---|---|---|---|
| 1 | CPU registers, cache, routing table, active network connections | Seconds | System commands, collection scripts |
| 2 | RAM (full memory dump) | Until shutdown | Volatility, FTK Imager, LiME |
| 3 | Running processes and temporary files | Minutes to hours | osquery, EDR |
| 4 | Disk (bit-for-bit image) | Persistent | dd, Guymager, write blocker |
| 5 | Centralised logs and backups | Days to months | SIEM, WORM storage |
Memory analysis using a framework such as Volatility makes it possible to reconstruct malicious processes that never touched the disk — so-called fileless malware — to recover volume encryption keys held in memory, and to map command-and-control connections. Disk images are always obtained using a write blocker to ensure the original is not altered during copying.
Forensics is not limited to endpoint disks and memory. Evidence sources have multiplied considerably: proxy and firewall logs reveal exfiltration traffic; Active Directory authentication logs show lateral movement and privilege escalation; in cloud environments, platform audit logs — who created which resource, from which IP, with which credentials — are often the key piece needed to reconstruct a compromise that never touched a physical server. Cloud forensics adds a particular challenge: evidence is ephemeral and shared, so enabling and preserving audit logging before an incident is decisive. An organisation that discovers, mid-investigation, that its cloud logs are retained for only seven days has lost most of the story it needed to tell.
Timeline reconstruction and attribution
The central deliverable of a forensic investigation is the timeline: a unified chronology that arranges every artefact — file creation, process executions, network connections, authentication events — into a coherent sequence. Tools such as Plaso and its log2timeline engine merge timestamps from dozens of sources into a single thread, making it possible to answer the questions that matter: when did the attacker enter (the initial access vector), what did they do next, which data did they touch, and when were they detected. The reliability of that chronology depends entirely on clock synchronisation: if system clocks do not all point to a common NTP source, timestamps from different systems cannot be aligned and reconstruction becomes conjecture.
Attribution — determining who is behind the attack — is deliberately cautious in serious forensic work. Rather than naming suspects, observed behaviour is mapped against frameworks such as MITRE ATT&CK to characterise the adversary by tactics and techniques, and is cross-referenced against threat intelligence to associate it, with explicit confidence levels, with known campaigns. Premature attribution is a common trap: it leads to conclusions that cannot withstand cross-examination and can derail the entire response towards the wrong suspect.
Chain of custody: integrity as a legal requirement
The chain of custody is the uninterrupted documentary record of who had access to each piece of evidence, when, where, and for what purpose, from acquisition through to presentation. If it is broken, the evidence loses its probative value even if it is technically correct. The pillars are:
- Cryptographic hashing: a SHA-256 digest of each image is calculated at the moment of acquisition and verified with every subsequent copy. If the hash matches, the evidence is identical to the original; if it does not, the evidence has been tampered with.
- Working on copies: analysis is never performed on the original evidence, only on a verified copy, preserving the source intact.
- Complete documentation: signed custody forms at every transfer, recording date, time, and the responsible person.
- Secure storage: restricted and logged access to stored evidence.
Common mistakes
The first and most serious is acting on a live system without collecting memory first: rebooting or shutting down destroys irrecoverable volatile evidence. The second is analysing the original rather than an image, contaminating the only authentic copy. The third is failing to synchronise clocks: if the timestamps of different systems are not aligned against a reliable NTP source, reconstructing the attack timeline becomes impossible. The fourth is poor communication: inadvertently tipping off the attacker — for instance, by visibly changing passwords before the full picture is known — or conversely, notifying authorities too late and breaching legal deadlines.
Notification obligations: NIS2 and GDPR
In 2026, incident notification is no longer discretionary. NIS2 (EU Directive 2022/2555), transposed into national law, obliges essential and important entities to notify their national CSIRT of a significant incident with an early warning within 24 hours and a full report within 72 hours. In parallel, when an incident involves a personal data breach, the GDPR requires notification to the supervisory authority within a maximum of 72 hours from becoming aware of the breach, and notification to affected individuals when there is a high risk to their rights and freedoms. These deadlines make the speed of triage a compliance matter and reinforce why the preparation phase must include notification procedures that are already drafted and ready to use.
Frequently asked questions
Do I need an in-house forensic team or can I outsource?
Many organisations combine an internal CSIRT for triage and containment with a specialist provider for deep forensics and expert witness work. What is critical is that retainer agreements are signed before the incident occurs, not negotiated during the crisis.
What is the difference between an IOC and a TTP?
An indicator of compromise (IOC) is a specific data point — a hash, an IP address, a domain — that reveals a known intrusion. Tactics, techniques, and procedures (TTPs), catalogued in frameworks such as MITRE ATT&CK, describe attacker behaviour and are far harder to evade than a simple IP change.
How long should I retain evidence?
Until the statute of limitations for potential legal action has expired and all regulatory obligations have been closed, which typically implies several years. Retention policy should be defined with legal advice.
Does disk encryption complicate forensics?
Yes, if the system is switched off. This is precisely why live memory acquisition is so valuable: the encryption keys for mounted volumes typically reside in RAM while the machine is running.
Conclusion
Incident response capability is not demonstrated on the day of the attack, but in the preceding months of quiet preparation: rehearsed playbooks, deployed telemetry, synchronised clocks, and written custody and notification procedures. Digital forensics adds the rigour that turns a suspicion into admissible evidence, and the chain of custody is what sustains that evidence before a judge or a regulator. The operational lesson is stark: every minute of the first hour consumes volatile evidence that cannot be recovered, and every hour of the first 72 brings the organisation closer to or further from compliance with NIS2 and the GDPR. At Summum Systems we structure IR as a permanent capability, not as a reactive measure, because the only incident response that works is the one that was ready before the incident occurred.