Cases

Investigation or incident

Every case runs in one of two modes, chosen when you create it. Both carry the same tabs and the same kinds of content: evidence, files, notes, indicators, a timeline, reports and a team.

An investigation suits triage and analysis. An incident adds the machinery of active response: a declared start time, movement through phases, and a duration that runs until the incident resolves.

Behaviour	Investigation	Incident
Actions checklist	First phase only	Every phase
Phase workflow	No	Yes
Declared start and duration	No	Yes
CAN report	No	Yes
Severity control labelled	Priority	Severity
Undetermined value	Allowed, and the default for a new case	Not allowed

The shipped playbooks

A playbook gives a new case its custom fields and its action checklist, grouped by phase. DFIRe ships fifteen for common scenarios. Any of them works for either mode, because the mode belongs to the case rather than the playbook.

Playbook	Its custom fields
Accidental Data Leak	Data Types, Leak Source, Recipient, Records Exposed, EU Personal Data Involved
Cloud Security Incident	Cloud Provider, Account ID, Compromised Identity, Resources Publicly Exposed
Critical Vulnerability Response	CVE ID, CVSS Score, Exploited in the Wild, Assets to Patch, Patch Deadline
Distributed Denial of Service Attack	DDoS Type, Targeted Asset, Peak Attack Bandwidth, ISP Ticket Reference
Financial Fraud Incident	Fraud Type, Attack Method, Financial Loss Amount, Bank Recall Initiated
General Cyber Incident Under Investigation	Suspected Vector, Status, PII Involved, Estimated Systems Affected
Lost or Stolen Equipment	Device Type, Serial Number, Device Encrypted, Contains PII, Remote Wipe Status
Malware Analysis Request	File Hash, Requested Depth, Source System, Submitted By, Appears Targeted
Malware Infection Incident	Malware Family, Detected By, File Hash, Automated Action
Network and Perimeter Compromise	Device Type, Exploited CVE, Internet Facing, Firmware Version
Phishing and Social Engineering Campaign	Sender Address, Users Targeted, Users Who Clicked, Malicious URL
Physical Security Incident	Type, Site Location, Specific Zone, Assets Impacted, Police Report Number
Policy and Compliance Violation	Violation Type, Subject Employee, HR Case Reference, Legal Hold, Estimated Financial Impact
Ransomware Attack Incident	Ransom Demand Amount, Ransomware Strain, Viable Offline Backups, Data Exfiltration Confirmed
Third Party and Supply Chain Incident	Vendor Name, Service Type, Data Types Shared, Contract Reference

Administrators can edit these or add their own under Settings → Playbooks. See Playbooks.

Creating a case

Choose New Case on the dashboard.

1. Pick the mode and the severity

   Investigation or incident, then one of critical, high, medium, low or info. On an investigation that control reads Priority and also offers Undetermined, the default. Use it when you open a case before you know its priority.

2. Name the case

   If your organization uses codenames, the button beside the title field picks an unused one. External Reference takes a ticket number from another system, and Project groups this case with others.

3. Choose a playbook

   Required. It decides the case's custom fields and its action checklist. ENISA Category is optional and classifies the case for reporting.

4. Fill in the playbook's fields

   When the playbook defines custom fields, DFIRe collects them on a second step before creating the case. Required ones are marked.

5. Create it

   DFIRe assigns the case number and opens the case. With Slack enabled you can also tick Create Slack channel for this case before creating.

A new case opens with the status Open. Lead investigator in the dialog starts with your name. Select another user to give the case to them, or select No lead to leave the case unassigned. A case without a lead is visible to every user who can edit cases. Add the rest of the team afterwards with Team in the case header.

Acknowledgement

An open case has one of three states:

• Open - New: nobody has taken the case on yet.
• Open - In progress: someone has acknowledged the case.
• Open - Resolved: the incident is in its resolving phase, or in a phase after it. See Resolving an incident.

The state is on the dashboard card, in the case header and in the case side panel.

To take a new case on, select Acknowledge in the case header or in the Case Overview on the Case tab. DFIRe records the time and who acknowledged the case, and adds the acknowledgement to the timeline. You need permission to edit the case. A user who may edit cases can also acknowledge a case that has no lead, and then becomes its lead. The Case Overview shows who acknowledged the case and when. You can also acknowledge a case with /dfire acknowledge in Slack, with the MCP tool acknowledge_case, or with POST /api/cases/{id}/acknowledge/.

To hand a case back, select Edit Case, then Reset beside Acknowledged, and save. The case reads Open - New again, so another analyst can pick it up. DFIRe clears who acknowledged the case and when, and records the reset on the timeline. The acknowledge SLA target keeps the first acknowledgement, so a reset never restarts the clock. Only an open case can be reset, and a case whose acknowledgement time is unknown cannot be. The MCP server does the same with the reset action of acknowledge_case.

The lead investigator does not change the state. A case with a lead is still new until someone acknowledges it, and removing the lead does not make an acknowledged case new again.

In the New Case dialog, Status chooses how the case starts. Open - New, the default, leaves the case for someone to acknowledge. Open - In progress acknowledges it as it is created. A case created through the MCP server, Slack or an automation is always new. Through the API, send acknowledge: true to create the case acknowledged.

A new case that is resolved or closed is acknowledged at that moment, so closing a false positive does not need an acknowledgement first.

To correct a wrong acknowledgement time, select Edit Case and change Acknowledged. The time cannot be before the creation of the case or in the future.

Cases that were taken on before DFIRe recorded acknowledgements have no acknowledgement time. They read Open - In progress. Reset is disabled while that time is unknown.

Working in a case

Every case carries the same ten tabs, in this order: Case, Report, Timeline, Slack, Actions, Notes, Files, Evidence, IOCs and Compliance. Slack appears only when an administrator has enabled it.

The mode changes what is inside two of them. An investigation's Actions tab shows only the playbook's first phase, and its Case tab has no CAN report.

Case

Case Overview comes first. It shows who created the case and when, and who acknowledged it and when. For an incident it adds the declaration. A resolved or closed case shows its first resolution. A closed case shows its closing time, an archived case when it was archived, and a reopened case how many times it was reopened. The overview also shows the time open and the SLA targets of an incident with their state. A row of counts closes it: evidence, files, notes, indicators and actions, with the Acknowledge button on a new case. Export Case and Copy for AI sit on the heading row of the overview.

On an incident, the CAN report follows: a situation summary in three parts. Conditions describes the current state, actions covers what is under way, and needs lists what is still outstanding. See Reports. The case description follows.

When the playbook of the case has a description, the tab ends with it as Playbook Description. It is read from the playbook each time, so an edit to the playbook shows on every case that uses it. A playbook without a description adds nothing. The playbook name under the heading, and in the side panel, opens the playbook for users who may view playbooks.

Report

The formal write-up. The investigation report is a sectioned document, and each section moves through three stages on its own. A section starts as Draft, becomes Ready for QA when it is finished and waiting on a reviewer, and ends as QA Completed. Which sections exist comes from the templates an administrator configures under Settings → Reporting, not from the playbook.

Timeline

A chronological record of the case: its creation and status changes, phase transitions, notes posted to it, evidence added or changed, team changes and completed actions. See Timeline.

Actions

The response checklist from the playbook, grouped by phase. Each action sits in one of five states.

• Pending, not yet started.
• Started, taken by an assignee and in progress.
• Blocked, waiting on something. It applies to a pending or a started action and needs a note saying what it waits on. See Incident response.
• Done.
• Skipped, not applicable to this case.

The icons on action cards and in Slack are ⚪ pending, ⚡ started, ⛔ blocked, ✔️ done and 🚫 skipped. The sidebar tracks how many are complete.

With Jira connected you can raise a Jira issue from an action. A DFIRe user whose email matches a Jira account can be assigned automatically, and status changes travel in both directions.

Notes

Investigation notes in Markdown, each timestamped and attributed to its author. A note can be posted to the timeline, or included in the investigation report as a lettered appendix, but not both; either switch can be turned off again. With Slack enabled a note reaches the case channel. Import bulk-loads notes from a CSV file and previews what it will create or update first.

IOCs

Indicators from the global registry that this case is associated with. Add existing ones, create new ones, or paste text and let DFIRe extract the addresses, domains, URLs, hashes and email addresses out of it.

Each association carries a case context field for notes that belong to this case alone. It is visible here and not in the registry.

Files, Evidence and Compliance

Files holds attachments on the case itself, and Evidence holds the artifacts under examination, each with its own files and custody record. See Evidence and Storage. Compliance carries the regulatory notification timers. See Compliance timers.

Slack and chat

The Slack tab shows the case's Slack channel inside DFIRe. Create the channel, read it and post to it without leaving the case. From Slack, /dfire commands reach back, and reacting to a message with the pushpin emoji captures its file into the case. An administrator enables this under Settings → Slack Integration.

Separately, every case has its own case chat, which docks beside the case or pops out into its own window. It needs no Slack. See Case chat.

The sidebar

The collapsible panel on the right summarizes the case in short lines. It shows how many actions are complete and the state of any compliance timers. Then come the status, the project, playbook, reference, lead investigator and team. The project name opens the project page. Below those sit the custom fields the playbook defined. Timestamps, the SLA targets and the counts of the case are on the Case tab.

An incident adds two more. Incident phase shows the current phase and when it last changed. Incident duration counts from the declaration and stops when the incident reaches its resolving phase or the case closes. You can correct both timestamps in Edit Case.

The case team

Team in the case header lists who is on the case. Search under Add User to Case to add someone. They join at the lowest access their role allows, usually view. Edit on their row grants write access, and None takes them off. Changes apply when you save, and closing the dialog with unsaved changes asks first.

Lead on a row makes that person the lead investigator. One person leads at a time, so the previous lead moves to Edit. You can also change the lead in Edit Case.

On the case	What it grants
Lead investigator	Write access, and ownership: the case is listed and filtered under this person. One per case.
Investigator	Write access to the case's content.
Viewer	Read-only.

Open, closed, archived

A case is open while people work it. Closing it makes it read-only, which prevents an accidental edit to finished work. Archiving puts it into long-term storage and out of the default views.

Change the status in Edit Case. Neither closed nor archived is final: reopen the case and it becomes editable again. An archived case has to be reopened before it can be closed.

Retention rules can archive and delete cases on a schedule. See Configuration.

Projects

A project groups cases that belong together: a large investigation spanning several devices, recurring work for one customer, or a set of incidents that share context. Create one with New Project on the dashboard, then assign cases to it when you create or edit them. Creating a project needs the permission to create projects. Of the shipped roles, Team Lead and DFIRe Admin have it, and Standard user does not.

Project details

A project has a name, a color, a description in Markdown, a project lead and a list of linked legal entities. Each linked entity has a role: Organization, Primary contact, Technical contact, Legal contact or Other. Contact details come from the entity record, so you keep them in one place. On the project page, select an entity to open its record. Only users whose role may view legal entities see the linked entities and can edit them. See Entities.

The color is optional. Pick it when you create or edit the project, or type it as a hex code such as #0f766e. The Projects tab on the dashboard shows the color on the card or row of the project, and the project page shows it along the top of the project details. It helps you find a project in a long list.

The project lead always sees the project, also without access to any of its cases. A project keeps its lead when the lead's account is deactivated. The project page and the edit dialog then show the lead as deactivated. Only active users can become the lead.

When the legal entity you need does not exist yet, select New Entity beside the Legal entities heading in the project dialog. It shows when your role may create legal entities. The new entity is linked to the project as a primary contact; change the role if needed.

To edit a project, open it and select Edit project, or go to Settings, then Projects. Editing needs the permission to change projects.

The project page

The project page shows the description, the lead, the linked entities, the incident SLA targets with the number of open incidents at risk or breached, and the cases of the project. The same Open cases, Closed and Archived tabs as on the dashboard split them. The page lists only the cases you have access to, and the case counts follow the same rule.

Open the page from the Projects tab on the dashboard, or select the project name on a case card.

To create a case in the project, select Add case. The New Case dialog opens with the project already chosen. An inactive project has no Add case button.

A case that you open or create on the project page links back to the project, for example Back to Acme. A case opened from the dashboard links back to the dashboard.

Users with access to Analytics also see key figures of the project for the last 30 days. The figures are the cases opened and closed, the median times to acknowledge and to resolve, and the share of targets met for each. Project analytics opens Analytics with the project selected. See Analytics.

Incident SLA targets

A project can set service level targets for its incidents, in calendar hours. Investigations have no SLA. Each severity has two targets, and both are optional:

• Acknowledge runs from the declaration of the incident to its acknowledgement. An investigation that was acknowledged before it was escalated meets this target at once.
• Resolve runs from the declaration to the first resolution, which is the move to the resolving phase or a phase after it. For an incident closed before that, it runs to the closure. If the incident is reopened, this target keeps the result of the first resolution.

To set the targets, create or edit the project and fill in Incident SLA targets (hours). A field left empty reads No SLA and sets no target. Each target is a whole number of hours, from 1 to 8760. The resolve target cannot be shorter than the acknowledge target of the same severity.

A target is at risk when 80 percent of its time has passed, and breached when all of it has passed. An open incident has one SLA state: the state of its running target with the earliest deadline. Both targets start together. Pauses extend only the resolution deadline. The dashboard card of an open incident shows each running target with the time left, or with the overdue time after a breach. A bar under the clocks shows the time used of the target that sets the SLA state. The bar is green while that target is on track, amber when it is at risk, and red when it is breached. A finished target is dimmed, and on a closed case both are. The Case tab shows both targets. A finished target reads Acknowledged or Resolved and shows the time it took, behind a green check mark when the target was met and a red cross when it was breached. The dashboard card shows the same. The project card and the project page show how many open incidents are at risk and how many are breached.

The targets of an incident are those of its severity. While the incident is new, a change of the severity also changes the targets. When the incident is acknowledged, the severity it has then sets the targets. A later change of the severity does not change them, so an incident inside its target does not breach because its severity was raised.

An incident that gets its project later is measured from its declaration, not from the time it got the project.

Pause resolution SLA

Use Pause SLA timer when progress depends on another party or an internal dependency. Find it in Case Overview or at the bottom of Incident Duration in the sidebar. The control is available for acknowledged, unresolved open incidents with a resolution target. Changing the pause needs case edit permission.

Paused time does not count towards the resolution SLA. The acknowledgement SLA and calendar incident duration stay unchanged. The case card shows a pause icon before the resolution counter and a blue progress bar. Its tooltip shows total paused time. The collapsed sidebar also shows a pause icon. A breach that existed before the pause stays a breach, and Analytics keeps it in the period in which it happened.

Turn the Case Overview toggle off, or select Continue SLA timer in the sidebar, to resume. Each pause adds to the total. Resolution or closure ends an active pause automatically, and reopening does not restart it. The timeline records each pause, and the entry written when the timer resumes says how long it was paused, this time and in total. The Case Overview shows the paused total beside the time open. Resolution SLA alerts wait until the clock resumes.

For automation, use GET /api/cases/{id}/sla-pause/ to read paused, paused_since and total_paused_seconds. The duration includes the active pause.

Send POST with {"paused": true} to pause or {"paused": false} to resume. Repeating the current state changes nothing. An empty POST body or {} reads the same state. POST requires case edit permission, including empty-body reads. GET requires case read permission.

SLA alerts

DFIRe checks the running targets of open incidents on the compliance timer schedule. A target sends one alert when it becomes at risk and one when its deadline passes. A target whose deadline has already passed when DFIRe first checks it sends only the breach alert. A target that stops and then runs again can alert again.

An alert goes to:

• Notifiers subscribed to the SLA at risk or SLA breached event. See SLA.* variables.
• The Slack channel of the case, when DFIRe is connected to Slack. DFIRe always posts the breach alert. The at-risk alert follows its setting under the Slack event delivery settings.

Notifiers can also subscribe to Case acknowledged. It fires when someone selects Acknowledge. It does not fire for a case acknowledged in the New Case dialog, or for a case acknowledged by its resolution or closure.

Inactive projects

Set a project inactive when the work for it has ended. An inactive project keeps its cases and its page. It accepts no new cases, and it no longer appears in the project lists for new cases. While it has open cases, it stays in the project filter of the dashboard, so you can follow the work that remains. To set a project inactive, edit it and turn off Project active at the bottom of the dialog.

Deleting a project needs the permission to delete projects, and DFIRe refuses to delete a project that has cases. Delete is available only for a project without cases.

Finding a case

The dashboard splits into Daily Summary, Open cases, Closed, Archived and Projects, and filters the case list by project, investigator, severity, attention and mode. Cases can also be sorted by SLA time left. See Dashboard.

The search icon in the header searches across cases, evidence, notes and more. See Search.