Triage and containment with forensic judgement: isolating machines from the network without powering them off when RAM holds volatile evidence (malicious processes, encryption keys, active connections), and deciding what to contain first based on impact to both the business and the investigation.
What is DFIR
DFIR (Digital Forensics and Incident Response) is the discipline that combines digital forensics with incident response: not just stopping the attack, but reconstructing with evidence what happened, how, and how far it went. The cycle covers initial triage, containment, evidence acquisition with chain of custody, analysis of disk, memory, cloud and M365, reconstruction of the attack timeline —from initial access through to exfiltration—, eradication and verified recovery. What separates DFIR from plain incident response is the forensic weight: every conclusion rests on technical evidence that will stand up in court, before an insurer or in front of a regulator, not on the sysadmin team's best guess.
Why it matters
When a company suffers a breach, the first instinct is usually to restore service as fast as possible: wipe, reinstall, reset passwords. That haste destroys exactly what will be needed later. Without preserved evidence there is no way to know whether the attacker retains persistence, what data left or when the intrusion began; and without those answers, any GDPR notification is made blind, the cyber insurer can reject the claim for lack of documentation, and legal action against the attacker or a negligent third party is dead on arrival. DFIR addresses both needs at once: it contains the incident with sound technical judgement and produces an evidentiary file —forensic images, memory dumps, correlated logs, chain of custody— that supports business, regulatory and legal decisions. Root cause analysis then turns the incident into learning: without a complete timeline from initial access to final impact, the organisation patches the symptom and leaves open the door the attackers came through. With NIS2 and DORA demanding technically detailed notifications within 24-72 hours, improvising is no longer an option.
Key points
Evidence acquisition with chain of custody: forensic disk images, memory dumps, exported logs and cloud artefacts, all hashed, timestamped and with a documented record of who accessed what. Without chain of custody, evidence loses its probative value.
Multi-source analysis: disk (execution artefacts, deleted files), memory (fileless malware, credentials), network and cloud (Azure AD/Entra, M365, access logs). The indicators of compromise extracted feed the hunt across the rest of the environment.
Full timeline reconstruction: initial access (phishing, VPN without MFA, exposed vulnerability), establishment of persistence, lateral movement, privilege escalation and exfiltration. The timeline is the central product of the forensic analysis.
Eradication and verified recovery: removing every identified persistence mechanism, rotating compromised credentials and validating with heightened monitoring that the attacker no longer has access before declaring the incident closed.
A defensible report: conclusions traceable to specific technical evidence, written for three distinct audiences —leadership, insurer/legal and the technical team— and usable in regulatory notifications (GDPR, NIS2, DORA) or in court proceedings.
Example: Ransomware at a manufacturer with cyber insurance
A 300-employee manufacturer wakes up to encrypted production servers and a ransom note. The IT team wants to restore backups immediately, but the insurer requires a forensic investigation before accepting the claim, and the DPO needs to know within 72 hours whether personal data was exfiltrated in order to decide on the regulatory notification. Restoring without investigating would mean destroying the evidence and answering "we don't know" to both.
The DFIR team isolates the affected systems while preserving memory, acquires forensic images of the key servers and analyses the VPN and Active Directory logs. The reconstructed timeline shows initial access twelve days earlier through a VPN without MFA using purchased credentials, lateral movement over RDP, creation of an admin account as persistence, and 40 GB exfiltrated to an external storage service before encryption. With that evidence, the company notifies the regulator with concrete facts, the insurer accepts the claim, the persistent account that a simple restore would have left alive is eradicated, and recovery is verified with heightened monitoring for 30 days.
Common mistakes
- Wiping and restoring before investigating. Recovering service by destroying the evidence leaves the insurer's, the regulator's and the board's questions unanswered, and usually leaves the attacker's persistence alive on systems that were never rebuilt.
- Powering off compromised machines on instinct. RAM holds critical volatile evidence —fileless malware, encryption keys, active sessions— that is lost on shutdown; the right move is usually to isolate from the network and capture memory first.
- Investigating with the everyday domain admin account on the compromised systems themselves. If the attacker is still inside, they watch the investigation in real time and harvest even more privileged credentials.
- Skipping chain-of-custody documentation because 'this will never go to court'. When the insurer disputes the claim months later, or an affected party sues, evidence without documented custody is worth little or nothing.
- Declaring the incident closed once service is back, without verifying eradication. Re-attacks weeks after a 'resolved' incident almost always use the persistence nobody looked for.
Related services
This concept may be related to services such as:
Frequently asked questions
What is the difference between DFIR and incident response?
Incident response focuses on detecting, containing and restoring service. DFIR adds the forensic dimension: evidence acquisition with chain of custody, analysis of disk, memory and cloud, and a complete attack timeline. The outcome is not just a recovered system, but an evidentiary file that stands up before the insurer, the regulator or a court, plus a verified root cause.
When is a DFIR retainer better than calling someone once an incident happens?
A retainer guarantees response SLAs —hours, not days—, a team that already knows the environment, and pre-agreed rates. Without one, the company negotiates contract, price and access in the middle of a crisis, when every hour of delay widens the damage. For organisations under NIS2 or DORA, or with cyber insurance that requires demonstrable response capability, a retainer is usually the rational choice.
What should be preserved in the first minutes of an incident?
The general rule: isolate from the network without powering off. Preserve the RAM of key machines, the logs of the affected systems and the perimeter (VPN, firewall, email), and note every action taken with a timestamp. Avoid logging in with privileged accounts on compromised machines, and do not delete or 'clean up' anything until the forensic team says so.
Does DFIR analysis support GDPR, NIS2 or DORA notifications?
It is practically the only way to meet them rigorously. These regulations demand notification within 24 to 72 hours with detail on scope, affected data and measures taken. Without a forensic investigation, the company notifies blind and risks penalties for incomplete or inaccurate reporting. The DFIR report provides the technical evidence behind every statement made to the regulator.