Technology Information& News


Conducting a Post-Mortem after a Security Incident

Once a security threat has been neutralized and damage control has been handled as best as possible, the incident is usually over for most employees. However, the work is far from over for chief information security officers. For CISOs, understanding how the incident happened is the first step in preventing a recurrence. As it stands, launching a post-mortem review is the best way to understand how a security incident occurred. As such, a post-mortem analysis needs to be part of every CISO’s incident response plan. A post-mortem can be effective in providing insight into how you can enhance your training, tools, and processes if it delves into the what, who, why, when and how. Here’s how you should conduct a post-mortem.

Complete an incident report

Document any information that can be used to prevent the occurrence of similar threats in the future. An incident report can even serve as an index of your security in terms of effectiveness. Not all of the data will apply to all incidents or organizations, but a good incident report should include most of the following:

  • The location of the device or system that was compromised
  • Date and time of the incident
  • Function of the compromised device or system
  • How the security threat was identified
  • The steps that were taken to neutralize the threat
  • The incident’s impact
  • The team involved in containing the threat and every piece of evidence collected

Image result for Conducting a Post-Mortem after a Security Incident

Analyze your response

When evaluating your incident response, you’ll want to consider the following questions:

  • How much time passed between identifying the security threat and finding a resolution?
  • Was it possible to identify the threat sooner?
  • Could you have identified the threat sooner?
  • How capable were your resources in handling the threat?
  • Could you have handled the response better, and how?
  • Had you automated some processes, would it have meant greater protection or improved responses?

Determine whether it was a random or targeted incident

In most cases, you can tell whether you suffered a random or targeted incident from the method of attack. Updating your security intelligence feeds in accordance with the most likely cause of the threat is important. Inform every relevant person about potential triggers and your system’s vulnerabilities. Pay special attention to policies that require improvement. Monitoring activities after the incident could prove beneficial because additional threats are usually launched soon after a targeted company contains the initial incident.

Identify preventive measures

Scorecards can help you evaluate your security, secure buy-ins across departmental lines, and establish new initiatives. Although companies can select varying metrics, you’ll want to consider the following:

  • Volume of alerts
  • Number or percentage of unpatched vulnerabilities
  • Number of false alarms
  • Volume of opened and closed incident tickets
  • Amount of time between identification and resolution
  • Average time from initial infection to detection
  • Inventory of unauthorized software, systems, and devices

Follow up

Planning for some additional activities might be necessary depending on your findings. For instance, you will need to provide your response team with additional training if your post-mortem shows they need it. On the other hand, automating a number of your response processes might be necessary if your team members overlooked a real threat because they were overwhelmed by false positives.


Although security incidents are not usually a pleasant experience, they are often a learning opportunity. You’ll be much better placed to prevent the occurrence of another incident if you analyze the initial threat. While newly implemented improvements may not help prevent every potential attack, you will be better prepared for the next security threat.

Leave a Reply

Your email address will not be published. Required fields are marked *