Post incident review

Based on the requirements of your business, a review of the origins and handling of security incidents is often needed.

The Post Incident Review functionality in ServiceNow provides many tools for automating, tracking, auditing, and simplifying this process.

These tools include:
  • Dynamic post incident questionnaires for collecting pertinent information about the incident.
  • A post incident report including an audit trail, if one was created.
  • Drafts of knowledge base articles from an incident.

Post Incident Review workflow

After the security incident has been resolved and is moved to the Review state, all users in the Request assessments field will be assigned a dynamic post incident questionnaire.

The questionnaire can be a helpful tool for gathering information about the handling of the security incident from various sources.

During 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. If you add new users to the list, they receive the questions when the record is saved. The security incident cannot be closed until all questionnaires have been completed. As each user complete the questionnaire, the post incident report is automatically generated (and regenerated) and displayed on the Post Incident Review tab.

But if you would rather gather the information yourself, empty the Request assessments field. The post incident report is generated and displayed on the Post Incident Review tab.

Post incident report

The final product of the post incident review is the post incident report. When closing the security incident, a PDF of the report is created and attached to the incident.

The post incident report documents the actions performed, by whom, and the reasons for doing them. The post incident report compiles all the information related to the security incident, as well as all assessment responses, into a concise record of the security incident lifecycle. Even if a questionnaire was not used, the post incident report provides valuable data, including:
  • Initial incidents that caused the security incident.
  • Change requests, problems, and vulnerabilities created or linked to the security incident.
  • Descriptions on the security incident.
  • Activity logs with all work notes, response tasks, and activities.

    [Optional] Audit log.

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

Table 1. Security incident report
Security incident report - summary

The Summary section above 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.

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

The Timeline 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 listed.

If an activity created an audit log, then work notes from that activity are included.
Audit trail example

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

Security incident report - findings
The Findings section lists the questions sent out, along with answers from each user. Some data can be generated from fields in the security incident, or from scripts gathering data from related records, such as the list of affected business services. If questionnaires were sent out during the post incident review, the post incident report is regenerated and assessment data in this section is recalculated.
Security incident report - resolution

The Resolution section describes how the issue was resolved. It lists the vulnerability records that were referenced, and identifies the change or problem created during the handling of this security incident. It also includes the Close code and Close notes fields under the security incident Closure Information tab.