Create Security Incidents
About 10% of the CIS-SIR exam — see all 7 domains.
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: reported emails (notably phishing reports) are processed automatically: for user-reported phishing, the Create Phishing Email inbound action creates a phishing email record and the Transform user-reported phishing emails to security incidents flow converts it into a security incident, with observables extracted 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. Defining the phishing email address and email matching rules is one of the Setup Assistant steps, tying Domain 2 back to Domain 1.
Sample questions from this domain
Three of the 30 in this domain, with the reasoning. The full set is in the question bank.
Which of the following is a valid method for creating a security incident in ServiceNow?
- A. Adding a response task to an existing security incident
- B. Manually creating a record in the Security Incident form ✓
- C. Running a Sightings Search on an observable in the SIEM logs
- D. Saving a new record on the Security Request form
Why: Selecting New on the Security Incident list opens the Security Incident form, and saving it manually creates a security incident (other manual routes include the Security Incident Catalog and Create Security Incident on an Incident Management incident). Adding a response task only adds work to an incident that already exists. A Sightings Search looks for an observable in integrated SIEM or log data and does not open an incident. A security request is a separate record (sn_si_request) that becomes a security incident only when someone selects Convert to Security Incident.
Which two channels can automatically generate a security incident without an analyst manually filling out the form? (Choose two)
- A. Inbound email parsing of reported phishing messages ✓
- B. A security request that an analyst has not yet converted
- C. An email from a detection tool that lands in Unmatched Emails
- D. A Service Catalog request item submitted through the portal ✓
- E. A Sightings Search that finds an observable in SIEM logs
Why: Inbound email parsing of reported phishing messages and a Service Catalog item submitted by an end user both produce a security incident without an analyst filling in the form. A security request stays a request until someone selects Convert to Security Incident. An email that lands in Unmatched Emails matched no email parser, so no record was created from it (it can be reprocessed after a parser is added). A Sightings Search reports where an observable appears in SIEM or log data; it does not create an incident.
An organization wants employees to report suspicious emails by forwarding them to a monitored mailbox, which then creates a security incident. Which mechanism enables this?
- A. An email matching rule set to Allow, which itself opens the security incident as soon as a forwarded message meets its conditions
- B. Inbound email processing: an inbound email action creates a phishing email record that a flow converts into a security incident ✓
- C. An Event Management alert rule, which raises an alert for each forwarded message and then opens a matching security incident
- D. A scheduled import set, whose transform map loads each message in the mailbox directly into the security incident table
Why: In Zurich, the Create Phishing Email inbound action checks the message against the email matching rules (ingestion rules) and creates a phishing email record (sn_si_phishing_email), and the Transform user-reported phishing emails to security incidents flow, which is inactive by default, converts it into a security incident. An Allow email matching rule only decides that the message qualifies as user-reported phishing; it does not create the incident itself. Event Management alert rules create security incidents from monitoring alerts, not from messages in a mailbox. A scheduled import set with a transform map loads bulk data from a data source and is not how forwarded phishing email is processed.