Understanding the Difference Between an Incident, a Complaint and a Risk Event

Have you ever stopped to think – what is the difference between a security incident and an HR incident? What about Legal vs Compliance? When is an incident a complaint? Even further, isn’t an incident a risk that has actually happened?

Categorizing these events can be difficult. Most have vague definitions, one event often leads to another, and there can be multiple teams involved in each incident. However accurately tracking these events is necessary to manage liability, comply with regulations and drive improvements across the organization.

Defining Event Categories

Before we dive in, let’s look at some commonly used definitions for each category.

Incident – An event (typically negative) that occurs at a specific date and time. It often follows the pattern of someone did something on this date at this time at this place.

Complaint – A complaint is typically not defined by the event, but rather by the fact that someone has complained. It is the act itself that makes something a complaint rather than the subject of the complaint.

Risk – There has been a lot of work done by ISO 31000, COSO, RIMS, OCEG and others to define what a risk is, but in its simplest form a risk references an event and its potential impact on something important.

Applying a Category Type to an Event

Unfortunately, there isn’t a straightforward guide on how to apply a category type to an event. Risk and security events aren’t one size fits all and the way that they’re categorized can depend on a variety of things such as company size and industry, how serious the event is and especially the knowledge of the person recording the event.

To break this down, let’s look at few examples of events and think about how a business might categorize them.

Scenario 1: An employee behaves aggressively with a customer

• Is this an incident? Yes, if serious enough, unlikely if it’s a general pattern of poor behavior
• Is this a complaint? Yes, but only if it was complained about.
• Is this a risk? Potentially, but likely part of a bigger customer-reputation risk

Scenario 2: A customer receives repeated calls ostensibly from their financial institution

• Is this an incident? Yes, likely multiple incidents
• Is this a complaint? Yes, likely one complaint.
• Is this a risk? Yes, and could also result in other risks like theft, fraud or account takeover

Scenario 3: A financial transaction is sent to the wrong party

• Is this an incident? Yes, but most organizations would call it a loss event (yes, that’s yet another term that means almost the same thing)
• Is this a complaint? Possibly, though unlikely unless the intended recipient complains
• Is this a risk? Yes

Scenario 4: An employee’s computer is compromised

• Is this an incident? Yes
• Is this a complaint? Probably not, but an action as a result of the compromise could result in a complaint, and this may be the way the incident is discovered.
• Is this a risk? Yes

You can see from these examples that events are incidents, complaints and risks all at the same time. Each of these examples highlights the subjectivity of the decision by the person who is reporting the event.

On a recent call a customer who is responsible for Business Continuity, Risk, Security, Facilities, InfoSec and Vendor Risk expressed this idea in perhaps the most succinct way I’ve heard  to date:

“Incidents are Incidents. Most of the information you collect is the same”

Does Time Affect Event Type?

One thing that you may have noticed in both categories and the examples above is the concept of time.  Considers whether the event has already happened or if it might happen in the future.

Here’s how one of our event examples might play out over time:

Which of these is the incident? When does the complaint happen? Which ones are risks?

You can see in this scenario that as we progress through time, individual events compound to become bigger risks, but there isn’t a specific line as to when that happens.

Still, incidents and complaints are typically about something that has happened or is currently happening. Whereas risks are more focused on what might happen in the future and what the potential impact could be.

However, just because an incident happened in the past, what’s to say it won’t happen again? Wouldn’t the fact that it happened once increase the probability of it occurring again? In this context, what do you call it? A potential incident? A risk event? What if the incident almost happened but was narrowly avoided? Those are typically referred to as “near-misses” but do they get consistently logged?

Who Owns the Event?

One further complication is to define and understand which team or individual owns the event based on the category selected. If we reflect on each of our scenarios above, can we pinpoint whether they are security incidents? HR? Safety? Finance? Customer Service? Many incidents involve two or three teams in different ways. This added layer further complicates the reporting process. If an employee wants to report something, they not only have to identify the event type, but also have to think about who the event should be reported to.

Documenting and Recording Events

Ok, now that we’ve painted the picture, you can see that it’s complicated, and we haven’t even discussed the various technology involved.

Most organizations have multiple systems each with their own use. They might have an incident, case, risk and complaint system. They span different topics and teams and produce separate reports. They cover both what happened already and what may happen in the future.

Incidents and complaints are the data shows what actually happened. Risks  tell us what might happen.  If these systems are disjointed, it’s nearly impossible for teams to make data- driven decisions and risk assessments. It is similarly difficult to understand potential downstream risks when looking at a single incident. Without a single integrated Incident and Risk Management system there is very little visibility to see the whole picture.

Why Your Organization Needs a Process for Handling Security and Risk Events?

Don’t make employees or customers guess at what they are reporting. To ensure that people continue to submit their concerns, make it simple. Provide multiple intake channels to a single repository that connects incidents with risks across the enterprise. Once you have the information, routing the event to the right team can be easily done with an intelligent triage process. 

How can Resolver Help You with Incident and Complaint Management?

Resolver offers a simple but powerful system that allows organizations to capture incidents, complaints and risks all in one place. Once an event has been logged it is tagged and categorized using our AI-based Intelligent Triage process and routed to the right team. Since information is easily linked together Incident, Complaint and Risk Managers can see the whole picture and move rapidly to respond to and recover from the event preempting incremental loses.