Digital forensics and incident response (DFIR) combines two jobs: incident response, which detects, contains and recovers from a security incident, and digital forensics, which collects and analyzes evidence to establish what happened. They pull in different directions, since speed argues for acting and evidence argues for waiting, so teams need to decide the trade-off before an incident.
How do the two halves differ?
NIST SP 800-61 Revision 3 treats incident response as part of cybersecurity risk management, aligned to the Cybersecurity Framework 2.0, and says doing so helps organizations prepare, reduce the number and impact of incidents, and improve detection, response and recovery. It is a lifecycle, not an emergency button.
NIST SP 800-86 covers the forensic side. It is intended to help organizations investigate computer security incidents and troubleshoot some operational problems by giving practical guidance on computer and network forensics, from an IT view and not a law enforcement view. It describes processes for forensics and the data sources: files, operating systems, network traffic and applications. It also says it is not an all inclusive step by step guide or legal advice, and tells readers to consult management and legal counsel on the laws and regulations that apply.
Where do they conflict?
CISA's #StopRansomware guide contains a clear example. During containment it advises isolating affected systems immediately, and if that is not possible it advises powering devices down to stop spread. It then adds that powering down prevents the organization from keeping infection artifacts and potential evidence stored in volatile memory, so it should be done only if the network cannot be disconnected by other means. For cloud resources it advises taking a snapshot of volumes to get a point in time copy for later forensic review.
That one passage shows the trade-off. Each action that stops damage may destroy evidence. A written decision about which wins, and who may make that call, belongs in the plan.
What does an investigation need that a response does not?
Time stamps you trust, a record of who handled which evidence and when, copies instead of originals where possible, and notes written as events happen. Response needs speed. Forensics needs a record that someone else can follow, whether that someone is a regulator, an insurer, a court or your own team next quarter.
The same CISA guide advises coordinated isolation and out of band communication, such as phone calls, because attackers may monitor your communications to see if they have been detected. That affects forensics too: tell the investigators and the responders through a channel you trust.
A constructed example
A company sees a suspicious process on a file server. The on call engineer disconnects the server from the network, leaves it powered on, and takes a disk snapshot and a memory capture before anyone touches it. The investigators later find a stolen service account that was used from a second machine nobody had noticed. Had the server been rebooted first, the memory capture that showed the connection would not exist. The plan that made this possible was a single page: who may isolate, what to capture first, where to store it.
How to check or apply this
- Write down who can declare an incident, who leads, and who talks to legal counsel.
- Decide the default containment action and the evidence to capture before it, such as snapshots and memory.
- Make sure log retention is long enough to cover an intrusion that lasts weeks, and that logs are stored away from the systems they describe.
- Keep a contact list that works if email is down, and agree on out of band communication.
- Record every action with a time stamp and the person who did it.
- Involve legal counsel early, as NIST SP 800-86 advises.
- Practice with a tabletop exercise and fix what it exposes.
- After the incident, review and feed the findings back into the plan.
Quick check
Should you power off a compromised machine?
Not by default. CISA advises isolating it from the network first and powering down only if that is impossible, because powering down loses volatile memory evidence.
Is DFIR the same as a security operations center?
No. A SOC monitors continuously. DFIR is the investigation and response work, often triggered by what a SOC or other sources find.
Sources
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations
- NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
- CISA: #StopRansomware Guide
Last reviewed: 18 October 2026.
