Security Incident Response Management

This is the single largest domain and the operational heart of the product. It covers everything that happens to a security incident after it exists: how analysts work it, how it is routed, how it is prioritized, how its lifecycle is governed, and how major incidents are coordinated.

The security incident lifecycle and state model

A security incident lives on the sn_si_incident table, which extends the platform Task table. The default lifecycle moves a record through a set of states that mirror the NIST incident-handling phases: Draft → Analysis → Contain → Eradicate → Recover → Review → Closed. Each state represents a phase of work, and the product is designed so that the response process, response tasks, and playbook activities map onto these states. Understanding the state progression is foundational — many exam questions hinge on which activities belong in which phase and on the fact that the state model is configurable but ships with this NIST-aligned default.

A security incident is distinct from an ITSM incident. They live on different tables, are worked by different roles, and follow different processes, even though both extend Task and both can reference the same CMDB configuration items. Do not confuse the incident table (ITSM) with sn_si_incident (SIR).

Roles

SIR ships a layered role model. The most commonly tested roles are:

• sn_si.analyst — works security incidents day to day.
• sn_si.admin — full administrative control of the SIR application, including configuration.
• sn_si.manager — oversight, reporting, and management functions.
• sn_si.basic — baseline access required by anyone who touches SIR data.
• sn_si.read_all / sn_si.write_all — broad read or write access across security incidents.

A key design principle: security incident data is restricted by default. Unlike an open ITSM incident, only users with the appropriate SIR roles can see security incident records. This data-segregation model is a frequent exam theme — security incidents are not visible to general ITIL users.

Assignment and escalation

Security incidents can be assigned manually, by assignment rules, or automatically based on category and other attributes. The product supports assignment lookup rules that route incidents to the correct assignment group based on conditions such as category, business service, or location. When a major incident is declared or an SLA is at risk, escalation can be driven by SLA workflows, flow automation, or manual promotion to a major security incident.

Security tags

Security tags classify and mark security incidents (and related records) so that handling, visibility, and downstream automation behave correctly. Tags can drive who can see a record and how it is treated. The Traffic Light Protocol (TLP) is the canonical example: TLP markings (RED, AMBER, GREEN, WHITE/CLEAR) communicate how broadly information may be shared. Security tags are central to information-handling governance inside SecOps and tie into the data-restriction model. (VERIFY) the exact shipped tag set and TLP labels for your release.

Service Level Agreements (SLAs)

SIR uses the platform SLA engine, applied to security incidents through SLA definitions with conditions, schedules, and stages (in progress, paused, breached). Common SLA targets include time-to-acknowledge, time-to-respond, and time-to-resolve. SLAs can be tied to priority, which on a security incident is derived from criticality/impact and the risk/severity calculation rather than the ITSM urgency-times-impact matrix alone. Understand that SLA attainment is one of the primary management KPIs surfaced on SIR dashboards.

Response process and response tasks

Work on a security incident is decomposed into response tasks (sn_si_task), which are child Task records that let analysts and other teams perform discrete units of work (for example, "block IP at firewall," "reimage host," "reset credentials"). Response tasks can be assigned to different groups, run in parallel, and roll their status back up to the parent incident. The response process is the structured set of activities — guided by playbooks, runbooks, and knowledge — that an analyst follows through the lifecycle phases.

Playbooks (Process / Flow-based)

Modern SIR ships playbooks built on the Now Platform's Process Automation / Playbook experience and powered by Flow Designer. A playbook presents the analyst with a guided, stage-based set of activities aligned to the incident lifecycle. The flagship example is the automated phishing playbook, which orchestrates email parsing, observable extraction, enrichment, containment, and closure. Playbooks combine automated flow actions with manual analyst tasks, giving repeatable, standardized response. (VERIFY) which playbooks ship activated by default in your release, as the default-activation set has changed across releases.

Runbooks and knowledge

Runbooks and knowledge articles provide analysts with documented procedures and reference material directly in the incident workspace. Knowledge integration lets the right article surface in context so analysts follow approved, consistent procedures. Runbooks differ from playbooks: a runbook is reference documentation/procedure, whereas a playbook is an executable, stage-driven workflow.

Major Security Incident Management (MSIM)

When an incident is severe enough, it can be promoted to a major security incident. MSIM provides coordinated, war-room-style handling: a dedicated workspace, a trusted set of responders, communication management, and tighter access control. A major security incident can have child security incidents that roll their MITRE ATT&CK information and status up to the parent. MSIM is a heavily tested management topic — know that it exists, what it adds (coordination, restricted membership, communications), and that it is a promotion/declaration of an existing incident.

Workspaces

Analysts increasingly work in the Security Incident Response workspace (a Configurable/Agent Workspace built on UI Builder / Workspace experience) rather than classic forms. The workspace consolidates the incident, related observables, response tasks, playbooks, and timeline into a single analyst view. (VERIFY) the exact workspace name and capabilities for your release.

---