Playbooks

Default Playbooks

DFIRe ships with a set of pre-made playbooks covering common investigation and incident response scenarios. These are editable. Adjust them, copy them, or replace them entirely to match your organization's processes.

Creating a Playbook

1. Go to Settings → Playbooks
2. Click "New Playbook" to open the designer.
3. Name the playbook

   The name is what investigators pick from when creating a case, so make it say what the playbook is for.

4. Describe it and name its owners

   Say what the playbook covers and who keeps it current. See Description, author and owners.

5. Define actions and phases

   Actions are the tasks investigators will tick off during a case, grouped by incident phase. Each action has a description and an optional runbook attachment. A case created in investigation mode shows only the actions in the first phase, and the rest become available if it is escalated to an incident.

   Actions without a phase are collected in an Unassigned group at the end of the list. Deleting an incident phase puts its actions there, so they can be moved to another phase instead of going missing.

6. Add custom fields

   Define additional fields specific to this playbook. E.g., "Reporter Email" for a data breach playbook, or "Malware Family" for a malware analysis playbook.

7. Save the playbook

   New cases can now be created from this playbook. Existing cases can also be swapped onto it. See Swapping a playbook on an existing case.

Description, author and owners

The designer's details panel holds the record keeping that sits next to the name.

• Description. What the playbook covers and when to use it. The details panel shows it as it will read. Select Edit to write it in Markdown, up to 10,000 characters.
• Author. An attribution label of up to 255 characters. It is free text rather than a user account, so it can name a team, an outside author or the standard the procedure follows. A new playbook starts with the name of the signed-in user. Playbooks that arrive through a settings import without an author are labelled DFIRe Defaults.
• Created. When the playbook was written. Saving a new playbook stamps the current date. Set it back to the date the procedure really dates from, if that is earlier. DFIRe refuses a date more than a day ahead. Clear the field on a saved playbook and it has no creation date.
• Owner users and Owner roles. Who keeps this playbook current. List accounts, roles, or both. A user owns the playbook when they are listed under Owner users, or when they belong to a role listed under Owner roles. Listing somebody twice changes nothing. Review reminders go to everyone the two lists reach. A playbook can also have no owner at all.

A role listed as an owner owns the playbook whoever belongs to it. An empty role is still an owner, and the playbook list names it without further comment.

Deactivating a user account leaves the playbooks it owned in place. Where a playbook lists users, lists no role, and every listed user has been deactivated, the playbook list marks it Owners deactivated. Its in-app reminders go nowhere until an administrator lists an owner who is still active, while the Playbook Review Due event still fires.

The audit log records a change to the author label, the creation date or the owners. None of the three is part of the definition. Only the name, description, case fields and actions are, and only a change to one of those raises the playbook's revision number. Assigning owners to a shelf of reviewed playbooks therefore does not mark them all as changed.

Visual and JSON editors

The playbook designer has two editing modes, accessible via the Visual / JSON toggle at the top of the editor:

• Visual mode. Form-based editor for building playbooks step-by-step. Recommended for most edits.
• JSON mode. Raw JSON representation of the playbook. Useful for bulk edits, diffing, version-controlling playbook definitions, or generating playbook drafts with an LLM. Paste a JSON definition, switch back to visual mode to check it, then save.

Both modes round-trip through the same data structure. Iterate in the designer, flip to JSON to copy a definition elsewhere, and flip back without losing changes. JSON mode carries the description, author label, creation date and both owner lists along with the definition. It never shows the revision number or the review fields, which the server owns and refuses to accept from a payload.

Copying a playbook

The clone button in the playbook list opens the designer on a copy. The copy takes the description, the case fields and the actions of the original. Its name ends in (Copy), so rename it before you save.

Nothing else comes with it. The copy is written by whoever made it, created on the day it is saved, and carries no review history and no review date. It starts at revision 1, and reviewing the original does not review the copy.

Periodic review

A procedure written two years ago may no longer match the network it describes. Periodic review puts every playbook on a schedule, records who last read one through, and reminds its owners when the next reading is due.

A superuser switches it on under Settings → Playbook Policy and sets the period and the reminder days there. See Configuration → Playbook Policy. While the review period is zero, playbooks carry no due dates and no review can be recorded.

Recording a review

Open the playbook in the designer and read it through. The Review panel gives the last update, the last review and who recorded it, the due date and the current status. Click Mark reviewed, add a note of up to 4,000 characters if the decision needs one, and click Record review.

Recording a review needs the edit permission on playbooks, the same one that saves a change. When the button is unavailable, the panel says why. Periodic review is off, the JSON does not parse, or changes on screen are unsaved. A review certifies what is stored, so save first.

If someone else saves a change first, DFIRe refuses the review, reloads the definition and asks you to read it again. That is the point of the check. A review names the exact revision the reviewer saw.

What a review certifies

A review certifies the playbook's saved definition at one revision. That is its name, description, case fields and actions, with the author, owners and creation date as they stood. It does not certify the runbooks the actions point to, or the incident phases they are grouped by. Those are separate records with their own histories, and a change to one of them does not raise the playbook's revision.

Each review is evidence. It holds the reviewer's name, the server time, the revision, the note, and a SHA-256 digest of the definition. The digest identifies the reviewed content, so two reviews of the same text carry the same digest. It is a content identifier, not a signature.

Users with view permission on playbooks can open a visible playbook from Settings → Playbooks and read its definition and review history. Without edit rights, the designer is read-only in both Visual and JSON modes. Ownership restrictions still determine which playbooks the user can see and change.

Nobody edits or deletes a review. Recording a second review of the same revision is a fresh certification and adds a second entry. The Review history list under the panel shows the entries newest first. Reading it needs the view permission on playbooks, and nothing more. It needs neither access to the audit log nor permission to edit the playbook.

Deleting a playbook keeps its reviews. They are no longer reachable in the interface, and they remain in the database and in backups.

How the due date is worked out

The deadline is one review period after the anchor. DFIRe takes the anchor from the first of these that the playbook has:

1. the last review
2. the creation date
3. the time periodic review was switched on

A playbook is overdue from the deadline itself, not from the day after. It is due soon from the longest reminder day you configured. With reminders at 30 and 7 days, a playbook counts as due soon a month before its deadline.

The third anchor is what gives an installation's existing playbooks a first deadline. DFIRe stamps it every time periodic review is switched on, and clears it when review is switched off. An undated playbook put back on a schedule counts its first period from the day it went back on. A playbook that carries a review or a creation date keeps counting from that, so it can go straight back to overdue. Changing the period while review is on leaves the anchor alone: every deadline moves, the anchor does not. A shorter period can then make playbooks overdue at once. Setting an old creation date on a playbook that has never been reviewed does the same.

Never reviewed and changed since review

A playbook has one standing against its deadline, and up to one other fact worth knowing.

• Overdue or Due soon. Where the playbook stands against its deadline. A playbook inside its period and past neither carries Reviewed on schedule instead.
• Never reviewed. No review has ever been recorded. A playbook can be well inside its first period and still carry this.
• Changed since review. The definition was edited after the last review. A playbook edited yesterday is still current by date and needs reading again.

The last two replace Reviewed on schedule, which would claim the opposite beside them. Either one stands next to Overdue or Due soon, which it does not contradict.

Review status is advisory. An overdue playbook stays fully usable. Investigators create cases from it, cases already running carry on, and anyone with the permission can still edit it or swap a case onto it. Nothing in DFIRe blocks work because a review is late.

Where review status is shown

Review status is a housekeeping signal for administrators, so it appears in System Settings and nowhere else. Settings → Playbooks carries owner, last reviewed and review due columns. Review due counts the days to the deadline, beside a status icon. The count runs on past the deadline as a negative number, so a playbook two weeks late reads -14 days, and today on the deadline itself.

The icon shows the first of these that is true:

• A red cross. Overdue. The deadline has passed.
• An amber question mark. Changed since review. The definition was edited afterwards, so nobody has read the current version through.
• An amber clock. Due soon. The deadline is close.
• A green tick. Nothing to do. A playbook nobody has reviewed yet carries this as well: a new playbook counts as correct until its first deadline, and writing one is not a review.

Hover the icon for the whole standing in a sentence, such as Overdue by 14 days, changed since review. The owner column shows the first owner and a count of the rest, with owner roles on a line of their own. Hover a line to read the whole list.

A cell with no value shows a dash. One filter narrows the list to a single kind of gap: Without an active owner, Never reviewed or Overdue. The playbook designer's Review panel states the same facts, and it is where the review badges appear.

Case creation, the playbook picker on a case, the dashboard and every other investigator surface show nothing about review at all.

Who can manage a playbook

Managing a playbook means changing it, reviewing it, deleting it or naming its owners. All of that happens under Settings → Playbooks and in the designer. Using a playbook is separate: picking one when creating a case, and swapping a case onto another, are case work and need the whole library.

Settings → Playbook Policy → Playbook management access control holds one setting, Restrict playbook management to playbook owners. It is off unless a superuser turns it on, and it works whether or not periodic review is in use.

The two kinds of owner

Every playbook carries a list of owner users and a list of owner roles. Either list can be empty, and the designer sets both. A user owns the playbook when the owner-user list names them, or when they belong to a listed role. Listing somebody both ways changes nothing. See Description, author and owners.

While the restriction is on

Only a playbook's owners manage it. They change it, review it and delete it, and nobody else does, whatever their role grants. Naming owners stays with superusers, so an owner can neither hand a playbook on nor clear its owners.

Settings → Playbooks lists what you manage, which is now the playbooks you own. Opening one you do not own says that you cannot edit it.

Anyone with case rights still uses every playbook. Creating a case offers the whole library, and so does swapping a case onto another playbook, whoever owns each one.

A user without case rights reaches nothing they do not own. Such a playbook is absent everywhere, and a direct link to it reports that the playbook could not be loaded.

A new playbook belongs to whoever creates it, and a copy to whoever copied it. DFIRe refuses a new playbook that names anyone else as its owner.

Superusers are exempt throughout. Two cases need one before anybody else can work: a playbook with no owner, and one whose owners reach no active account. List an active owner, or a role somebody belongs to, and the delegated editor can take it from there.

While the restriction is off

Nothing beyond the ordinary role permissions applies. Whoever holds the playbook edit permission manages every playbook, and ownership decides only where review reminders go and what the owner column reports.

A role that only maintains playbooks

Turning the setting on lets you hand one person their own playbooks without handing them anything else. Under Settings → Access Roles, add a role and grant it create, edit and view on playbooks. Grant nothing else. Its holder writes and maintains their own playbooks and reads their review history. DFIRe hides every other playbook from them, and they get no access to cases, settings or user accounts.

DFIRe does not ship this role. Build it when a customer needs one, from the three permissions named here. See Users and roles → Editing roles.

Playbooks in a settings export

A settings export carries each playbook's definition, description, author label and creation date. It also carries the usernames of its owners and the names of its owner roles. See Configuration → Data portability.

On import, DFIRe matches each username against the active accounts on this installation, and each role name against the roles it has. DFIRe drops a name it cannot match and warns about that name on its own. The rest of the list still applies, and the import itself goes through. Names are the only accepted form, because a numeric identifier from another installation points at a different person or role here.

Review history, review dates and the last-updated date never travel. They record what happened on one installation, and no file can restate that. An import that changes a definition raises its revision, which then shows as Changed since review. An import that changes nothing leaves the revision and the review alone.

Swapping a playbook on an existing case

Cases are not locked to the playbook they were created from. Investigations change direction. What looked like a phishing incident can turn out to be a broader compromise, and you can swap the case onto a different playbook without losing progress.

Only the case's lead investigator, or a role holding core.edit_all_cases, can swap the playbook. Other investigators on the case can work it, but not change its playbook.

How to swap

1. Open the case and go to Case → Change Playbook.
2. Select the new playbook.
3. Choose a merge mode:
   • Merge (default): adds the new playbook's actions alongside the existing ones. Existing action progress (done, started, skipped) is preserved.
   • Replace: replaces unstarted actions with the new playbook's actions. Completed and skipped actions are kept for audit; started actions are preserved.
4. Confirm. A PLAYBOOK_CHANGED timeline event is written so the switch is visible in the case history.

What happens to the custom fields

Custom fields behave the same in either mode. A field that holds a value stays on the case, even when the new playbook does not define it. The case's Attributes panel still offers the field, so you can correct the value or take the field off the case. DFIRe drops a field nobody filled in.

Custom Fields

Custom fields capture playbook-specific information on each case. Available field types:

Field Type	Description
Text	Single-line text input
Number	Numeric values
Yes/No	A checkbox, stored as true or false
Date	Date picker

There is no dropdown field type. Where a field should hold one of a fixed set of values, name the options in the label, as the shipped playbooks do with fields like Status (Active Threat, Contained, Under Investigation).

Field Properties

• Label: Display name
• Required: Must be filled when creating a case. Yes/No fields are never required, since an unticked box is a valid answer.

Actions and seeding

Actions defined on a playbook act as a template. When a case is created from the playbook, DFIRe copies the action list onto the new case. From that point on, the case's actions and the playbook's actions are independent. Editing a playbook does not retroactively change existing cases. Per-case action edits happen on the case itself (Actions tab), not on the playbook.

This keeps historical cases stable while letting you evolve playbooks over time.

Best Practices

• Start from a default playbook and customize rather than building from scratch.
• Don't proliferate playbooks. Use custom fields to capture variation instead of cloning.
• Keep action phrasing consistent across playbooks so team members build muscle memory.
• Version-control playbook JSON exports if multiple people edit playbooks. Useful for rollback.
• Make the playbook name say when to use it, so responders pick the right one under pressure.