07.02 Recording an Incident

Why this matters

Recording an incident is the operational moment that transforms an event the team is reacting to into a tracked artifact the program can manage, share, and learn from. Before the record exists, the response is a Slack thread and somebody's notebook; after, it's a structured entry with a status, a phase, an owner, attached evidence, and a timeline that can be defended in front of an auditor or a board member who asks "what happened?"

The honest answer to "how do I record an incident in Core SimpleRisk?" is: you can't. The entire incident-management workflow is gated to the Incident Management Extra. The /incidents/ URLs in Core are stubs that redirect to either the Extra (if active) or to /admin/incidentmanagement.php to activate it. There's no Core-side incident table, no Core-side recording form, no Core-side status field. This is different from vulnerability management (where Core lets you track vulnerabilities-as-risks via convention) — for incidents, Core offers no fallback at all.

That said, the workflow once the Extra is active is well-defined. This article walks the recording step (NIST 800-61's Identification phase, branded "Identification" in the UI). The downstream response work (Containment, Eradication, Recovery, Lessons Learned) is in The Incident Management Extra. The conceptual relationship between incidents and the risk register is in From Incident to Risk and Back.

Before you start

Have these in hand before recording an incident:

The Incident Management Extra activated. Sidebar: Configure → Extras → Incident Management Extra, then Activate. (Activation is admin-only and creates 35+ tables for the Extra's data model; once active, the Incident Management sidebar menu becomes visible.)
The Allow Access to Incident Management "Incidents" Menu permission (im_incidents) for any view of the incidents area, plus Able to Submit New Incidents (im_submit_incidents) for the recording action specifically. The two are gated separately so a viewer-only role exists. (See Permission Reference.)
Configured lookup values that the form will reference: occurrence types, attack vectors, sources, source types, regions/countries/cities, functional/information impact scoring scales, and at least one playbook. Most installs ship with seeded values; if your install has been customized, confirm the lookups exist before recording — incomplete dropdowns make the form hard to use.
Known facts about the incident. A summary, the detection date, the start date (if different), the affected systems, the suspected attack vector, the reporter, and a candidate owner. Recording an incident with mostly-blank fields is fine for the first capture (the Extra accepts updates), but the more facts you have at recording time, the better the downstream response goes.
For Core-only programs: an alternative tracking mechanism. Core has nothing to record into; if the program needs to track an active incident now and can't activate the Extra in time, use the standard risk register with a Risk Source value of "Incident" or similar, tag the risk incident-2026-Q3-A, and treat it as a temporary record until the Extra is available. Migrate the data manually to a real incident record once the Extra is up. This isn't an ideal pattern but it preserves continuity when the Extra installation is deferred.

Step-by-step

1. Open the Identification page

Sidebar: Incident Management → Incidents → Identification opens /incidents/index.php?menu=identification. The page shows the list of incidents currently in the Identification phase plus the Submit An Incident button at the top.

If you don't see the Incident Management sub-menu in the sidebar, the Extra isn't activated. If you see the menu but the Submit An Incident button doesn't appear, the Able to Submit New Incidents permission isn't on your account.

2. Click Submit An Incident

Click Submit An Incident to open the recording form. The form is organized into five tabs that group the fields by purpose:

Detection — what happened, when, and how it surfaced.
Assignment — who's involved, on the response side and the stakeholder side.
Prioritization — the impact scoring that drives the incident's priority.
Location — where the incident is happening (region, country, city), useful for global organizations.
Associations — what the incident links to (other incidents, risks, assets, tags).

The tabs aren't strictly sequential (you can fill them in any order) but the workflow tends to follow Detection → Assignment → Prioritization → Location → Associations because that's roughly the order the facts become known during the early response.

3. Fill in the Detection tab

The Detection tab captures what happened and how it was identified:

Summary — a short headline (max 300 characters). Treat it like the Subject field on a risk: this is what scrolling readers see, so be specific. "Phishing campaign targeting finance team — credential harvesting via fake AWS console" beats "Phishing."
Details — the longer description. What was observed, when, by whom, what's known about the scope so far. This grows over the life of the incident; the initial entry can be brief.
Occurrence Type — a dropdown distinguishing Incident from Event (and possibly other configured values). The distinction matters operationally: events are noteworthy occurrences that don't yet warrant a response, incidents are occurrences the team is responding to. Be deliberate; defaulting everything to Incident produces a noisy register.
Direction — a dropdown classifying the incident as inbound (external attacker), outbound (internal-to-external), internal (insider or lateral), etc.
Attack Vector — the method or channel involved (phishing, web exploit, supply chain, physical, etc.).
Source — the threat actor or source category (organized crime, nation-state, insider, accidental, unknown). For events without an attribution, leave as "Unknown" rather than guessing.

4. Fill in the Assignment tab

The Assignment tab captures the people:

Reporter — single-user picker. Who reported the incident (the person who first surfaced it, often not the responder).
Owner — single-user picker. The single accountable owner for the response. Defaults can be set in admin configuration.
Additional Stakeholders — multi-user picker. People who should be in the loop but aren't responsible for the response (managers, related teams, communications staff).
Team — multi-team picker. The team(s) involved in the response.

The owner is load-bearing — notification routing, status-change emails, and the responsibility for moving the incident through phases all flow to the owner. Don't leave it blank.

5. Fill in the Prioritization tab

The Prioritization tab captures impact scoring through three dropdowns, each with its own scoring helper:

Functional Impact — how the incident affects business operations (none, low, medium, high). The seeded values map to numeric scores that drive the overall incident severity.
Information Impact — how the incident affects data confidentiality/integrity/availability (none, privacy breach, integrity loss, etc.).
Recovery — how recoverable the incident is (regular, supplemented, extended, not recoverable). This shapes the Recovery-phase planning.

Each field is configurable in admin (Configure → Incident Management → Functional/Information/Recovery scoring); the seeded values are based on NIST 800-61's impact-categorization guidance.

6. Fill in the Location tab

For global organizations, the Location tab lets you scope the incident geographically:

Region — multi-select.
Country — multi-select.
City — multi-select.

For single-location organizations, leave these blank or set to your one site. The tab exists because incidents in multinationals frequently cross jurisdictional lines (regulatory reporting requirements, breach notification laws) and the geography drives those decisions.

7. Fill in the Associations tab

The Associations tab is where the incident links to the rest of SimpleRisk:

Related Incidents — multi-select. Other incidents in the database related to this one (a phishing campaign hitting multiple teams might warrant separate incidents linked together).
Related Risks — multi-select. Risks in the standard register that this incident relates to (the materializing risk, the risk newly surfaced by the incident). This linkage is what the bidirectional integration in From Incident to Risk and Back reads.
Affected Assets — multi-select assets and asset groups, using the same widget as the Submit Risk form. The asset linkage feeds the asset-side incident reporting.
Source Tags and Destination Tags — free-text tags categorizing the incident's source and target. Useful for cross-cutting reporting later.

8. Save

Click Save. The Extra writes the incident to incident_management_incidents with a status of 1 (Response/New) — meaning the incident is now recorded and ready to move into the Containment phase of the Response workflow. The reporter, owner, additional stakeholders, and team members all receive notifications based on the configured incident_management_notification_setting (the new event type).

The incident appears in the Identification list and (because status=1) also in the Response list at /incidents/index.php?menu=response (or in Closed once it's been moved to a closed status). Click the incident to open its detail view at /incidents/index.php?incident_id=X and continue with the response work — see The Incident Management Extra.

9. Programmatic recording via the v2 API

For automation (alerts from a SIEM that should auto-create incidents, integrations with ticketing systems, scripted bulk recording) the v2 API exposes the operation:

POST /api/v2/im/incident/details/update — create or update incident details (the Detection-tab fields).
POST /api/v2/im/incident/summary/update — update the summary specifically.
POST /api/v2/im/incident/status/update — change phase/status (also used to advance through Containment → Eradication → Recovery → Closed).
GET /api/v2/im/incident/get/all — list all incidents.
POST /api/v2/im/incident/get/incident/datatable — paginated list (DataTables-compatible).

A typical SIEM-integration pattern is: alert fires in the SIEM, a webhook posts to POST /api/v2/im/incident/details/update with the alert content as the Summary and Details, the resulting incident lands in Identification, the on-call responder picks it up. Pair with the notification settings so the right people get pinged at creation time.

Common pitfalls

A handful of patterns recur with incident recording.

Recording every alert as an incident. The single biggest failure pattern. A SIEM that fires hundreds of alerts per day, integrated with the Extra to auto-create incidents per alert, produces an incident register where 95% of the entries are routine alerts the SOC closed without doing anything. Use the Event occurrence type (or a SIEM-side filter) for the routine alerts; reserve Incident for the ones the team is actually responding to.
Blank Owner field. A new incident with no Owner gets nobody's attention. The notification routing has nowhere to send the "new incident" alert; the dashboards show the incident as unassigned indefinitely; the response stalls before it starts. Always assign an owner at recording time, even if it's the on-call rotation account that the actual responder will reassign from.
Vague Summary. "Server issue" tells future readers nothing. The Summary appears on every dashboard, in every notification, and in every audit-trail entry — it's the field that does the most work over the life of the incident. Spend the extra thirty seconds at recording time; "Production database connection-pool exhaustion causing 500-errors on /api/v2/risks endpoint" is much more useful than "Server issue."
Confusing Reporter and Owner. The Reporter is the person who raised the incident (often a user who saw something weird, or the SIEM if auto-recorded); the Owner is the person responsible for the response (typically a security engineer or SOC analyst). Conflating them produces an incident where the reporter is held accountable for the response work, which they didn't sign up for.
Skipping the Prioritization tab. A new incident with no Functional Impact, Information Impact, or Recovery scoring lands in the register without an inferred severity. The dashboards can't surface it as high-priority because there's no priority signal. Even rough scoring at recording time (everything as "Medium" if you don't know yet) is better than blank.
Linking to no risks at recording time. The risk-incident link is what makes the bidirectional integration work. An incident with no risk link is a closed-system incident that doesn't connect to the program's broader risk picture. At recording time, look for related risks already in the register and link them; if no related risk exists, that's a finding for the post-incident review (the program had no record of this exposure before the incident materialized).
Treating recording as the end. Recording is the start of the workflow, not the end. A program that records incidents diligently but doesn't move them through the response phases ends up with a register full of "New" incidents that never get worked. The Identification phase is the front door; the response work is what happens inside the building.
Auto-recording without notification routing. Setting up SIEM-driven auto-creation without configuring the incident_management_notification_setting produces incidents that arrive in the database and notify nobody. The on-call team finds out at the morning standup. Configure notification routing for the new event type before turning on auto-create.