Getting started
Configuration
DFIRe keeps almost all of its configuration inside the application, under System Settings. This page maps the settings area and covers the tabs that no other page does.
Reaching Settings
Open the user menu in the application header and choose Settings.
There is no single administrator permission for the settings area. You reach it as soon as one tab is visible to you, and you see exactly the tabs you hold permissions for. A role that can only edit playbooks gets into Settings and finds the Playbooks tab there, and nothing else.
Two kinds of gate apply. Some tabs admit superusers only, because they hold installation-wide secrets and connection details. The rest check the specific permissions for the records they manage, so you can delegate one area without granting the others. Assign those permissions in Users and roles.
New installations are not empty. DFIRe ships with playbooks, runbooks, evidence types, triage flags, workflow steps, incident phases, categories, verdicts, compliance timers and report sections already configured. The default settings file is that starting state, and importing it under Global Settings returns an instance to it.
The tabs
Settings holds 34 tabs in three groups. Most of them configure a feature that has its own page, and the tables below name that page.
System
| Tab | Who can open it | Documented in |
|---|---|---|
| Global Settings | Superusers | This page |
| Storage | Superusers | Storage |
| Email Delivery | Superusers | Email delivery |
| Single Sign-On | Superusers | Single sign-on |
| License & Updates | Superusers | This page |
| Retention Policy | Superusers | This page |
| Playbook Policy | Superusers | This page |
| Backup & Recovery | Superusers | Backup and recovery |
| Scheduled Jobs | Superusers | This page |
| Dependencies | Superusers | Third-party licences |
| Support | Superusers | Support and diagnostics |
| User Accounts | User permissions | Users and roles |
| Access Roles | Role permissions | Users and roles |
| Automation | Automation rule permissions | Automation |
| Reporting | Report template permissions | Reports |
| Compliance Timers | Compliance timer permissions | Compliance timers |
Integrations
| Tab | Who can open it | Documented in |
|---|---|---|
| Webhooks & Email | Webhook permissions | Webhooks and Email |
| Slack Integration | Superusers | Slack and Jira |
| Jira Integration | Superusers | Slack and Jira |
| Log Integration | Superusers | Audit log |
| IOC Enrichment | Superusers | Indicators of compromise |
| IOC Sharing | Superusers | Indicators of compromise |
| AI / LLM | Superusers | AI integration |
| MCP Server | Superusers | MCP server |
Case properties
These tabs define the vocabulary that case and evidence forms offer.
| Tab | Who can open it | Documented in |
|---|---|---|
| Case codenames | Superusers | This page |
| Triage Flags | Triage flag permissions | This page |
| Projects | Project permissions | Cases |
| Playbooks | Playbook permissions | Playbooks |
| Runbooks | Runbook permissions | Runbooks |
| Evidence Types | Evidence type permissions | Evidence types |
| Evidence Workflow | Workflow step permissions | Workflows |
| Incident Lifecycle | Incident phase permissions | Incident response |
| Incident Categories | Incident category permissions | This page |
| Outcome Verdicts | Outcome verdict permissions | This page |
Legal entities are not a settings tab. The registry of people, organizations and agencies has its own page in the main navigation. See Entities.
Global Settings
Installation identity, report branding, API key limits and configuration transfer.
Organization
The organization name and contact email identify this installation to the license server, and the name appears in the application and on reports. DFIRe asks for both at first sign-in.
Organization logo
The logo appears in the application header and on printable report title pages. Use a PNG with a transparent background, around 300 by 100 pixels. DFIRe accepts PNG and JPEG, up to 500 KB. Without a logo, DFIRe uses its own.
API key policy
Two limits apply to the keys users create for themselves. Maximum keys per user caps how many active keys one account can hold, from 1 to 20. Maximum key lifetime caps how far ahead an expiry date can go, from 1 to 3650 days. The tab also links to the REST API reference and the OpenAPI schema. See API access.
Report customization
The title page disclaimer prints at the bottom of report title pages. Leave it blank to hide it.
The message of the day is a notice on the login page. It supports Markdown and is visible to everyone who reaches the login screen, including people who have not signed in.
Data portability
Export and import move configuration between installations. They carry reference data: roles, playbooks, runbooks, evidence types, triage flags, phases, categories, verdicts, workflow steps and webhooks.
- Export writes a JSON file. Without a password it leaves out secrets and the storage configuration. Set a password and DFIRe writes an encrypted file that carries both.
- Import reads such a file and shows what it would add, update or remove before you confirm.
An import matches incident phases by name rather than by position. The phase a case sits in therefore survives a file that moves it up or down the list. A phase the file does not contain disappears, and the cases in it keep no phase until you set one. Workflow steps match by position instead. An import only adds and updates incident categories and outcome verdicts, and never removes them.
An export is not a backup. It carries no case data. It also leaves out the values that identify this installation: the license details, and the database connection for backup and restore. An import leaves those alone too, so a file from another installation cannot overwrite them. For case data, see Backup and recovery.
License & Updates
The status card names the current state: an active license with its expiry, a trial with the days left, an expired license, or offline mode. It also shows the running backend and frontend versions.
License server connection
This section shows whether the installation is registered and when it last checked in. DFIRe checks in every hour. Each check-in identifies the installation: installation ID, a system identifier for this deployment, hostname, organization, contact email and license key. It describes the environment: DFIRe version, Python version, operating system and timezone, and reports whether single sign-on and email are configured. It counts active user accounts, cases and evidence items, and the users who signed in and cases created in the last 30 days. It carries the dates of registration, of the last change to the installation record and of the check-in. Turn usage metrics off and DFIRe sends zeroes for those five counts. Everything else goes either way.
Check in now forces a check-in. Re-register recovers an installation whose registration key was lost, for example after a restore from backup, without reinstalling.
If the license server is unreachable. DFIRe keeps working for 90 days and warns more insistently as that window closes. The end-user licence agreement guarantees 14 days. The longer window is how current releases behave rather than a contractual commitment, and it may change. After 90 days the application turns read-only. To recover it, install an offline continuity licence, which covers the rest of your paid term with no dependency on the licensing service. Request one from [email protected]. The upload works even in read-only mode. A term that a reachable server reports as genuinely expired turns read-only at once, because the grace window never extends a paid term.
Activating a license
Paste the key, in the form DFIRE-XXXX-XXXX-XXXX-XXXX, and choose Activate.
Offline licensing
Use an offline license when the installation cannot reach the license server. Copy the installation ID from the Offline License section, send it to [email protected], and upload the .dfire-license file you receive. An offline license binds to one installation and cannot move to another. It costs nothing extra.
Retention Policy
Automatic lifecycle rules for cases and indicators. The tab shows when the policy last ran and when it runs next. Leave every toggle off and nothing is ever removed automatically.
Case retention
Auto-archive closed cases moves a closed case to archived after the number of days you set, counted from when it was closed. Auto-delete archived cases then removes archived cases after a further period, counted from when they were archived.
Auto-delete is permanent. It removes the case and everything attached to it: evidence, attachments, notes and timeline events. Nothing recovers it except a backup. Confirm your backups work before you enable this.
IOC lifecycle
Default IOC expiration sets how many days a new indicator stays valid. Zero means it never expires. Auto-revoke expired indicators revokes indicators whose valid-until date has passed. Auto-delete revoked indicators removes revoked indicators after a further period, counted from when they were revoked.
Playbook Policy
How often playbooks are read through again, and who may manage them. The two parts are independent, so turning review off does not lift the ownership rule. For what a review is and what it certifies, see Playbooks → Periodic review.
Periodic Review
Review period is how long a playbook stays current after a review, in days. Set it to 0 and periodic review is off. Playbooks carry no deadlines, DFIRe sends no reminders, and nobody can record a review. Everything already recorded stays where it is, so switching review back on picks up the earlier history.
Review reminders are extra warnings, sent the given number of days before the deadline. Add up to nine, none of them longer than the review period. The deadline itself always notifies, whether or not you add a reminder, so DFIRe always reports an overdue playbook.
Periodic review switched on is the time review was last enabled on this installation. DFIRe stamps it every time you switch review on, and clears it when you switch review off. Changing the period while review is on leaves it where it is. Playbooks that carry neither a review nor a creation date count their period from this time. That is what gives an existing library its first deadlines. The row appears once you set a review period.
Playbook management access control
Restrict playbook management to playbook owners narrows changing, reviewing and deleting a playbook to the users and roles listed as its owners. Anyone with case rights still uses every playbook, and superusers are exempt. While the policy is on, only a superuser assigns owners, and a role that holds no case permission at all sees only the playbooks it owns. It is off by default. See Playbooks → Who can manage a playbook, which covers ownership assignment and how to build a role for a delegated playbook editor.
How reminders reach people
A daily job compares every playbook against its deadline. When a playbook crosses a reminder day, DFIRe notifies the playbook's owners in the app and fires the Playbook Review Due webhook event. Each reminder day sends once per review cycle.
Both owner lists count. DFIRe notifies the users listed on the playbook and the members of the roles listed on it. Somebody named both ways hears once, and DFIRe skips deactivated accounts. The notification names the playbook and its due date, and links to it. A playbook with no owner, or one whose lists reach no active account, notifies nobody. The webhook still fires for it, which is how an unowned playbook still gets reported somewhere. See Webhooks → Playbook review reminders.
Scheduled Jobs
A read-only list of the background jobs DFIRe runs for itself. Each row gives the frequency, the last run and its result, and the next run. Nothing here is configurable. Use it to confirm that background work still runs, and look here first when something scheduled has not happened.
The list covers compliance timer checks, the daily playbook review check, audit log batching, license check-ins, Jira polling, retention processing and several cleanup jobs. Their frequencies range from every minute to daily.
Case codenames
A pool of single-use names for cases. When the pool holds names, the case creation dialog offers a button that draws one at random. DFIRe moves a name from the available list to the used list once a case takes it, so no name is handed out twice.
Enter names separated by commas or one per line. Duplicates are dropped.
Triage Flags
Colour-coded tags for evidence items, used to mark findings and warnings during triage. Each flag has a name, a colour and a description.
Ten flags ship by default. They cover what a triage pass found, and what the item needs afterwards.
- Findings: Evidence, No evidence, Malware, Illegal content
- Handling: Return, Do not return, Personal, Broken
- Device state: Reimage OS, OS Reimaged
Incident Categories
The classification offered on the case form, where the field is labelled ENISA Category. DFIRe ships the ENISA incident taxonomy: Abusive Content, Malicious Code, Information Gathering, Intrusion Attempts, Intrusions, Availability, Information Content Security, Fraud, Vulnerable, Other and Test.
Edit the list to match the taxonomy your reporting obligations use. The order set here is the order the case form offers.
Outcome Verdicts
The verdicts offered when a case is resolved. Four ship by default.
- True Positive: a confirmed incident
- False Positive: an alert that proved not to be malicious
- Benign Positive: real activity, but expected or authorized
- Indeterminate: the investigation could not settle the question