Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.
  • London
  • Kingston
  • Jakarta
  • Istanbul
  • Helsinki
  • Geneva
  • Store

Post incident review

Post incident review

Based on the requirements of your business, a review of the origins and handling of certain security incidents may be required.

The Post Incident Response functionality in ServiceNow provides many tools for automating and simplifying this process, including:
  • a method for flagging a security incident for post incident review
  • dynamic post incident questionnaires for collecting information about the incident
  • an automatically-generated first draft of the post incident report that can be edited before it is finalized

Optimal post incident review workflow

If you are an agent or manager, you may decide anytime during the process of handling a security incident--through analysis, containment, eradication, and recovery--that the security incident requires additional review before it can be closed. Reasons for doing so might include:
  • it involves legal action
  • it requires public relations attention
  • it requires review by the next level up in management, or even board action
  • it may need to be documented for auditing reasons

So you flag the security incident for security incident review. The security incident now cannot be closed until a post incident report has been generated. If you want the security incident review to include a set of questions about the security incident to be sent to a specific group of users who worked on it, you should create the list as the security incident transitions to the Review state. The questionnaire can be a helpful tool for gathering information about the handling of the security incident from a number of sources, without having to chase people down or hold meetings. But if you'd rather gather the information yourself, simply leave the user list empty.

After the security incident has been resolved, it moves into the Review state. If you selected users to receive a questionnaire, each user is sent a notification with a link to the dynamic post incident questionnaire. The questions are filtered to apply to the security incident you are dealing with. During the course of the review, you can add more users to the list or remove existing users from the list, unless they have already started filling out the questionnaire. When you save the security incident, the new users receive the list of questions.

When all of the users have responded, the post incident report is automatically generated. If you decided to dispense with the questionnaire, ensure that all users have been removed from the list and click the Format Post Incident Report button to generate the first draft of the report. You can edit the report using the HTML editor until it reflects the level of information required, then transition the security incident to the Closed state. The report is complete and cannot be changed.

Post incident report

The final product of the post incident review is the post incident report. The post incident report is required to record the actions performed, the reasons for doing them, and lessons learned. The post incident report compiles all of the information related to the security incident, as well as all assessment responses if one is performed, into an initial draft that you can then edit.

If the report was generated by clicking the Format Post Incident Report button without sending out a questionnaire, an initial post incident report is assembled. If a questionnaire was sent out, those results are included, along with the percentages of users who provided each answer. But even if a questionnaire was not used, the post incident report provides valuable data, including:
  • the initial incidents that caused the security incident
  • changes, problems, and vulnerabilities created or linked to the security incident
  • a description on the security incident
  • the entire activity log with all work notes, response tasks, and activities

The following table describes the components of the security incident report and identifies where the information originated.

Table 1. Security incident report
Section Description
Security incident report - summary

This section identifies the security incident number, as well as other summary information.

This information comes from the Short description and Assigned to fields in the security incident, and the Close notes and Lessons Learned fields under the security incident's Closure Information tab.

Security incident report - team
This section identities the individuals who were assigned to and/or updated the security incident, along with their titles or departments.
Security incident report - timeline

This section lists, in chronological order, all events recorded for the security incident, from creation (in this example, it was created from an Incident) to the review state. All subtasks created in the resolution of the issue are also lists.

This information comes directly from the security incident's work notes entered in the Activities tab.

Security incident report - findings
This section lists the questions sent out, along with answers from each user.
Security incident report - resolution
This section describes how the issue was resolved, lists the vulnerability records that were referenced, and identifies the change or problem created during the handling of this security incident.