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
- 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
This section identifies the security incident number, as well as other summary
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.
||This section identities the individuals who were assigned to and/or
updated the security incident, along with their titles or departments.
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
||This section lists the questions sent out, along with answers from each
||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.