What Is DFIR? Digital Forensics & Incident Response

DFIR (Digital Forensics and Incident Response) is the discipline that unites digital forensics and incident response into a single process: investigating what happened on a compromised system while, at the same time, stopping the attack, containing the damage and returning operations to normal. Where digital forensics answers the question what happened and what evidence proves it, incident response answers how do I cut it off now and how do I stop it happening again. A DFIR team does both in a coordinated way, usually against a clock that is running (active ransomware, ongoing exfiltration or a legal notification deadline).

This article explains what DFIR is in technical terms, how its two halves differ, how the response lifecycle is structured, which tools are used, how it fits with the SOC and the blue team, and which legal obligations apply in Spain and the European Union.

The essentials

• DFIR = forensics + incident response, executed at once and over the same evidence.
• The reference framework is NIST SP 800-61 and the SANS PICERL lifecycle: preparation, identification, containment, eradication, recovery and lessons learned.
• The chain of custody and the order of volatility (RFC 3227) are non-negotiable: without them, evidence holds up neither technically nor legally.
• A DFIR team is engaged for ransomware, a confirmed breach or an active intrusion, which usually coincides with a NIS2 (24/72 hour) or DORA notification deadline.

What DFIR is: a technical definition

DFIR is the practice of collecting, preserving and analysing digital evidence of an incident while at the same time managing the operational response to stop the attacker. The key word is union: for years, digital forensics (expert testimony, litigation, court cases) and incident response (technical teams stopping attacks) were separate worlds. In a real 2026 incident they are not. The same analyst who isolates an endpoint to contain ransomware first needs to capture the memory and artefacts that explain how the attacker got in, because that evidence is destroyed the moment the machine is powered off or rebuilt.

A mature DFIR team combines three capabilities: acquiring evidence without altering it, analysing it to reconstruct the timeline of the attack, and responding to contain, eradicate and recover. All of it documented rigorously enough to support an internal investigation, an insurance claim or a court proceeding.

Digital forensics vs incident response

Although they now run together, the difference is worth understanding:

• Digital forensics: focused on the evidence. It acquires bit-for-bit disk and memory images, preserves the chain of custody, and reconstructs which files ran, which credentials were used and what data left the network. Its output is a defensible report: this happened, in this order, and here is the proof. It prioritises integrity and traceability over speed.
• Incident response: focused on action. It isolates systems, cuts command-and-control channels, revokes credentials, applies patches and restores services. Its output is a recovered operation and an attacker locked out. It prioritises speed and containment over completeness.

The tension between the two is real: containing fast can destroy evidence, and preserving evidence calmly can give the attacker time to encrypt more. DFIR resolves that tension with a disciplined sequence, capturing volatile evidence before containing whenever possible.

The incident response lifecycle: PICERL

The de facto standard is NIST SP 800-61 (Computer Security Incident Handling Guide), which the SANS Institute summarises in the acronym PICERL. These are the six phases:

Preparation

Everything done before the incident: asset inventory, centralised log retention, an EDR deployed with detailed telemetry, a written response plan, escalation contacts and emergency access. An incident without preparation multiplies investigation time because the data is missing: without logs and retention, there is no timeline to reconstruct.

Identification

Confirming there is a genuine incident and not a false positive, and determining its scope. This is where alerts from the SIEM and the SOC come in, along with initial indicator analysis. The goal is to answer three questions: what is compromised, since when (the dwell time) and what the attacker is doing right now.

Containment

Cutting off the spread without alerting the attacker or destroying evidence. The endpoint is isolated at the network level (keeping memory live so it can be captured), IoCs are blocked at the firewall and EDR, sessions are revoked and affected networks are segmented. Containment is usually both short-term (stop the bleeding) and long-term (harden while eradicating).

Eradication

Removing the root cause: deleting the malware, closing the entry vector (an unpatched vulnerability, a stolen credential, an exposed service), rebuilding compromised systems from clean images and rotating every credential that may have been exposed.

Recovery

Bringing services back to production in a controlled, monitored way, validating that the attacker retains no persistence. You restore from verified backups, watch the telemetry closely and confirm the IoCs do not reappear.

Lessons learned

The phase most often skipped and most valuable. An honest post-mortem documents the timeline, the root cause, which controls failed and which new detection rules come out of the case. Every incident closed well feeds the preparation phase of the next one.

Essential DFIR tooling

DFIR relies on mature tools, most of them open source:

• Memory acquisition: DumpIt and WinPmem on Windows, AVML or LiME on Linux. RAM holds running processes, network connections, keys and malware that never touches disk, and it vanishes on shutdown.
• Volatility 3: the standard for analysing memory dumps. It lists hidden processes, connections, injected DLLs and credential artefacts.
• Disk acquisition: dd, dc3dd or FTK Imager to create bit-for-bit images with an integrity hash (SHA-256), using a write-blocker that prevents altering the original.
• Autopsy and The Sleuth Kit: forensic analysis of file systems, recovery of deleted data, histories and user artefacts.
• KAPE (Kroll Artifact Parser and Extractor): fast triage that collects only the relevant artefacts (registry, event logs, prefetch, MFT) in minutes, ideal when there is no time for full images.
• Velociraptor: DFIR at scale. It runs forensic queries and collects artefacts across hundreds of endpoints remotely, essential when the incident hits a whole fleet rather than a single machine.
• Plaso / log2timeline: building super timelines that merge thousands of sources into a single ordered timeline.

Above the tools sit the chain of custody and the order of volatility (RFC 3227): you capture the most ephemeral data first (memory, connections, processes) and the persistent data later (disks, backups), and every piece of evidence is hashed, sealed and logged with who touched it and when. Without that discipline, evidence supports neither an internal report nor a court proceeding.

How DFIR fits with the SOC, threat hunting and the blue team

DFIR does not replace the rest of the defence: it closes it. The SOC detects and filters alerts every day; threat hunting proactively looks for what alerts miss; the blue team maintains the defensive posture. When any of them confirms a serious compromise, DFIR is engaged as a specialised emergency response. The telemetry the SIEM produces feeds the forensic investigation, and the detection rules that come out of the post-mortem go back to the SOC. To understand how the detection platforms fit together, the SIEM vs SOAR vs XDR comparison explains the pieces of that chain.

When to engage a DFIR team

Not every incident needs DFIR, but these cases justify it:

• Ransomware, especially with double extortion, where you have to reconstruct the entry vector, confirm what data left and make decisions about backups. It is the most common trigger, as covered in the ransomware in Spain 2026 landscape.
• A confirmed data breach with possible exfiltration of personal or confidential information.
• An active intrusion with evidence of lateral movement or persistence in Active Directory.
• Email or cloud compromise with unauthorised access to privileged accounts.

Many of these vectors start from known initial-access vulnerabilities (Citrix Bleed CVE-2023-4966, MOVEit CVE-2023-34362, PAN-OS CVE-2024-3400), something DFIR confirms during the investigation and the organisation must close during eradication.

Legal obligations in Spain and the EU

In 2026, DFIR is no longer purely technical: it is a compliance requirement. The NIS2 directive requires essential and important entities to send an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. The financial sector adds DORA, with its own scheme for classifying and reporting major incidents. Notification is channelled through INCIBE-CERT (private sector and citizens) or CCN-CERT (public sector and government). Meeting those deadlines with reliable data is only possible if the forensic investigation runs in parallel with containment from minute one: the evidence that supports the notification is the same evidence the DFIR team is capturing.

Frequently asked questions

What is the difference between digital forensics and incident response?

Digital forensics focuses on the evidence: acquiring, preserving and analysing artefacts to reconstruct what happened in a defensible way. Incident response focuses on action: containing, eradicating and recovering to stop the attack. DFIR runs both in a coordinated way over the same evidence.

What is chain of custody and why does it matter?

It is the documented record of who touched each piece of evidence, when and how, along with its integrity hash. It matters because without it the evidence is not reliable: you cannot prove it was not altered, which invalidates it for an internal report, a court proceeding or an insurance claim.

Can the SOC do DFIR or do you need a specialised team?

A mature SOC covers detection and first-tier response, but a serious incident (ransomware, active breach) requires senior forensic profiles, specific tools and a rigorous methodology. The usual pattern is that the SOC escalates to an internal DFIR team or an external response service.

Which open-source DFIR tools are enough to start?

Volatility 3 for memory, Autopsy and The Sleuth Kit for disk, KAPE for fast triage and Velociraptor for response at scale cover most of the work. The non-negotiable piece is not the tool but the data: without centralised logs with retention and an EDR with telemetry, no investigation is possible.

How quickly must an incident be reported in Spain?

Under NIS2, obligated entities must send an early warning within 24 hours and a full notification within 72 hours, with a final report within one month, through INCIBE-CERT or CCN-CERT depending on the sector. The financial sector also applies the DORA deadlines.

Related resources

• What is a SOC: the team that detects and escalates the incidents that trigger DFIR.
• What is threat hunting: the proactive search that often uncovers a compromise before an alert does.
• What is the Blue Team: the defensive function where DFIR acts as the emergency response.
• SIEM vs SOAR vs XDR: the platforms whose telemetry feeds the forensic investigation.
• Ransomware in Spain 2026: the most frequent trigger for a DFIR engagement.

DFIR at Secra

At Secra we support organisations through serious incident response: acquisition and forensic analysis of evidence, coordinated containment, reconstruction of the attack timeline and support to meet NIS2 and DORA notification deadlines. If you have an incident in progress or want to build your response capability before you need it, check our incident response and DFIR forensics service or get in touch through contact.