Playbook for Child Security Incident Automation

  • Release version: Zurich
  • Updated March 12, 2026
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Playbook for Child Security Incident Automation

    The Child Security Incident Automation playbook is designed to streamline the handling of duplicate security incidents, known as child security incidents, by automatically consolidating unique details into the parent security incident. This automation reduces investigation and closure time for duplicates by rolling up affected users, configuration items (CIs), and observables from child incidents to their parent incident, and managing incident states accordingly.

    Show full answer Show less

    Key Features

    • Automatically transitions child security incidents from Draft to Analysis stage.
    • Eliminates duplicate affected users and rolls up unique users and CIs to the parent incident.
    • Rolls up unique observables from the child to the parent security incident.
    • Posts automated worknotes on both parent and child incidents to document rolled-up artifacts.
    • Closes or cancels child security incidents when the parent incident is resolved.

    Prerequisites and Setup

    • Required roles: snsi.admin and flowdesigner.
    • Install the Security Operations Spoke (snsecspoke) in Flow Designer.
    • Login as a user with appropriate roles and navigate to Flow Designer to access the playbook.
    • Optionally, make a copy of the playbook to customize it for specific organizational needs before activation.
    • The playbook is triggered when a child security incident has a non-empty parent incident field and the parent is in Draft, Analysis, Contain, or Eradicate states.

    How It Works

    The playbook executes a series of steps:

    • If the child incident is in Draft, it updates the state to Analysis.
    • Retrieves and consolidates affected users from the child to the parent incident, removing duplicates.
    • Retrieves and rolls up unique configuration items.
    • Retrieves and consolidates unique observables.
    • Adds automated worknotes to both parent and child incidents to record these roll-up actions.
    • Automatically closes or cancels the child incident when the parent incident is closed.

    Benefits for ServiceNow Customers

    • Reduces manual effort in managing duplicate security incidents.
    • Ensures comprehensive aggregation of critical security data in the parent incident.
    • Improves incident investigation efficiency and closure times.
    • Maintains clear audit trails through automated worknotes.

    Duplicate security incidents are categorized as child security incidents and are rolled up to the parent security incidents.

    The Child Security Incident Automation playbook helps reduce the time required to investigate and close duplicate security incidents. This playbook automatically rolls up specific unique artifacts of the child security incident (observables, affected users, CIs) to the parent security incident.

    Prerequisites

    Role required:
    • sn_si.admin
    • flow_designer

    Spoke: Install Security Operations Spoke (sn_sec_spoke)

    Key capabilities

    The Child Automation playbook covers the following capabilities:

    1. Moves the security incident to the Analysis stage.
    2. Eliminates duplicates and adds (rolls up) the affected users and CIs to the parent security incident.
    3. Adds observables from the child incident to the parent security incident.
    4. Closes or cancels the child security incident when the parent security incident is closed.

    Capabilities required

    For more information, see the ServiceNow store.

    Security analyst experience

    To understand how to resolve security threats in a step-by-step manner, see Resolve security threats with the playbook.

    Deeper understanding of the Child Security Incident Automation playbook with Flow Designer capabilities

    Getting Started
    1. Login as a user with sn_si.user and flow_designer roles.
    2. Navigate to Flow Designer > Designer and select the Failed Login playbook.
    3. Make a copy of the Child Security Incident Automation playbook and make the necessary modifications. (This is an optional step. Follow this step only if you plan to customize or make specific changes to the flow).
    4. Make the necessary modifications according to your requirement. (This is an optional step. Follow this step only if you plan to customize or make specific changes to the flow).
    5. Activate the playbook.
      • Activate the main flow to use the playbook available with the base system.
      • Activate the copied flow after making any modifications according to your requirements.
    The following image shows a copy of the Child Security Incident Automation playbook. Review the steps below to get an understanding of the various actions in the playbook.
    Child Automation Flow:Overview
    This playbook is triggered when:
    • The parent security incident field isn’t empty.
    • The parent security incident is in Draft, Analysis, Contain, or Eradicate state.

    The following steps walk you through the actions and tasks that are available in the Child Security Incident Automation playbook.

    1. When the playbook starts executing, in Step 1, if the security incident is in a Draft state, it’s updated and set to the Analysis state.
    2. In steps 2 and 3, affected users for the security incident are retrieved and rolled up to the parent security incident. Any duplicate users are eliminated.
    3. In steps 4 and 5, configuration items associated with the child security incident are retrieved and unique CIs are rolled up to the parent security incident.
    4. In steps 6 and 7, observables associated with the child security incident are retrieved and unique observables are rolled up to the parent security incident
    5. In steps 8 and 9, automated worknotes are posted to the parent and child security incidents indicating that the affected users, configuration items, and observables have been rolled up from the child to the parent security incident.