By Will Anderson Modified April 17, 2020
The key to reporting for security teams is to start with good quality data. There are many tactics that can help you focus on what data will have the most impact in order to provide meaningful insights, but first you and your team need to clearly define what information you should be actively tracking as part of your incident management process.
Every business has their own unique incidents, which means that unfortunately, there isn’t a one-size fits all approach to apply when it comes to creating an incident management program. There are several categories that should be considered when developing an incident tracking process.
For any incident that occurs, there is some basic information that needs to be tracked.
This could be a single category (a broad theme to segment related incidents), or it could include a subcategory (a more specific segment), either way, it is critical to keep this simple. Categories should be driven by reporting. Team should consider what level they will want to see trends. As you consider your categories keep in mind that different data is required to be tracked for different incident types, (what you track for a slip and fall will be quite different from what you track for internal fraud) which will then determine the associated workflow that gets triggered.
A critical element of resource allocation is to measure the severity of each incident. Resources should be allocated primarily to manage and reduce more severe incidents.
Who is the person (s) assigned to manage the incident and ensure that it moves through the appropriate stages to be closed?
This can be as simple as a single date of when the incident happened, or as complex as tracking the start and end date, if there is an investigation or case opened as a result of the incident. It all depends on how granular the report will be.
Where is the incident in the workflow process? This will vary depending on how complex your organization’s workflow is, but this could be “open, in review, investigation, etc.”
Tell us what happened – what was the incident, where did it occur, who reported it, who was involved and what are the next steps.
Now that you’ve documented the basic information for an incident, there are additional things you can track to improve the quality of your data, and, ultimately, allow you draw more meaningful insights from your reporting.
At a minimum, capturing where and if possible, who submitted the incident should be required. This helps your team identify correct contact personnel if more information is necessary to proceed. If the submissions are processed through an incident submission portal, it could be helpful to collect more specific information about the location and/or person reporting so that reporting can be done on the volume of incidents received per channel.
Of course, it’s critical to know where the incident took place. This could simply be the address, or it could go further and track specific locations within the organization’s office (floor 1, reception, warehouse etc.)
An involvement is the tracking of something or someone that was involved in the incident including:
In simple processes, you may only need to track this information in a single field (Fred was the witness, Nancy the suspect) but you can also get very complex and track attributes of these involved people, organizations and items. Tracking this in a system as linked people, items and organizations provides a greater ability to find connections between different incidents.
Tracking losses is a critical component for building a business case for additional security resources. It can be as simple as putting a single value on the incident or as complicated as tracking a list of losses and recoveries tied to specific assets or items.
Narratives are most commonly used for witness or suspect statements. If narratives are going to be submitted as evidence to law enforcement, security teams should go beyond simply tracking, and ensure that there is a workflow built that allows the team to lock the narrative from future changes, or at least have an audit trail.
Depending on the organization and the severity of the incidents, there may be a need to track additional incident information. A few examples include:
For more mature security teams, there is additional information that can be linked together to provide additional insight. This could include:
Effective incident reporting is generally a tradeoff between ease of use and depth of data submitted. If your incident management program is still in the early stages, start your incident tracking as simple as possible. The more information required from users, the more likely it is that mistakes will be made. Start with the information you need reporting and the data required to adequately address incidents. If you find gaps, add more steps.