07.03 The Incident Management Extra

Requires: Incident Management Extra

The entire incident-management workflow lives in the Extra. Core SimpleRisk has no native incident recording; the /incidents/ URLs in Core redirect to either the active Extra or to /admin/incidentmanagement.php for activation. See What is Incident Response? for the discipline overview and Recording an Incident for the per-incident recording walk-through.

Why this matters

The Incident Management Extra is what turns SimpleRisk into a working incident-response platform. Activation creates 35+ tables and 15 granular permissions, surfaces a sub-menu structured around NIST SP 800-61's four-phase IR lifecycle, and brings playbooks, evidence collection, lessons-learned tracking, and event-driven notifications. Without the Extra, the program has no incident-response surface in SimpleRisk at all.

The other reason this matters: the Extra was deliberately built around NIST 800-61. The sidebar entries map directly to the standard's phases (Preparation, Identification = Detection & Analysis, Response = Containment + Eradication + Recovery as tabs, Lessons Learned = Post-Incident Activity). Programs that follow NIST 800-61 will find the Extra's vocabulary familiar; programs running other IR frameworks (NIST CSF's Detect/Respond/Recover, ISO 27001's A.5.24–A.5.28) can map their own vocabulary onto the Extra's phases without much friction because the underlying activities are the same.

The third thing worth knowing: the Extra is opinionated about playbooks. Containment, Eradication, and Recovery actions aren't free-text fields the responder fills in during the response — they're checkboxes from a pre-defined playbook the program built before the incident occurred. The Preparation phase exists in part to author those playbooks. Programs without playbooks find themselves authoring during the response (which works, sort of, but loses the rehearsed-process value) or skipping the action-tracking entirely.

Before you start

Have these in hand before working with the Extra:

Admin access to activate the Extra. Activation is a one-time admin action via /admin/incidentmanagement.php; it creates the database schema and registers the permissions. Subsequent operational work doesn't need admin.
The right permissions for the actions you'll take. The Extra has 15 granular permissions:
Allow Access to Incident Management "Incidents" Menu (im_incidents) — base view access.
Able to Submit New Incidents (im_submit_incidents) — record new incidents.
Able to Modify Existing Incidents (im_edit_incidents) — edit incident details.
Able to Delete Incidents (im_delete_incidents) — remove incidents.
Able to Select Incident Preparation Items (im_select_preparation) — mark preparation items complete.
Able to Select Incident Playbook (im_edit_playbook) — assign or change a playbook for an incident.
Able to Select Incident Response Items (im_select_response) — check off action steps in Containment/Eradication/Recovery.
Able to Add Incident Evidence (im_add_evidence) and Able to Delete Incident Evidence (im_delete_evidence) — manage evidence files.
Able to Add Incident Notes (im_add_notes) and Able to Delete Incident Notes (im_delete_notes) — manage notes.
Able to Add Lessons Learned to Incident (im_add_lessons) and Able to Dismiss Lessons Learned from Incident (im_dismiss_lessons) — manage lessons.
Allow Access to Incident Management "Reporting" Menu (im_reporting) — view reports.
Allow Access to Incident Management "Configure" Menu (im_configure) — configure playbooks, lookups, notifications.
(See Permission Reference.)
At least one playbook for each kind of incident the program expects to respond to. Common starters: Ransomware Response, Data Exposure Response, Account Compromise Response, DDoS Response. Authoring playbooks before the first real incident is the work the Preparation phase exists to do.
Configured notification routing. The incident_management_notification_setting controls who gets notified about which event types (12 events: new, status_changed, summary_changed, playbook_changed, details_changed, all_containment_steps_completed, all_eradication_steps_completed, all_recovery_steps_completed, evidence_attached, notes_added, lesson_learned_added). Each event can route to the reporter, the owner, additional stakeholders, and team members. Configure this before activating routing-dependent integrations; otherwise, incidents land silently.

Step-by-step

1. Activate the Extra

Sidebar: Configure → Extras → Incident Management Extra, then Activate. The activation:

Sets the incident_management_extra_enabled configuration setting to true.
Creates the 35+ Extra-specific tables (see the data-model summary at the end of this article).
Registers the 15 incident-management permissions.
Adds the Incident Management sidebar menu with sub-items: Incidents → Preparation, Identification, Response (Incident Details), Lessons Learned, Closed, plus Configure and Reporting.

Once activated, the Extra's surface is operational. The activation is reversible (deactivate from the same page), but deactivation drops the Extra-specific tables and the data they hold — back up before deactivating.

2. Set up the Preparation phase

Sidebar: Incident Management → Incidents → Preparation opens the preparation page. The page surfaces preparation items the program tracks (playbook authoring, responder training, communication-channel setup, jump kits, escalation lists). The configurable items are managed in Configure → Incident Management; the Preparation page is where you mark them complete.

Preparation isn't an incident-recording surface — it's the program-readiness scoreboard. A program with all preparation items checked off is ready; a program with most items unchecked is improvising when the next incident arrives.

The Able to Select Incident Preparation Items permission gates the marking-complete action. Without it, the page is read-only.

3. Author playbooks

Sidebar: Incident Management → Configure opens the configuration page, including the playbook authoring surface. A playbook has a name, a description, and a list of categorized actions for each of the three response phases (Containment, Eradication, Recovery).

Action authoring is per-phase: you add Containment actions, Eradication actions, and Recovery actions separately, optionally grouped into categories (the seeded categories are reasonable defaults; customize for your operation). Each action is a single line of instruction the responder will check off during the actual response.

Examples of well-shaped actions:

Containment: "Disable the compromised user account in Active Directory." (Specific, verifiable, single-step.)
Eradication: "Run a full anti-malware scan against all systems flagged in the affected-asset list." (Specific population, specific action.)
Recovery: "Restore the affected database from the most recent clean backup; verify the backup's checksum before promoting." (Procedure with a verification step.)

Vague actions ("Improve security") aren't useful; they can't be checked off meaningfully and don't help the responder know what to do.

The v2 API for playbook authoring is POST /api/v2/im/incident/playbook/add, POST /api/v2/im/incident/playbook/update, POST /api/v2/im/incident/playbook/action/add, POST /api/v2/im/incident/playbook/action/update, POST /api/v2/im/incident/playbook/action/move/up, and POST /api/v2/im/incident/playbook/action/move/down. Useful for scripted import of playbooks from external sources.

4. Record new incidents through Identification

The Identification phase is where new incidents enter the system. The full mechanics are in Recording an Incident. Briefly: Submit An Incident at /incidents/index.php?menu=identification opens the five-tab form (Detection, Assignment, Prioritization, Location, Associations); save lands the incident in the Response queue with status=1 (Response/New).

5. Operate the Response phase

Sidebar: Incident Management → Incidents → Response lists incidents in active response. Click an incident to open /incidents/index.php?incident_id=X, the per-incident detail view. The page has tabs for the incident metadata plus the three response sub-phases:

Containment — actions to stop the spread.
Eradication — actions to remove the cause.
Recovery — actions to restore normal operations.

Each tab requires a playbook to be assigned (the Able to Select Incident Playbook permission gates the assignment). Once assigned, the tab shows the playbook's actions for that phase as a checklist; the Able to Select Incident Response Items permission gates the check-off.

Status transitions happen as the team works through the phases:

Status 1 (Response/New): incident recorded, no phase started.
Status 2 (Response/Containment): containment phase active.
Status 3 (Response/Eradication): eradication phase active.
Status 4 (Response/Recovery): recovery phase active.
Status 5–11 (Closed): closed for various reasons.

The Extra fires a notification when all actions in a phase are completed (the all_containment_steps_completed, all_eradication_steps_completed, all_recovery_steps_completed events). This is the operational signal that the team can advance to the next phase.

The status update API endpoint is POST /api/v2/im/incident/status/update.

6. Attach evidence and notes

Throughout the response, the team accumulates evidence (screenshots, log exports, malware samples, scanner output) and notes (timeline entries, decisions made, actions outside the playbook). Both attach to the incident:

Evidence files land in incident_management_incident_evidence. The Able to Add Incident Evidence permission gates the upload; Able to Delete Incident Evidence gates removal. Each evidence file fires the evidence_attached notification event.
Notes land in incident_management_incident_notes. The Able to Add Incident Notes permission gates creation; Able to Delete Incident Notes gates removal. Notes fire the notes_added notification event.

Both surfaces are open-ended; for a long-running incident, expect many evidence files and many notes. The evidence file naming convention matters here for the same reason it does for compliance evidence — files named for the incident and the action they support are findable later (incident-2026-Q3-A_containment-step-3_disabled-account-screenshot.png); files named Document.pdf aren't.

7. Move through Lessons Learned (Post-Incident Activity)

Sidebar: Incident Management → Incidents → Lessons Learned opens the post-incident review page. The page shows incidents that have been moved to a Closed status; for each, the program can attach lessons (from the global lessons library in incident_management_lessons_learned) and finally dismiss the incident from the queue.

The Extra's Lessons Learned surface is more list-shaped than meeting-shaped — it captures which lessons attach to which incidents, but doesn't ship a structured "review meeting agenda" template. Programs that want a formal review meeting layer that on through their own conventions (a recurring calendar event with a structured agenda, the meeting outputs captured as lessons attached to the incident).

The Able to Add Lessons Learned to Incident permission gates attachment; Able to Dismiss Lessons Learned from Incident gates the dismiss-from-queue action. Both fire the lesson_learned_added notification event when a lesson lands.

8. Close the incident

Closure happens by setting the status to one of values 5–11. The seeded closure reasons typically include "Resolved," "False Positive," "Duplicate," and a few others; customize via the configuration page. Closed incidents move to the Closed list at /incidents/index.php?menu=closed and stay there for historical reference and reporting.

A closed incident can still have lessons attached and evidence reviewed — closure doesn't lock the record, it just marks it as no longer in active response.

9. Read the Reporting surface

Sidebar: Incident Management → Reporting opens the incident-reporting page (gated by Allow Access to Incident Management "Reporting" Menu). The reporting surface is what produces the longitudinal incident metrics — incident volume over time, mean time to closure, incident counts by attack vector, incident counts by source, etc.

The reports read from the same underlying tables (incident_management_incidents and the per-phase action tables); the Reporting page just presents the data in dashboard-friendly views.

10. Configure notifications

Sidebar: Incident Management → Configure also exposes the notification configuration. For each of the 12 event types, you pick the recipient roles (reporter, owner, additional stakeholders, team) that should receive the notification. The configuration writes to incident_management_notification_setting as JSON.

Default routing is conservative — most events notify the owner only. For programs running an active SOC, broaden the routing on new and status_changed events so the on-call rotation gets the page; for programs with executive-visibility requirements, route new events for high-impact incidents to a leadership group.

Common pitfalls

A handful of patterns recur with the Extra.

Activating without authoring playbooks. Activation is fast; authoring playbooks is slow. A program that activates the Extra and tries to use it on the first real incident with no playbooks ready discovers the Containment/Eradication/Recovery tabs are empty placeholders. Author at least one playbook before relying on the Extra in production; the standard set (ransomware, data exposure, account compromise, DDoS) covers most starting cases.
Skipping the Preparation phase. The Preparation page surfaces program-readiness items that drive whether the response will go well. A program that never visits the page never marks anything complete and never knows where the readiness gaps are. Review the page quarterly as part of the program-management cadence.
Vague playbook actions. "Investigate the incident" isn't a playbook action; it's a category. Playbook actions should be specific enough that a responder can do them without further instruction and verify they're done. The granularity matters during the response; vague actions get checked off without the underlying work happening.
Recording every alert as an incident. Discussed in Recording an Incident: the Event vs Incident occurrence type is the distinction the Extra uses to keep the register meaningful. Treat every SOC alert as an Incident and the register is unreadable within a quarter.
Notification routing left at default for an active program. Default routing notifies only the owner, which works for one-person responses and breaks for team responses. For programs with on-call rotations or executive-visibility requirements, configure the routing deliberately at activation time.
Lessons Learned skipped because it's "not a real meeting." The Lessons Learned page is where the post-incident learning gets captured for the next incident. Programs that skip this step run through the same incidents repeatedly without improving the playbooks. Block off review time per incident, even if the lessons capture is brief.
Evidence files dumped without naming convention. The evidence-attachment surface accepts any file. Programs that dump files named Screenshot.png and Capture.pdf produce an evidence trail nobody can navigate during a follow-up audit. Adopt a naming convention; the discipline matters more for incidents than for routine compliance evidence because incident-evidence reviews happen under pressure.
Deactivating the Extra without backing up first. Deactivation drops the 35+ Extra-specific tables and the data they hold — incidents, playbooks, evidence, notes, lessons all gone. Take a database backup before deactivating; the data isn't recoverable from the Extra after deactivation.
Treating the Extra as the only place incident data lives. Incidents touch many systems — the SIEM, the ticketing tool, the communications platform, the legal-and-PR tracker for major breaches. The Extra is the GRC-side record; it's not (and shouldn't try to be) the operational tool for the actual response. Pair it with the operational tools through the v2 API; let each system hold the data it's good at holding.
Ignoring the bidirectional risk linkage. Incidents link to risks via incident_management_incident_to_risks. Programs that don't use the linkage produce incident records that don't connect back to the risk register and risk records that don't show their materialization history. The bidirectional integration is what makes the program coherent — see From Incident to Risk and Back.