> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/xsoar-6-administrator-guide/6.12/configure-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/incident-lifecycle.md). # Incident Lifecycle Cortex XSOAR is an orchestration and automation system used to bring all of the various pieces of your security apparatus together. Using Cortex XSOAR, you can define integrations with your third-party security and incident management vendors. You can then trigger events from these integrations that become incidents in Cortex XSOAR. Once the incidents are created, you can run playbooks on these incidents to enrich them with information from other products in your system, which helps you complete the picture. In most cases, you can use rules and automation to determine if an incident requires further investigation or can be closed based on the findings. This enables your analysts to focus on the minority of incidents that require further investigation. The following diagram explains the incident lifecycle in Cortex XSOAR. ![incident-lifecycle.png](/files/eOLpcaZTjUKOpOofZ0gr) **Planning** Before you begin configuring integrations and ingesting information from third parties, consider the following: | Phase | Description | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Create fields | Used to display information from third-party integrations and playbook tasks when an incident is created or processed. For more information, see [Incident Fields](/xsoar-6-administrator-guide/6.12/configure-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/incident-customization.md#UUID-6928d291-2b38-6212-e714-79650c291264). | | Create incident types | Classify the different types of attacks with which your organization deals. | | Create incident layouts | Customize your layouts for each incident type to make sure the most relevant information is shown for each type. For more information, see [Customize Incident Layouts](/xsoar-6-administrator-guide/6.12/configure-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/incident-customization.md#UUID-5cd6db5a-52b4-a3f9-ba81-e9b70feb7c11). | This is an iterative process. After you initially create your fields and incident types, as well as implement them in your incident layouts, you can start the process of ingesting information. You can then see how accurately you have mapped out your information. Make changes as you go along and learn more about the information you are receiving. Information that is not mapped to fields is available in labels, but it is much easier to work with the information when it is properly mapped to a field and displayed in the relevant layouts. **Configure Integrations** You configure integrations with your third-party products to start fetching events. Events can be potential phishing emails, authentication attempts, SIEM events, and more. **Classification Mapping** Once you configure the integrations, you have to determine how the events ingested from those integrations will be classified as incidents. For example, for email integrations, you might want to classify items based on the subject field, but for SIEM events, you will classify by event type. In addition, you have to map the information coming from the integrations into the fields that you created in the planning stage. For more information, see [Classification and Mapping](/xsoar-6-administrator-guide/6.12/configure-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/classification-and-mapping.md). **Pre-Processing** Pre-processing rules enable you to perform certain actions on incidents as they are ingested into Cortex XSOAR directly from the UI. Using the rules, you can select incoming events on which to perform actions, for example, link the incoming event to an existing incident, or based on configured conditions, drop the incoming incident altogether. For more information, see [Create Pre-Process Rules for Incidents](/xsoar-6-administrator-guide/6.12/configure-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/pre-process-rules.md#UUID-e49e2cac-8f6f-17d7-51fc-b69b438ccd7c). **Incident Created** Based on the definitions you provided in the Classification and Mapping stage, as well as the rules you created for pre-processing events, incidents of various types are created. The incidents all appear in the Incidents page of the Cortex XSOAR user interface, where you can start the process of investigating. **Running Playbooks** Playbooks are triggered either when an incident is created or when you run them manually as part of an investigation. When triggered as part of an incident that was created, the playbooks for the type of incident that was classified will run on the incident. Alternatively, if you are manually running a playbook, you can select whichever playbook is relevant for the investigation. For example, playbooks can take IP address information from one integration and enrich that IP address with information from additional integrations or sources. **Post-Processing** Once the incident is complete and you are ready to close it out, you can run various post-processing actions on the incident. For example, send an email to the person who opened the incident informing them that their incident has been resolved, or close an incident in a ticketing system. ### **Fetch Incidents From an Integration Instance** You can poll third party integration instances for events and turn them into Cortex XSOAR incidents that trigger automations (fetching). There are a number of integrations that support fetching, but not all support this feature. You can view each integration in the [Cortex XSOAR Developer Hub](https://xsoar.pan.dev/docs/reference/index). You set the objects to be fetched and their mapping in Settings → OBJECTS SETUP → Incidents → **Classification & Mapping**. When setting up an instance, you can configure the integration instance to fetch events. You can also set the interval for which to fetch new incidents, by configuring the **Incidents Fetch Interval** field. The fetch interval default is 1 minute. This enables you to control the interval in which an integration instance reaches out to third-party platforms to fetch incidents into Cortex XSOAR. If the integration instance, does not have the **Incidents Fetch Interval** field, you can add this field by editing the integration settings. {% hint style="info" %} ### Note * In some integrations the **Incidents Fetch interval** is called **Feed Fetch Interval**. * If the integration instance does not have the **Incidents Fetch Interval** field, you need to add this field by editing the integration settings. If the integration is from a content pack, you need to create a copy of the integration. Any future updates to this integration will not be applied to the copy integration. {% endhint %} You can change the default for all integration instances by setting the server configuration using the **`serversiemincidents.schedule`** key. The value is the interval in seconds (s), minutes (m) or hours (h). Setting the incident fetch interval when defining an instance overrides the server configuration settings. Go to Settings → About → **Troubleshooting**. For example, type **`jobs.serversiemincidents.schedule`** key and **`120s`** value. It is recommended that you do not set the value to less than one minute (1m). {% hint style="info" %} ### Note If you turn off fetching for a period of time and then turn it on or disabled the instance and enabled it, the instance remembers the "last run" timestamp, and pulls all events that occurred while it was off. {% endhint %} 1. Select the integration instance you want to fetch incidents by going to Settings → **INTEGRATIONS** and click the integration instance settings button. 2. Select the **Fetches incidents** checkbox. Once enabled, Cortex XSOAR searches for events that occurred within the time frame set for the integration, which is based on the specific integration. The default is 10 minutes prior, but can be changed in the integration script implementation. 3. (Optional) In the **Incidents Fetch Interval** field, set the number of hours or days, and the number of minutes the interval for which to fetch incidents (default 1 minute). 4. (Optional) If the **Incidents Fetch Interval** field does not appear, add it to the integration. Relevant for any incident fetching integration. 1. For out-of-the-box integrations, select the duplicate integration button. If you have already duplicated the integration, click the Edit integration’s source button. 2. In the **Basic** section, select the **Fetches incidents** checkbox. In the **Parameters** section, you can see that the **`incidentsFetchInterval`** parameter is added. Change the default value if necessary. ![integration-fetch.png](/files/72ui8M6VxPnkMorSja1q) 3. **Save** the integration. ### **Receive Notification on an Incident Fetch Error** The administrator and Cortex XSOAR users on the recipient’s list receive a notification when an integration experiences an incident fetch error, which occurs for a state transition from **Success** to **Failure** during an incident fetch. {% hint style="info" %} ### Important Because notifications are triggered only by the state transition, you will not receive an alert if: * A new integration instance fails its first fetch attempt (since a successful fetch has not yet occurred). * You force a fetch failure for testing purposes before a successful fetch has occurred. {% endhint %} Cortex XSOAR users can select their notification method, such as email, from their user preferences. Administrators with multiple instances of mail sender can choose to receive one email notification instead of multiple email notifications. {% hint style="info" %} ### Note The connectivity behavior that exists between third-party applications may trigger a fetch failure, which will send a notification to an administrator and users. If the fetch operates correctly just after the notification was sent, the notification may no longer be relevant. {% endhint %} **Before you begin** In the integration instance, ensure that you select the **Fetch Incidents** checkbox. 1. Select Settings → About → Troubleshooting → **Add Server Configuration**. 2. Add the following keys and values: | Key | Value | | ----------------------------------------- | ----------------------------------------------------------------- | | **`module.health.notification.users`** | List of names in CSV format, for example **`user1,user2,user3`**. | | **`message.ignore.failedFetchIncidents`** | **`false`**. | 3. (Optional) Administrators that have multiple instances of a mail sender configured that want to receive only one email notification should select the **Do not use by default** option in the integration instances that should not be used to send emails. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/xsoar-6-administrator-guide/6.12/configure-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/incident-lifecycle.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.