Have you ever considered the differences between a security event and an HR occurrence? What about legal vs. compliance issues? Or when a corporate security incident turns into a complaint? Isn’t a situation a risk that has already manifested?
Understanding these distinctions is vital for effective security incident management. Categorizing a physical security incident, complaint, and enterprise risk event can be difficult. Each has vague definitions: One event often leads to another, and multiple teams can be involved in each situation. However, accurately tracking these events is necessary to manage liability, comply with regulations, and drive improvements across the enterprise.
Categorizing Incidents, Complaints, and Risk Events for Better Business Operations
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
Applying the correct category to an event in incident management can be challenging. Business incidents, whether related to compliance, operations, or security, require careful consideration. Factors such as company size, industry type, the severity of the event, and the experience of the person reporting all play a role in how an incident or risk event is categorized. Ensuring accurate categorization is crucial for effective risk management and compliance across your organization.
To break this down, let’s look at a few examples of events and think about how a business might categorize them.
Scenario 1: An employee behaves aggressively with a customer
- Is this a security incident? Yes, if it is serious enough, but it is 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, it’s part of a bigger customer-reputation risk
Scenario 2: A customer receives repeated calls ostensibly from their financial institution
- Is this a security incident? Yes, likely multiple incidents.
- Is this a complaint? Yes, it’s likely a complaint.
- Is this a risk? Yes, and it 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 a security 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 a security incident? Yes.
- Is this a complaint? Probably not, but action resulting from the compromise could result in a complaint, and this may be how 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 a very succinct way:
“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 individual events compound to become bigger risks as we progress through time, 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
It should now be clear that these situations are complicated — and we haven’t even discussed the various technologies involved.
Most organizations have multiple systems, each with its own use. They might have security incident, case management, risk, and complaint systems, spanning different departments and producing distinct reports. These systems often cover both past occurrences and potential future events.
The incidents and complaints data show 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
When it comes to incident reporting, employees or customers shouldn’t have to guess what they must report. 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 Resolver helps with security incident and complaint management
Navigating the intricacies of incidents, complaints, and risk events underscores the complexity of modern business operations. Scenarios like the ones above are rarely isolated, often overlapping and interweaving to create multifaceted challenges. However, Resolver’s Security Incident Management Software efficiently collects, analyzes, and synthesizes vast amounts of information.
Our solution empowers organizations to discern the true nature of each occurrence — whether it be an incident, a complaint, or a risk event — and make informed determinations. Security Incident Management Software streamlines processes while also enhancing the ability to identify patterns, anticipate potential threats, and proactively implement strategies to mitigate risks.
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 rush to respond to and recover from the event, preempting incremental losses.
