Critical Incident Information All Security Teams Should Be Tracking

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 its 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.

Start with the Basics

For any incident that occurs, there is some basic information that needs to be tracked.

Incident Category

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

Severity

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.

Incident Owner

Who is the person (s) assigned to manage the incident and ensure that it moves through the appropriate stages to be closed?

Date and Time

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.

Incident Status

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.”

Description

Tell us what happened – what was the incident, where did it occur, who reported it, who was involved and what are the next steps.

Improving the Quality of Your Incident Data

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.

More About the Reporter

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.

Location, Location, Location

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.)

Who’s Involved?

Involvement is the tracking of something or someone that was involved in the incident including:

• Involved people (suspect, victim-witness etc.)
• Involved organization (vendor, customer, partner, law enforcement, organized crime etc.)
• Involved items (laptop, machine, server, IP etc.)

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 provide a greater ability to find connections between different incidents.

Losses and Recoveries

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.

Defining Narratives    

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. 

Including Additional Fields

Depending on the organization and the severity of the incidents, there may be a need to track additional incident information. A few examples include:

• Business Unit
• Incident Flags (i.e. weapon used, hate crime)
• Additional Responses (flags for police, EMS or fire involvement)
• Police file number
• Incident level (used to control access to sensitive incidents.)

Additional Incident Information to Track for Mature Security Teams

For more mature security teams, there is additional information that can be linked together to provide additional insight. This could include:

• Related incidents: It’s helpful to link together incidents that are related (i.e. multiple incidents that involve a specific criminal organization.)
• Cases: If one or more incidents escalate to a case, accessing relevant information it is critical to understand where investigators need to be assigned to do more analysis or collect any additional evidence.
• Tasks & Action Plans: For more complex incidents, the ability to assign tasks or create action plans linked to an incident can help to reduce the time to close the incident.
• Risks: For organizations that have implemented an Enterprise Security Risk Management function, it is helpful to link an incident to a specific risk. This along with links to business unit or location help the security department engage the wider organization to deploy resources and reduce overall risk.
• Root Cause Analysis: More mature teams will go a step further on complex incidents and perform a root cause analysis. These causes can be attached to the specific incident for future trending.

How to Keep Incident Reporting Simple

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 simply 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.