Security Incident Response Management
About 30% of the CIS-SIR exam — see all 7 domains.
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: underlying role for basic security access; can create and update security incidents, requests, and tasks.
- sn_si.read: read-only access to security incidents.
- sn_si.ciso: views the CISO dashboard.
- sn_si.integration_user: lets external tools create and update security incident records.
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.
Sample questions from this domain
Three of the 90 in this domain, with the reasoning. The full set is in the question bank.
What is the purpose of automated assignment in Security Incident Response?
- A. To route new security incidents to the appropriate group or analyst based on defined rules ✓
- B. To set the risk score of new security incidents from the configured risk score weights
- C. To move a stalled security incident to a user-defined escalation group when its SLA breaches
- D. To apply security tags to new security incidents that match the active security tag rules
Why: Automated assignment routes new security incidents (and response tasks) to the appropriate group or analyst based on defined rules or criteria, such as the auto-assignment options for skills, location, time zone, or group coverage area set on the SIR Administration Configuration screen, which improves response speed and consistency. The risk score comes from risk score weights and calculators, not from assignment. Moving an incident to a user-defined escalation group is what the manual Escalate button does, and time-based escalation needs separately configured logic. Security tags are applied by security tag rules, which are a classification feature, not routing.
Which feature allows a security incident to be automatically reassigned or escalated when it remains unaddressed beyond a defined threshold?
- A. Escalation rules / escalation logic ✓
- B. The manual Escalate UI action
- C. Security incident calculators
- D. Auto-assignment weight properties
Why: Time-based escalation is configured logic, such as On-Call Scheduling escalation rules and policies or an SLA-driven flow, that escalates or reassigns an incident left unaddressed past a threshold. The SIR Escalate button itself is a manual action that needs a user-defined escalation group, so it does not fire when a threshold passes. Security incident calculators evaluate conditions to set fields such as severity and priority; they do not watch elapsed time. The auto-assignment weight properties only rank analysts when a security incident or response task is first auto-assigned.
What is the primary purpose of a security tag (security label) on a security incident?
- A. To classify or mark the incident with metadata such as sensitivity or handling instructions ✓
- B. To set the incident's Business impact value so that its risk score is recalculated when saved
- C. To link the incident to a parent security incident so that work notes propagate to the children
- D. To select which process definition the incident follows from Draft through to the Closed state
Why: Security tags (grouped into security tag groups such as Traffic Light Protocol) classify or mark records such as security incidents and observables with metadata such as sensitivity or handling instructions, and a tag can also enforce restricted read or write access. Business impact is its own field on the incident form, recalculated from priority and risk, not something a tag sets. Parent and child relationships are built with the Parent security incident field and the Child Security Incidents list. The process definition in use is chosen through process selection, not by tagging an incident.