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 Response functionality in ServiceNow provides many tools for automating, tracking, and simplifying this process, including dynamic post incident questionnaires for collecting pertinent information about the incident and an automatically-generated post incident report, as well as automatically generated 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 a number of sources, without having to chase people down or hold meetings. 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. 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 questionnaires are completed by each user, the post incident report is automatically generated (and regenerated) and displayed on the Post Incident Review tab. But if you'd rather gather the information yourself, simply empty the Request assessments field. The post incident report will be 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. The post incident report documents the actions performed and the reasons for doing them. 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 a concise record of the security incident's life cycle. Even if a questionnaire was not used, the post incident report provides valuable data, including: the initial incidents that caused the security incident change requests, 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 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. The Incident Team section identifies the individuals who were assigned to and/or updated the security incident, along with their titles or departments. 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 lists. This information comes directly from the security incident's work notes entered in the Activities tab. The Findings section lists the questions sent out, along with answers from each user. Some data may 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. The Resolution 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. It also includes the Close code and Close notes fields under the security incident's Closure Information tab. Note: If there are any post incident review assessments that have not been completed for the security incident, the security incident cannot be closed, and therefore, the Resolution section will not include closure information. Perform a questionnaire-based post incident reviewEither during security incident creation or when you are working with an existing security incident, you may decide that a review of the security incident is needed to describe what happened, to help determine why the incident occurred, and identify how it can be avoided or handled in the future. Post incident review questionnairesIf you decide to use a questionnaire as part of a post incident review, a list of questions relevant to the security incident is sent to a user-defined list of users, and their responses are automatically formatted into a post incident report.