To ensure effective and consistent monitoring, reporting, and handling of information security incidents, incident management capability is necessary for rapid detection, minimizing loss and destruction, mitigating the weaknesses that were exploited, and restoring the organization’s services and systems.

SIRP’s Incident Management module helps analyze, respond, collaborate, and remediate time-sensitive incidents from inception till resolution to mitigate risks effectively and reduce response time.

The disposition on an incident record is the current status or final outcome of an incident. SIRP’s Incident Management module comprises of following dispositions:

  • Alert

  • Investigation

  • Incident

  • Not an incident (False Positive)

Through these dispositions, SIRP allows you to define a different set of fields and workflows, depending on the status and gathered data/evidence. The information to be supplied for each incident disposition is divided into the following sub-sections:

  • Information

  • Categorization

  • Analysis Summary

  • Evidence

  • Remediation


Alerts in SIRP are signals that indicate a possible attack. Alerts can be either manually added by an analyst, or automatically ingested from a SIEM (Security Information Event Management) solution or security control.

To access Incident Management Alerts, go to the Main Menu, select Incident Management, and click on the Alerts tab.

Main Menu > Incident Management > Alerts

You can View, Edit, and/or Delete any record by clicking on the ellipsis displayed in the Actions column.


Investigation is the stage when an alert is evaluated and assessed by an analyst. All such alerts are displayed in the Investigations list, available in the Incident Management module.

To access Investigations, go to the Main Menu, select Incident Management, and click on Investigations.

Main Menu > Incident Management > Investigations


The analyst changes the disposition of an alert or an investigation to an Incident when his analysis results in the confirmation of an attack or when some resolution or fix is deemed necessary.

The Incidents module in SIRP allows you to document critical information about an attack. The SOC and relevant parties use this information to identify the scope of the attack and its remediation.

Note: Incidents are opened when a certain action or remediation is required on an alert. So, in the Incidents module, an Incident also acts as a “Case”.


You can add an alert, investigation, or incident by clicking on the Create button displayed at the top of each page. For each disposition, SIRP divides and gathers the required data in five sub-sections:


  • Subject: This is the name or title of the record.

  • Priority: Set the priority based on how quickly the remediation needs to be performed. The three levels of priorities available in SIRP are:

  1. Low

  2. Medium

  3. High

  • Status: Set the status based on the current status or final outcome:

  1. Open

  2. Close

  3. Deferred. etc

By default, the status is set to Open. Once the remediation is performed, SOC Manager or a Senior Analyst can change the status to Close.

  • Description: Provide a brief description of the activity.

  • Start Date: The date when the work started on this particular alert.


  • Members: These are the people who will receive notifications about this incident.

  • Category: Select a category depending on the type of attack:

  1. Intrusion

  2. Malware

  3. Phishing

  4. Policy violation, etc.

Note: Administrator can customize these categories. For more information, refer to the SIRP Administration Guide.

  • Subcategories: Each category is divided into subcategories to signify the exact attack within the main category.

  • Disposition: The disposition on an incident record is the current status or final outcome of an incident. The following Dispositions are available in SIRP:

  1. Alert

  2. Investigation

  3. Incident

  4. Not an incident

Selecting Alert, Investigation, or Incident will show that record in the selected Disposition’s tab or stream.

Best Practice: Initially all incidents should be created as an Alert or Investigation by L1 Analyst. Depending on the results of the investigation, the senior analyst should confirm the activity and change the disposition to Incident.

  • Disposition Subcategory: Each disposition is further classified into three subcategories:

  1. Confirmed

  2. Deferred

  3. Unidentified

  • Location: Select a location where the particular incident occurred. For example:

  1. Primary Datacenter

  2. Secondary Datacenter

  3. DR Site

Note: The administrator can customize these locations. For more information, refer to the SIRP Administration Guide.

After completing each step, press the Next button that is displayed at the bottom of the page.


The analysis section gathers the most critical piece of information. This is where the analyst supplies the details of his findings along with supporting arguments.

  • Alert Summary: A summary of key factors pointing towards a potentially malicious activity.

  • Owner/Custodian: Provide information about the custodian of an asset or the name of the department that will handle this incident.

  • Alert Date: The date when the Alert got triggered.

  • Detection Date: The date/time when the analyst detected the activity.

  • Alert Ended: Select Yes or No depending on if multiple alerts of the same type are still being received or not.

  • Alert Duration: Select the duration between the first and the last alert.

  • Escalation Date: The date at which the incident is escalated to the concerned department or individual.

  • Severity: Severity of an alert can be selected from one of the four levels:

  1. Low

  2. Medium

  3. High

  4. Critical

  • Estimated Recovery Clock: Include details if downtime is observed.

  • Users Affected: Select the number of users affected by the activity.

  • Hosts Affected: Select the number of hosts affected by the activity.

  • Alert Type: Select the source of the alert e.g. SIEM, Manual review of logs, etc.

Note: The administrator can customize the list of Alert Types.


  • Evidence Description: Provide a brief description of supplied evidence or specify where the evidence is collected from.

  • Evidence: This section allows you to add artifacts or indicators of compromise (IOCs) pertaining to a particular alert, investigation, or incident. For example:

  1. Source/Destination IP

  2. URL

  3. IP Address

  4. Hash, etc.

The Attachment icon allows you to attach relevant screenshots. For example, SIEM-filtered search results or initial alert details.


  • Affected Assets: Select the assets affected due to that particular incident.

  • Data compromised: Select Yes or No depending on if any data is found to be compromised as a result of the incident.

  • Damage Details: Write a brief detail of the damage. For example, OS corruption, hardware failure, reputation loss, etc.

  • Remediation Details: Suggest actionable steps for the remediation.

  • Implemented Remediation: Describe the remediation performed by the relevant department. (To be filled only when the incident is resolved and needs closure).

  • Root Cause Analysis: Provide details of Root Cause Analysis completed

After adding all the information to the Remediation step, click on the Create button to save changes. This newly created record will be displayed in the stream of the selected Disposition i.e. Alerts, Investigations, or Incidents.

Tree Graph

This tab visualizes and correlates artifacts within an incident with other modules. It is one of the most important features of SIRP which provides correlation to the SOC team in terms of occurrences of particular artifacts and the number of times they have been seen in other modules of SIRP.


SIRP helps define, prioritize and drive standardized incident response activities according to a standard workflow. It allows an organization to streamline incident analysis and response procedures in a workflow format, such that each step to remediate the incident is available for an analyst, such as:

  • Analysis

  • Containment

  • Eradication

  • Recovery

  • Post-Incident

This keeps security analysts on the same page with interactive incident management.
For example, without the availability of proper workflow, a newly hired analyst may take too much time or cause a human error, while investigating or closing an incident.

Standardized workflows help analysts gain greater visibility so that every member can be more effective individually and the team can be more efficient as a whole.

Moreover, an analyst can be assigned to tasks wherever their efforts are required.

To access workflows, go to the Main Menu, select Incident Management, and click on Incidents. Select the Task under Action column of the Incident.

Bulk Update

SIRP allows analysts to update the status of multiple incidents (alerts, incidents, and investigations) at once. It also provides the option to create custom tickets and update them.

Select multiple items and click on the Bulk Update button at the top left of the Incident Management module.

This will open a pop-up window.

Enter the fields:

  • Priority

  • Severity

  • Status

  • Disposition

  • Sub Disposition (if any)

  • Category

  • Assign to

  • Remediation Details

  • Comment

Click Save.


SIRP also provides the option to generate reports for a specified time period. To generate a report, click on the Generate Reports option that is available at the top of the Incident Management module tabs.

Select your desired time period and Disposition. Then click on the Generate button. The PDF report will be generated and opened in a new browser tab. From there you can save it on your machine.

You can also export the complete details in a PDF or Excel report by clicking on the Export button available at the top right corner of the details page.

Incident Tracking

Once an Alert, Investigation, or Incident is created, the relevant individuals from different departments can add comments, and SOC leads can assign workflow-based tasks by clicking on the View button available under the Actions column.

The Incident View page comprises different sections and tabs, which are discussed below:

Incident Description: This tab provides details associated with an incident. These may include the following:

  • Description

  • Damage details

  • Analysis summary

  • Subcategories

  • Owner/custodian

  • Estimated Recovery Clock

  • Attack Duration

  • Escalation Date

  • Detection Method

  • Data Compromised

  • Users Affected

  • Hosts Affected

  • Close Date

  • Attack Ended

Artifact: This tab lists all the artifacts/IOCs related to the incident. Analysts can use this tab to execute automation actions on any of the artifacts. The execution results are displayed at the bottom of the page.

Artifacts with supported actions will be highlighted with a dropdown option. To execute a new action, click on any artifact and it will display a list of applications with supported actions for the artifact. Mouse over the desired application and click on the desired action.

Affected Assets: This tab shows the list and details of all the assets tagged in the incident.

Remediation: This tab displays the remediation suggestions (provided at the time of creating an incident). Whereas, the implemented remediation section specifies the actual remediation done.

Comments: Users can use this section to communicate by adding comments. Users can also embed images and attach files with their comments.

Tasks: Depending on the phase (of the incident management lifecycle) at which the incident currently stands, and its category, tasks can be defined and assigned to a person or department either automatically or manually.

New tasks can be added by clicking on the Create Task button available on top within the Tasks tab.

Clicking on the button will open a popup with a form containing the following fields:

  • Name

  • Description

  • Start Date

  • Status: (Current status of the task)

  • Task Category: (One of the phases from the incident management lifecycle)

  1. Analysis

  2. Containment

  3. Eradication

  4. Recovery

  5. Post-Incident

  • Assigned: The person to whom this task is assigned.

  • Incident: It denotes the incident to which the task pertains.

  • Choose files: Users can add a relevant screenshot (if applicable).

Click on Create button to add the task to the task list.

Did this answer your question?