--- sourceDocument: Australia Security Management sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/security-management Release : - australia ft:locale : - en-US ft:publication_title : - Australia Security Management ft:clusterId : - security bundleId : - security workflow : - Technology --- # Domain separation and Security Incident Response # Domain separation and Security Incident Response {#ariaid-title1} * Release version: Australia * * Updated March 12, 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 7 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 Domain Separation and Security Incident Response Domain separation in the Security Incident Response (SIR) application allows service providers (SPs) to organize data, processes, and administrative tasks into distinct domains. This feature enhances security by controlling user access to data and supports standardized procedures across multiple clients, improving operational efficiency and service quality. Show full answer Show less ## Key Features * **Data Separation:** Security incidents and alerts are confined to their respective domains, ensuring that sensitive data remains isolated. * **Domain-Aware Applications:** Applications and integrations can be configured to operate specifically within designated domains. * **Role Management:** Administrators can assign user roles and manage workflows specific to each domain. * **Automation Capabilities:** Supports various automation features such as Threat Lookup and Sighting Search within the domain of the security incident. * **Customizable Workflows:** Domain owners can create tailored incident response workflows, categories, and playbooks. ## Key Outcomes By leveraging domain separation, ServiceNow customers can expect: * Enhanced security through strict data isolation. * Improved incident response efficiency with domain-specific automation and workflows. * Greater control over operational processes tailored to individual customer needs. * Accurate reporting and metrics specific to each domain, facilitating effective post-incident analysis. Domain separation is supported in Security Incident Response. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data. ## Support level: Standard {#domain-separation-security-incident-response__section_smh_wgs_xkb} * Includes all aspects of Basic level support. * Application properties are domain-aware as needed. * Business logic: The service provider (SP) creates or modifies processes per customer. The use cases reflect proper use of the application by multiple SP customers in a single instance. * The instance owner must configure the minimum viable product (MVP) business logic and data parameters per tenant as expected for the specific application. {#domain-separation-security-incident-response__ul_tfh_drj_xkb} Sample use case: An admin must be able to make comments required when a record closes for one tenant, but not for another.{#domain-separation-security-incident-response__p_ssc_nfg_h1c} For more information on support levels, see [Application support for domain separation](https://www.servicenow.com/docs/access?context=domain-separated-apps&version=australia&pubname=australia-platform-security&ft:locale=en-US).{#domain-separation-security-incident-response__p_tsc_nfg_h1c} ## Domain separation in SIR overview {#domain-separation-security-incident-response__section_pvf_wkx_vcb} In the Security Incident Response application, domain separation enables service providers (SPs) to standardize SOC (Security Operations Center) and Security Incident Response (SIR) procedures across the customer base they serve with lowered operational costs and a higher quality of service. Separate customer workspaces for workflows, dashboards, reports, and so forth, ensures that customer data is separated and never exposed to other clients. {#domain-separation-security-incident-response__table_upt_sjc_vdb__entry__3} | Release | Support level | Notes | |:-|:-|:-| | Geneva, Helsinki | No support | Initiation of data-level domain separation | | Istanbul | Data only | | | Jakarta | Level 2 (Data, Requestor, Fulfiller) | New features: 3rd-party Integrations support with Level 2 domain separation under a single instance of integration, including Threat Intelligence integrations | | Kingston | Level 2 (Data, Requestor, Fulfiller) | New features: Sighting Search integration for SIR is enabled with multiple instances, but all instances still live under a single domain. Example: If there are two instances of a Splunk integration configured (SplunkCLOUD and SplunkCORP), both are still leveraged for incident response activities in a single domain, where the implementation was originally configured. | | London | Level 2 (Data, Requestor, Fulfiller) | New features: All integrations reside across multiple domains | | Madrid | Level 2 (Data, Requestor, Fulfiller) | All integrations can now reside across multiple domains. In the above example, SplunkCloud can be domain1 and SplunkCORP domain2. | | New York | Level 2 (Data, Requestor, Fulfiller) | All integrations reside across multiple domains. | | Orlando | Standard | All integrations reside across multiple domains. | | Paris | Standard | All integrations reside across multiple domains. | [Table 1. Domain separation support in Security Incident Response by version releases] {#domain-separation-security-incident-response__table_upt_sjc_vdb} Domain separation for the Security Incident Response application covers the following product functionality: * Security alerts are directed to the appropriate domain of the user whose ID/ credential/ scope generates the incident and is registered as a Security Incident. * Alerts generate "observables,"which represent stateful properties or measurable events: Security workflows in the domain of the security incident are used to orchestrate the response. * Integrations are configured in the domain of the security incident for response automation. * Capabilities are configured in the domain of the security incident for response automation. These capabilities (as of the Kingston release) include: * Threat Lookup * Enrich Observable * Enrich Configuration item * Get Running Process * Get Network Statistics * Block Request * Isolate Host * Sighting Search * Email Search and Delete * Publish to Watchlist {#domain-separation-security-incident-response__ul_hlb_xhd_vdb} * Results from Response Automation (such as Threat Lookup or Sighting Search) are stored in the domain of the security incident. * Other security incidents are cross-referenced in the same domain of the security incident based on a shared set of observables. * Other users are cross-referenced in the domain of the security incident. * Configuration Items are cross-referenced in the same domain as the security incident. * Manual response tasks are added to the domain of the security incident. * Knowledge base articles and run books are referenced in the domain of the security incident. * Security Incident Response metrics pertinent to incidents in the domain are displayed on dashboards as well as in reporting. {#domain-separation-security-incident-response__ul_vfz_blc_vdb} Note: In the preceding cases, the overarching principles of visibility in separated domains in the NOW Platform apply. As always, an incident in the parent domain can reference artifacts in the child domain, but not the other way around. ## How domain separation works in Security Incident Response {#domain-separation-security-incident-response__section_ydt_kth_scb} The Security Incident Response application manages the life cycle of a security incident end to end. The following use cases are domain-separation aware: * Ingestion of events and alerts to create security incidents for the analyst in the customer SOC or the MSP to respond: * Email parsers (platform based, user-reported phishing, custom) * De-duplication events/alerts prior to incident creation * Auto extraction of observables * Applications in third-party SIEM store {#domain-separation-security-incident-response__ul_p13_nmc_vdb} * Enrichment of artifacts involved in the incidents (IP, URLs, domains, file hashes): * Asset enrichment (CMDB) * Users (Platform) * Automation: Observable enrichment (Ex: WhoIs) {#domain-separation-security-incident-response__ul_ttz_smc_vdb} * Investigate the incidents with the help of the artifacts and their reputation or association with known threats * Orchestrate: Playbooks and knowledge base articles * Automation: Threat Lookup (Ex: VirusTotal), Sighting Search (Ex: Splunk), Get Running Processes (Ex: Carbon Black) {#domain-separation-security-incident-response__ul_ctq_zmc_vdb} * Eradicate the threat-related artifacts involved in the incident based on the investigation performed * Orchestrate: Playbooks and knowledge base articles * Automation: Email search and delete (Ex: Microsoft Exchange), Block IP (Ex: Palo Alto Firewall) {#domain-separation-security-incident-response__ul_j2n_cnc_vdb} * Measure the efficiency or Incident response operations * Performance Analytics Dashboards: Productivity and incident trends * Reconstruction of incident investigation steps from work notes * Post-incident review {#domain-separation-security-incident-response__ul_pkm_fnc_vdb} {#domain-separation-security-incident-response__ul_ipq_kmc_vdb} ## Domain separation setup {#domain-separation-security-incident-response__section_xl2_3nc_vdb} Setting up domain separation for Security Incident Response doesn't require any additional steps. All Security Incident Response tables acquire the Domain column after the instance is domain separated. ## Domain-separated data {#domain-separation-security-incident-response__section_fps_jnc_vdb} Data can be domain-separated, which means: * Security incidents in one domain can't be viewed from other domains. * Observables extracted from the security incident are placed in the same domain and can't be viewed from other domains. * Up to the Kingston release, configured third-party integrations exist in the global domain and are accessible to all other domains in the instance. * In the Madrid release, third-party integrations can be configured and activated on a per-domain basis. This means that the integration activated and configured in one domain cannot be leveraged in another domain. * Automations that run on the observables using third-party integrations (for Threat Investigation, Containment, or Eradication), place their results in the domain of the security incident and the results can't be viewed from another domain. * Orchestration workflows created in one domain aren't visible in another domain. * Capabilities (as delineated in the preceding capabilities function list) that are invoked stay generic across domains with domain-specific implementation of the capability being called. For example, a Sighting Search on an IP can invoke a Splunk implementation in one domain and a QRadar implementation in another. {#domain-separation-security-incident-response__ul_dpg_nnc_vdb} ## Configuration {#domain-separation-security-incident-response__section_sfz_tnc_vdb} All aspects of product configuration are self-contained in a domain-separated environment. Setup can be tailored for individual domains. Note: Business logic and the processes in #2-5 below can be administered within the tenant domain. The following tasks must be configured: 1. System Administration * Assign roles to users and groups of users: [User roles installed with Security Incident Response](https://servicenow-prod.fluidtopics.net/Ggj2k2A3Ycyj_BpBcgz1tA "Several types of components are installed when you download and activate the Security Incident Response application, including plugin dependencies, user roles, tables, properties, and scheduled jobs.") * Install one or more third-party integration plugins to work with Security Incident Response: [Security Incident Response integrations](https://servicenow-prod.fluidtopics.net/RhaRoT0Fn_2fkoMqo0mGDA "Security Incident Response (SIR) integrates with third-party security tools to create security incidents.") {#domain-separation-security-incident-response__ul_iss_fqc_vdb} 2. Security Incident Response Administration * Add or review roles: [Components installed with Security Incident Response](https://servicenow-prod.fluidtopics.net/Ggj2k2A3Ycyj_BpBcgz1tA "Several types of components are installed when you download and activate the Security Incident Response application, including plugin dependencies, user roles, tables, properties, and scheduled jobs.") * Configure groups and users: [Create a security incident group](https://servicenow-prod.fluidtopics.net/EjEx2i4_BJB~IAh6cy32sQ#t_CreateSecurityIncidentAdminGroup "Set up a security incident group and assign the appropriate roles and users to the group.") * Set up incident escalations: [Escalate a security incident](https://servicenow-prod.fluidtopics.net/xlIlw69eNJdIG1kcgQkPHA "If an escalation path exists for a security incident, the Escalate button is available in the security incident header.") * Set up security incident risk score calculators: [Understanding security incident calculators](https://servicenow-prod.fluidtopics.net/EjEx2i4_BJB~IAh6cy32sQ#c_SecIncCalculators "Security incident calculators are used to update record values when pre-defined conditions are met. The calculators are grouped based on the criteria used to determine how the records are updated.") * Set up service level agreements: [Create a Security Incident Response SLA](https://servicenow-prod.fluidtopics.net/EjEx2i4_BJB~IAh6cy32sQ#t_CreateSecurityIncidentSLA "You can define a Service Level Agreement (SLA) for Security Incident Response.") * Set up security incident process definitions: [Understanding Security Incident Response process definition](https://servicenow-prod.fluidtopics.net/EjEx2i4_BJB~IAh6cy32sQ#sec-inc-resp-process-definition "Security Incident Response Process Definition replaces state flows and provides end users and service desks with the status of a problem. A process definition helps track the problem through its life cycle. Security Incident Response is a Service Management (SM) application, which has its own set of states. Invalid states are reported as part of Process Selection.") * Set up post-incident review processes: [Manage post incident activities](https://servicenow-prod.fluidtopics.net/TPH1MQIwd1a_MXVvpiIOdA "Based on the requirements of your business, a review of the origins and handling of security incidents is often needed.") {#domain-separation-security-incident-response__ul_zc1_4qc_vdb} 3. Security incident email settings * Set the email parsing inbox: [Security Operations email parsing](https://servicenow-prod.fluidtopics.net/e3AEPsAj5Z~kDlc_eORyfw "Generate new Security Operations records from external detection systems using Email Parsing. This feature provides a method for integrating information from external tools such as malware detection, vulnerability detection, firewalls, threat intelligence, and more.") * Set up email parsers for alert ingestion: [Create email parsers in Security Operations](https://servicenow-prod.fluidtopics.net/ad9vca3b1Z_0QW33EljMRg "Email Parsing creates Security Operations records from your email for security, vulnerability, and observables to expedite threat response and remediation.") * Set up email matching rules for user-reported phishing: [Create rules to validate user-reported phishing attacks](https://servicenow-prod.fluidtopics.net/EjEx2i4_BJB~IAh6cy32sQ#create-email-matching-rules "When your employees receive emails that appear to be phishing attacks, they can report them to you using a phishing email address. The suspicious email is validated using rules defined by your organization.") * Set up email inbound actions: [Inbound email actions](https://www.servicenow.com/docs/access?context=c_InboundEmailActions&version=australia&pubname=australia-platform-administration&ft:locale=en-US) {#domain-separation-security-incident-response__ul_hzh_wqc_vdb} 4. Security incident playbook settings * Review and set up runbook documents: [Create a Security Incident Response runbook](https://servicenow-prod.fluidtopics.net/EjEx2i4_BJB~IAh6cy32sQ#create-runbook "A runbook is an association between a published knowledge article and a specific task. While you are performing the task, a knowledge article in the runbook automatically opens, providing information pertinent to the task.") * Set up security incident workflows: [Security Operations common functionality](https://servicenow-prod.fluidtopics.net/3bS6dWUIttw~ph9u9VyvCA "Whenever any of the plugins for the main Security Operations applications (Security Incident Response, Vulnerability Response, Threat Intelligence, or Configuration Compliance) are activated, the Security Support Common plugin is activated. This plugin loads various modules that provide functionality that is common across all Security Operations applications.") {#domain-separation-security-incident-response__ul_rm5_brc_vdb} 5. Capability configurations * Block request: [Security Operations Integration- Block Request capability](https://servicenow-prod.fluidtopics.net/TH3Fk5ngVPUW4bbScyEGwg "The Block Action capability blocks observables associated with a security incident on a firewall, web proxy, or other control point using implementation flows. This capability is used during incident response investigations to contain an identified threat.") * Email search and delete: [Security Operations Integration- Email Search and Delete capability](https://servicenow-prod.fluidtopics.net/iygPFivlSIet72Kp6CuLmQ "The Email Search and Delete capability returns the number of threat emails from an email server search and, optionally, returns details for each email found. After the email search is completed, you can delete the emails.") * Enrich configuration item: [Security Operations Integration- Enrich CI capability](https://servicenow-prod.fluidtopics.net/vklSRIi5EQ1wPGmNMtRt~A "The Enrich CI capability allows you to enrich data for configuration items associated with a security incident.") * Enrich observable: [Security Operations Integration- Enrich Observable capability](https://servicenow-prod.fluidtopics.net/SFbmJuNvMEgdI67XP2~5Hg "The Enrich Observable capability allows you to enrich observables with additional information from a variety of sources using implementation flows. This capability is used during incident response investigations to contain an identified threat.") * Get network statistics: [Security Operations Integration- Get Network Statistics capability](https://servicenow-prod.fluidtopics.net/uVBOus1TpQa4vzKbd7aGLg "The Get Network Statistics capability retrieves a list of active network connections from a host or endpoint. It can be used for incident enrichment during investigations. This capability is triggered automatically when a configuration item is added to a security incident.") * Get running processes: [Security Operations Integration- Get Running Processes capability](https://servicenow-prod.fluidtopics.net/7G0Det4oSs92UixHhucV7w "The Get Running Processes capability retrieves a list of running processes on a configuration item (CI) from a host or endpoint. This capability is used for incident enrichment during investigations.") * Isolate host: [Security Operations Integration- Isolate Host capability](https://servicenow-prod.fluidtopics.net/l37EZFEV1U1ZHH_Y5hUuWQ "The Isolate Host capability restricts system connections to other devices. Isolate host is executed against a configuration item (CI).") * Publish to Watchlist: [Security Operations Integration- Publish to Watchlist capability](https://servicenow-prod.fluidtopics.net/sqRJetgV_urJTWNWGVogFA "The Publish to Watchlist capability adds observables and indicators associated with a security incident to a third-party watchlist that monitors for security events and generates alerts. This capability is used as part of incident response during investigations.") * Sighting search: [Security Operations Integration- Sightings Search capability](https://servicenow-prod.fluidtopics.net/xMR07ohbMYj8J76trH9y8g "The Sightings Search capability accepts a set of observables, finds any integrations that support a Sightings Search, then executes these searches.") * Threat lookup: [Security Operations Integration - Threat Lookup capability](https://servicenow-prod.fluidtopics.net/aKsui0~8zhutMOFnbigrAA "The Threat Lookups capability performs threat intelligence lookups to determine whether one or more observables are associated with known security threats.") {#domain-separation-security-incident-response__ul_osy_xfk_vdb} {#domain-separation-security-incident-response__ol_qxl_bqc_vdb} ## How tenant domains manage their own application data {#domain-separation-security-incident-response__section_ogx_qsc_vdb} * Tenant domain owners create their own email parsing rules for ingesting security incidents. * Tenant domain owners can configure specific integrations exclusively for use within the domain. * Tenant domain owners can create their own incident response workflows. * Tenant domain owners can create their own incident categories, incident response knowledge base articles, and runbooks to be associated with incident response workflows. * Tenant domain users create and close their own security incidents. {#domain-separation-security-incident-response__ul_ewx_tsc_vdb} ## Business logic and processes that can be domain separated by instance owner {#domain-separation-security-incident-response__section_dlm_ysc_vdb} * Security Incident Response users and groups * Security Incident Response integrations (starting with the Madrid release) * Email parsing rules for incident creation * Business rules to consolidate multiple events or alerts into a security incident * Workflows for incident response orchestration * Security incident risk score calculators * Security incident escalation path * Security incident SLAs * Security incident process definitions * Security incident post-incident review processes {#domain-separation-security-incident-response__ul_l5d_zsc_vdb} **Related topics** * [Domain separation for service providers](https://www.servicenow.com/docs/access?context=domain-sep-landing-page&version=australia&pubname=australia-platform-security&ft:locale=en-US)