CIS-SIR Study Guide — ServiceNow Certified Implementation Specialist: Security Incident Response

Trademark disclaimer: ServiceNow, the ServiceNow logo, Now Platform, Security Operations, and all related product and feature names are trademarks or registered trademarks of ServiceNow, Inc. This study guide is an independent, original work created for exam preparation. It is not affiliated with, endorsed by, or sponsored by ServiceNow, Inc. All trademarks are the property of their respective owners.

How to use this guide. Domains below are ordered by exam weight (heaviest first), not by blueprint number. The CIS-SIR exam has 60 scored questions in 90 minutes. Concentrate your study time proportionally: Security Incident Response Management alone is roughly a third of the exam. Every concept here is written in original prose grounded in official ServiceNow Security Operations documentation. Where a claim depends on a specific release behavior that may have drifted, it is flagged (VERIFY) — confirm against your target release before relying on it.

Domain 4 — Security Incident Response Management (30%)

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.

Domain 1 — Security Incident Response Overview (15%)

This domain establishes the product's place in the portfolio, its data model, and its setup.

Product positioning

Security Incident Response is one of the core applications in the Security Operations (SecOps) product family, alongside Vulnerability Response and Threat Intelligence. SecOps connects the security organization to the Now Platform and the CMDB, bridging security tooling and IT operations. SIR is not part of ITSM, CSM, or GRC, though it integrates with them (for example, sharing the CMDB and integrating with Change for remediation).

Core data model

sn_si_incident — the security incident record (extends Task).
sn_si_task — response tasks (child work items).
sn_ti_observable — observables (IPs, hashes, domains, URLs, etc.) managed by Threat Intelligence.
Security incidents relate to CMDB CIs, users, and affected services.

Setup Assistant

The Security Incident Response Setup Assistant is the purpose-built, guided configuration tool. After activating the application, an implementer uses the Setup Assistant to walk through baseline configuration in organized sections: email/notification accounts for incident creation, default assignment, key system properties, integrations, and feature activation. It is the SIR analog of ITSM Guided Setup. Know that the Setup Assistant — not Flow Designer, not the Upgrade Monitor — is the answer when a question asks for the guided baseline-configuration tool for SIR.

Activation and dependencies

SIR is activated via plugin/Store install and depends on the Security Operations common components. Some capabilities (Threat Intelligence enrichment, integrations from the ServiceNow Store) are licensed and activated separately. (VERIFY) specific plugin names and licensing for your release.

Domain 6 — Automation and Standard Processes (15%)

Flow Designer is the automation engine

Modern SIR automation is built on Flow Designer, the Now Platform's low-code automation tool, which has replaced legacy Workflow for new SIR content. Flows are composed of triggers, actions, subflows, and the Action Designer for building reusable actions. SIR ships a library of security-specific flow actions (enrich observable, block IP, run lookups, create/close response tasks, notify, etc.) that you assemble into playbooks.

Standard processes and orchestration

Automation standardizes the response process: flows can auto-create response tasks, auto-enrich observables, auto-assign, and drive state transitions. Integration actions reach out to external security tooling through integration capabilities (a SecOps abstraction layer that maps a generic capability like "Block IP" or "Get Network Statistics" to a specific vendor integration). This abstraction means a playbook calls a capability, and whichever integration is configured for that capability executes it — letting you swap vendors without rewriting flows.

Phishing automation (the canonical example)

The automated phishing playbook flow is the most-documented standard process: a reported phishing email is parsed, observables (sender, URLs, attachments, IPs) are extracted, observables are enriched and looked up against threat sources, malicious indicators drive containment actions, and the incident is updated or closed. Know its end-to-end shape — it is a frequent source of automation questions.

Business rules, flows, and when to use what

Understand the distinction: business rules run server-side on database operations; flows are the preferred, maintainable way to orchestrate multi-step response and integration logic; Action Designer builds the reusable building blocks. The exam favors Flow Designer as the modern answer for SIR automation.

Domain 3 — Security Incident & Threat Intelligence Integrations (14%)

Observables and Threat Intelligence

Observables (sn_ti_observable) are the indicators of compromise associated with a security incident — IP addresses, domains, URLs, file hashes, email addresses. Threat Intelligence (TI) manages observables, threat sources, and indicators of compromise (IoC) feeds. When observables are attached to a security incident, the system can automatically scan and enrich them.

Enrichment and the Enrich Observable capability

Observable enrichment gathers additional context about an observable from external sources (reputation, geolocation, sandbox detonation results, WHOIS, etc.). The Enrich Observable capability is the SecOps integration capability that runs enrichment workflows; results appear on the observable's enrichment results. Enrichment can run automatically on incident creation or be triggered manually. This is core integration content — know that enrichment is capability-driven and that results are written back to the observable record.

ServiceNow Store integrations vs. custom integrations

Integrations come in two broad flavors:

Store integrations — pre-built integrations published on the ServiceNow Store (for example, VirusTotal, Shodan, Microsoft Defender, Palo Alto, Splunk, MISP, and many others). These map vendor functionality to SecOps integration capabilities.
Custom integrations — built in-house using the integration framework, REST/IntegrationHub spokes, and Action Designer, then mapped to capabilities so playbooks can call them.

Integration capabilities (the abstraction)

The integration framework defines capabilities such as Enrich Observable, Block IP, Get Network Statistics, Sightings Search, Get Running Processes, and others. Each capability can have one configured implementation. Playbooks and flows invoke the capability, not the vendor directly. This is the single most important integration concept on the exam — capabilities decouple the response process from specific tooling.

Threat lookup and sightings

A threat lookup queries threat sources for what is known about an observable. Sightings search queries SIEM/log sources to find where an observable has been seen across the environment, helping scope an incident. Both are capability-driven integrations.

MISP and threat sources

ServiceNow integrates with threat-intel platforms such as MISP for observable enrichment and IoC sharing. Threat sources feed indicators into TI, which can in turn create or enrich security incidents.

Domain 5 — Risk Calculations and Post Incident Response (13%)

Severity and risk calculation

A security incident's severity can be calculated automatically by a severity calculator that evaluates business-impact factors — the criticality of affected CIs/services, the number of affected users, and other weighted inputs — to produce a severity/priority value. The calculator is rule-driven and configurable: you can define the fields and weights that contribute to the score. The goal is consistent, defensible prioritization rather than analyst guesswork.

Risk score / severity is derived from business impact (affected service criticality, asset value) and incident attributes.
Calculators are configurable — implementers tune the inputs and weights to match the organization's risk model.
(VERIFY) the exact calculator names, default fields, and weight tables for your release, as these have evolved.

Business criticality and the CMDB

Because security incidents reference CMDB CIs, the business criticality of the affected CI/service feeds severity. A compromised business-critical server produces a higher severity than the same compromise on a low-value asset. This CMDB linkage is the bridge that makes risk-based prioritization possible.

Post Incident Review (PIR)

After an incident closes, Post Incident Review captures lessons learned: what happened, how it was handled, what worked, and what should change. PIR is structured (often a questionnaire/assessment) so that findings are consistent and actionable. The output drives continuous improvement — updated runbooks, new playbook steps, tuned calculators, closed gaps. Know that PIR is a defined, post-closure phase (it maps to the Review state) and is part of standardized incident handling, not an ad-hoc afterthought.

Closure and resolution

Closing a security incident requires recording closure information (resolution, close code/notes) and, depending on configuration, completing the review. SLAs stop on closure. Proper closure data is what feeds dashboards, PA, and PIR metrics.

Domain 2 — Create Security Incidents (10%)

There are several supported creation paths, and the exam expects you to match a scenario to the right method.

Creation methods

Manual creation — an analyst creates a security incident directly (form or workspace), choosing category, affected CI/user, and details.
Email parsing / inbound email — inbound email actions parse reported emails (notably phishing reports) and create security incidents automatically, extracting observables from the message. This underpins the phishing playbook.
Service Catalog — a security incident catalog item lets end users or analysts submit a request that generates a security incident through a record producer.
Integrations / event-driven — SIEM, EDR, and other security tools create security incidents via integrations, alerts, or the Event Management/alert pipeline. This is the most common enterprise creation path at scale.
Manually from another record — promotion from a related task, alert, or threat record.

Record producers and catalog

A record producer is the platform mechanism behind a catalog-driven security incident: it presents a simplified form to the submitter and creates the sn_si_incident record with mapped values. Know that catalog creation = record producer.

Email parsing specifics

Inbound email creation relies on configured email accounts and inbound email actions/flows. Reported phishing emails (often forwarded to a dedicated mailbox) are parsed; the body and headers yield observables. Configuring the notification/email account is one of the Setup Assistant steps — tying Domain 2 back to Domain 1.

Domain 7 — Data Visualization (3%)

Smallest domain, but easy points if you know the vocabulary.

Dashboards

SIR ships dashboards that surface operational and management KPIs: open incidents by state/severity, SLA attainment, mean time to respond/resolve, incidents by category, analyst workload, and trend lines. Dashboards are role-aware so managers and analysts see relevant views.

Performance Analytics (PA)

Performance Analytics provides time-series trending, scorecards, and KPIs beyond point-in-time reports. SIR ships PA content packs/solutions with predefined indicators (for example, incidents created/closed over time, SLA breach rate, MTTR trends). PA captures snapshots of data over time so you can see direction of travel, not just current state. Know the difference: Reports = point-in-time; Performance Analytics = trend over time via scheduled snapshots.

MITRE ATT&CK visualization

SIR/TI integrate with the MITRE ATT&CK framework. Analysts associate tactics and techniques with security incidents, and the product provides a MITRE ATT&CK heat map and navigator to visualize adversary behavior coverage and which techniques appear across incidents. Child incident techniques can roll up to a parent (relevant to MSIM). This is both a Data Visualization and Threat Intelligence topic — know that ATT&CK associations exist, that there is a heat map/navigator, and that it visualizes tactics/techniques.

Fast-recall cheat list

Table for security incidents: sn_si_incident (extends Task). Response tasks: sn_si_task. Observables: sn_ti_observable.
Product family: Security Operations (SecOps) — with Vulnerability Response and Threat Intelligence.
Lifecycle (NIST-aligned, default): Draft → Analysis → Contain → Eradicate → Recover → Review → Closed.
Guided baseline config tool: Security Incident Response Setup Assistant (not Guided Setup, not Flow Designer).
Key roles: sn_si.analyst, sn_si.admin, sn_si.manager, sn_si.basic, sn_si.read_all / write_all. SIR data is restricted by default.
Automation engine: Flow Designer (+ Action Designer). Legacy Workflow is deprecated for new SIR content.
Integration abstraction: Capabilities (Enrich Observable, Block IP, Sightings Search, Get Network Statistics, …). Playbooks call the capability; the configured integration executes it.
Two integration sources: ServiceNow Store (pre-built) vs. custom (IntegrationHub spokes / Action Designer), both mapped to capabilities.
Canonical automation: automated phishing playbook — parse email → extract observables → enrich/lookup → contain → close.
Enrichment: Enrich Observable capability adds external context (reputation, sandbox, geo) to observables; auto or manual.
Threat lookup = query threat sources about an observable. Sightings search = find where an observable appears across logs/SIEM.
Severity/risk: rule-driven, configurable severity calculator using business-impact + CMDB criticality + weighted fields.
Major Security Incident Management (MSIM): promotion of an incident for coordinated war-room handling; supports child incidents and MITRE roll-up.
Security tags / TLP: classify and govern information handling and visibility (TLP RED/AMBER/GREEN/CLEAR).
SLAs: platform SLA engine on security incidents (acknowledge / respond / resolve); key management KPI.
Post Incident Review (PIR): maps to Review state; structured lessons-learned feeding continuous improvement.
Creation methods: manual, email parsing (record an email account + inbound action), Service Catalog record producer, integrations/SIEM-EDR, promotion.
Reports vs. PA: Reports = point-in-time; Performance Analytics = trend via scheduled snapshots.
MITRE ATT&CK: associate tactics/techniques to incidents; heat map + navigator visualization; rolls up across child incidents.
Watch item: the published CIS-SIR blueprint predates several releases — verify table names, role names, default-activated playbooks, calculator fields, and workspace naming against your target release.