What is DFIR? How a police investigation explains modern incident response

It’s 2 AM. A neighbor hears glass shattering. The police arrive to find a body, a weapon and something odd—a strange symbol etched near the scene. They don’t know yet what it means, so they photograph everything, bag the evidence and open a case.

If you’ve ever lost a Friday night to a CSI or NCIS marathon, this might feel familiar. Turns out, the people protecting your organization’s data follow a remarkably similar playbook.

Every single day, security analysts across the world are doing the exact same thing, except their “crime scene” is a SIEM console, and the shattered window is a suspicious login from an IP in a country where their companies have no business.

That discipline—investigating and neutralizing threats—is what we in cybersecurity call DFIR.

DFIR stands for Digital Forensics and Incident Response. Digital Forensics is the investigation side: collecting evidence, understanding what happened, who did it and how. Incident Response is the operational side: containing the threat, eradicating it and restoring normal operations. Together, they form the discipline that allows organizations to understand threats early, react fast and recover fully.

Every detective knows that before you can investigate a crime, you need to understand what was stolen, damaged or threatened. In information security, it comes down to three things, and an incident is anything that compromises one (or more) of them:

• Confidentiality (your secrets stay secret)
• Integrity (your data hasn’t been tampered with)
• Availability (your systems stay up and running)

Now, let’s compare both stories phase by phase through the prism of DFIR!

Great detectives don’t just show up and improvise. Before any crime happens, they’ve already done the work: they know the neighborhood; they have a trained team, trusted informants and efficient protocols; they know who to call when they need a lab analysis done fast.

In incident response, preparation is everything. Here’s what it can include:

• building your playbooks before the incident, not during it;
• defining what a “critical asset” looks like for your organization;
• training your analysts on playbooks;
• setting up your detection and alert ingestion;
• making sure your tools are configured to surface the right signals.

When the glass breaks at 2 AM, you don’t want to be googling “how to preserve forensic evidence,” right?

The neighbor calls it in: an unusual situation, an anomaly that doesn’t fit the normal pattern of the neighborhood.

In DFIR, this is your detection phase: the moment an unusual signal surfaces. An EDR fires an alert, a SIEM rule triggers, someone notices an anomaly in network logs.

The police arrive and start documenting: a broken window (the entry point), a blunt object (the weapon), a victim, footprints near the window, fingerprints on the weapon and that odd symbol. All of these are observables, every piece of evidence that can be collected, tagged and analyzed.

Then, verification starts: is this a true positive or just noise? Is this a sophisticated intrusion or just Bob from accounting clicking on a phishing email? So, the investigators triage and enrich their signals: what’s here, what matters, what do we need to preserve right now?

Your analysts do the same. They look at the alert, enrich it with context, pull in related observables (IP addresses, file hashes, domain names, user accounts) and start asking: what exactly happened here?

This is where a “single pane of glass” matters: detectives don’t want three different notepads from three different officers. They want one case file, one shared picture of the scene.

Two days after the first murder, the police get a call: another body in a different part of town. But—same broken window entry, same type of weapon, and that symbol again. They go back and compare: same M.O.; same signature.

A week later: a third victim, same description. Now the detectives aren’t just looking at three separate crimes but at one threat actor. This is where incident response gets interesting and where teams without the right tooling can start to drown.

In cybersecurity terms, those three murders are three separate alerts that triggered three separate cases. And across all of them, the analysts are finding the same observables: the same malicious domain, the same attacker infrastructure, the same pattern of lateral movement. These similarities are not coincidences.

A seasoned analyst doesn’t just work on each case in isolation. They look up, connect the dots and realize: these three investigations share the same TTPs, indicators and threat actor fingerprint.

As soon as they have enough evidence to confirm these cannot be separate cases, they do what any good detective would do: they merge the cases to get one unified investigation, one shared timeline and one place where every piece of evidence lives.

Then, at the third crime scene, the detective notices that a home security camera across the street was running that night. They pull the footage and send it to the lab for analysis. This can be compared to a Cortex analyzer at work: you hand it an observable, and it hands you back tailored reports from chosen intelligence sources.

The footage reveals a car with readable plates. The plate number already leads to the vehicle’s owner. It also leads to the vehicle registration, then to a purchase record, then to a credit card number which confirms the owner’s identity… And everything clicks: you have a suspect.

Every new indicator gets added to the case; every connection gets documented. The case is becoming a story, with a beginning, a middle and hopefully an end.

The detective has enough evidence and knows who they’re looking for. Now comes the decision: what to do with this information? We in cybersecurity call this “choosing a posture.”

Do you quietly put the suspect under surveillance while you build a stronger case? Or do you move in now and make the arrest before they can strike again? Even in the cybersecurity world, this is a human decision based on all the evidence you have, and it shapes everything that follows.

Should your incident response team isolate the compromised endpoint immediately (and potentially tip off the attacker that you’re onto them)? Or should you monitor the threat actor’s movements a little longer to understand the full scope of the intrusion before you pull the plug? There’s no universal right answer: it depends on what you know, what you still need to find out and how much risk you can accept while you watch.

Once the posture is set and the decision is made, you can act to contain, eradicate, neutralize the threat. And here, time matters as much as precision. In TheHive, Cortex responders let analysts trigger automated response actions (like isolating a host, blocking an IP, revoking credentials) directly from the case without jumping between five different tools (and just as many browser tabs).

The detective picks up the phone and triggers the required procedures: the streets get blocked, the airports are alerted, the cell phone signal is jammed.

The suspect is in custody, but the crime scenes are still a mess. The windows are still broken; the victims’ families need to know what happened; the neighborhoods need to feel safe again.

In cybersecurity, this means you need to restore affected systems, patch the vulnerabilities that were exploited, validate that the threat is fully removed and not just dormant, and make sure the business can operate normally again.

Skipping all this is how you end up with the same attacker walking back in through a window you forgot to fix.

The detective now has to write a full report and sit down with the team for a debrief. What happened? What worked well? What went wrong? What was missing—tools, access, documentation, skills? How can we improve? That debrief is what turns a one-time investigation into institutional knowledge.

In DFIR, the post-incident review serves the same purpose. When the dust has settled but the details are still fresh, you’re asking the same three questions: what worked, what didn’t and what gaps did this incident expose in your preparation?

The incident report that comes out of it is a powerful communication tool that you present to the CISO, the board, the regulators, the cyber insurer. It demonstrates due diligence and drives the improvements that feed back into Phase 1, making your team sharper before the next incident hits.

But there’s something even more important that most people overlook.

Here’s a scenario any experienced security team has lived through: an incident gets investigated, partially closed, and then six months later, something similar happens again. A new analyst starts from scratch, picking up the new case with no idea that this exact threat actor has been seen before.

In criminal investigations, they call this a cold case.

Cold cases can only be solved if the evidence is properly preserved, documented and accessible to whoever picks it up next. A case that was opened two years ago needs to be just as readable and actionable today as it was the day it was created. New analysts/different team should have access to same evidence/conclusions.

This is why we built TheHive.

A good incident response platform isn’t just a task manager with an “IR” sticker on it. It’s a structured case management system designed to make every investigation reproducible, collaborative and future-proof. Every observable, every task, every piece of evidence, every analyst note—it all lives in one place, tied to the case, with full history.

All this because cases get reopened, new analysts join the team, external investigators come in and the threat actor you caught last spring might be behind next autumn’s ransomware attempt. When that day comes, you don’t want to be the detective who lost the evidence bag.

Here’s what I’ve learned after years of working with security teams: the difference between a good investigation and a great one lies not just in skill but also in tooling and process.

A detective without an evidence chain is just a person with a hunch. An analyst without a structured case management platform is just a person with a lot of open browser tabs.

The DFIR cycle—Preparation, Detection, Identification, Containment, Eradication, Recovery, Lessons Learned—maps almost perfectly onto how good investigators work. Executing this methodology consistently, at scale, across teams/months/multiple concurrent incidents requires the right tools.

TheHive was built to give your security team the structured environment they need to work like the best detectives in the world:

• Case templates and knowledge bases ready before the incident hits,
• Automatic alert ingestion and similarity detection at the triage stage,
• Collaborative case management, observable tracking and Cortex-powered enrichment during the investigation,
• Automated response actions at containment,
• Built-in reports, operational dashboards and past case search when it’s time to learn.

One platform for every phase of digital forensics and incident response.