Incident Classification Fully Examined: Best Practices and How-To's

Incidents are an inevitable part of business operations and are not all created equally. That's where incident classification comes into play.

In this article, we will explain classification and provide actionable items to help you improve your incident management processes.


Incident Classification

What is Incident Classification?

An incident is any disruption to normal operations. For example, problems such as hardware failure or a code error that cause an outage. Therefore, incident classification is the process of organizing incidents based on the service area affected so they are easily measurable. Once properly classified, an incident response procedure may proceed to remedy the situation.

Why is Incident Classification Important?

Incident classification is important because it's the first step to solving a problem. Classification kickstarts the necessary process. Without it, it may be obvious that something is afoot in your system, but the severity may be unknown. Or worse, the playbook for responding to the incident hasn't been written.

Some benefits of incident classification include:

  • Triage: The severity of the problem determines which incident receives the highest priority, who is involved, and how they intervene. In the case of simultaneous incidents, triaging and responding to major incidents first are critical components of the incident management process.
        
  • Personnel response: Proper incident classification will identify which personnel on the incident management team are needed and which are not.
     
  • Procedure response identification: There's a procedure, or playbook, for every incident. Effective classification ensures service managers deploy the most effective playbook first.

  • Impact measurement: Having different classifications for incidents allows service teams to measure the fallout from each incident. This helps them strategically plan for future incidents.
     
  • Pattern identification: With proper classification, you can analyze patterns to create preemptive fixes for future incidents and improve your problem management process. 

Best-Practice Types of Incident Classification

When developing Incident Classification protocol, hierarchy is essential. Each classification decision funnels down to more specific options. A carefully designed set of classifications will simplify the process of entering incidents and mitigate misclassification. The hierarchy also relates each category to a specific incident resolution playbook.

Here's an example of a set of classifications, with a related action and the personnel required to resolve an Email incident:

Example Incident Classification for Malfunctioning Email

Category

  • Adobe acrobat

    • Error

    • Install

  • MS Office

    • Error

    • Word

    • Excel

  • Windows

    • Crash

    • Upgrade

  • Email

    • Cannot Connect

    • Email Too Large

    • Error

Category → Email → Cannot Connect

Impact

  • Critical

  • High

  • Moderate 

  • Low

Impact → Low (affecting a few people)

Severity

  • 1 - Critical

  • 2 - Major

  • 3 - Minor

Severity → Minor (because of low impact)

Priority

  • High

  • Medium

  • Low

Priority → Medium (due to the importance of a properly functioning email)

Root Cause

  • Hardware Issue

  • Software Issue

  • Training

Root Cause → Software Issue (it was updated to a new version)

Action

Troubleshoot and update email domain

Required Personnel - System engineering

Categories

Hierarchical categories are standard practice with an incident classification scheme. The choice in the first menu relates to a subset of categories in the next menu. And so on.

The type of support operations will often have differing category listings.  For example, the following might be for an IT help desk:

  • Adobe

    • Errors

    • General

  • Applications

    • Acrobat Reader

    • Excel

    • Outlook

      • Sending Email

      • Receiving Email

    • Word

      • Create Table of Authorities

      • Edit Table of Authorities

      • Lost Document

  • Backup/Restore

    • Add server to backups

    • Add workstation to backups

    • Full server restore

    • Selective restore

  • Hardware-Desktop

    • Camera

    • Keyboard

    • Memory

    • Monitor

  • Network

    • Hub

    • Leased Line

    • Router

    • Software

  • Printing

    • Add Printer

    • Drivers

    • Paper Jam

    • Spooler

    • Toner

  • Training

    • Knowledge Base Request

    • New Hire Class

    • Remote Access

    • Software

And then this might be for a call center:

  • Account and Billing

    • Account Management

      • Create New Account

      • Update Account Info

      • Close Account

    • Billing Inquiries

      • View Charges

      • Understand Invoice

      • Request Billing History

  • Technical Support

    • Login Issues

      • Forgot Password

      • Locked Account

      • Two-Factor Authentication Problems

    • Product Malfunction

      • Software Bug

      • Hardware Failure

      • Connectivity Issues

    • System Performance

      • Slow Performance

      • Downtime/Outage

      • Feature Not Working

  • Orders

    • Shipping Problems

      • Late Delivery

      • Wrong Item Shipped

      • Shipping Address Error

    • Returns and Exchanges

      • Start Return

      • Exchange Request

      • Return Status

Each describes the natures of the request for the different types of support offered or issues to track.

Impacts

The impact of an incident is related to its severity. More severe incidents will affect a greater number of people. For example, a data breach in a hospital's electronic medical records system can affect thousands of patients. On the other hand, a poorly performing software may only impact a handful of employees and require a simple software update. 

Impact's Effect on Technical Support Resources

Incidents with a greater impact have a higher priority. They can also require more technical support to solve the issue. The amount of technical support needed to remediate the incident will depend on the assigned roles outlined in the incident management playbook. 

Some examples of just how widespread this effect can be are in how many different groups can be affected, such as:

  • HR
  • Field services (third-party)
  • Marketing department
  • Desktop engineer
  • System engineer

IT professionals are almost always involved in solving an incident. However, depending on the issue, other in-house departments or even third-party vendors may become involved to respond to the incident and prevent it from recurring in the future. 

Severity Levels

Further classifications for the severity of the incident help dictate how widespread the problem is. Well-defined severity levels provide an answer to the question, "How much impact does an incident have on users?"

In incident management processes, severity levels measure the impact a specific incident has on business operations. In most cases, the lower the numerical value of the severity level, the more impactful the incident. This is similar to the Defense Readiness Condition (DEFCON) used by the U.S. military. In this system, the lower the DEFCON rating, the higher the tension and potential risk of a military event. And the more ready the military is to respond.

  • With incident classification, severity level one indicates an incident with an extremely wide impact. Critical incidents include security breaches and loss of sensitive data.
  • Severity level two indicates a major event with a potentially significant impact. For example, when a client-facing service is disabled or when a critical function is not functioning.
  • Severity level three indicates a minor event, low severity, and little overall impact. Low severity incidents, such as system glitches, can cause inconvenience to your customers.

Examples of Severity Levels

Severity

Description

Example

1

A critical incident with high severity and impact

  • Customer data loss

  • Privacy and confidentiality is breached

2

A major incident with medium severity and significant impact

  • A core function is significantly impacted

  • Customer-facing service is disabled

3

A minor incident with low severity and low impact

  • Minor inconveniences

  • Performance degradation

Assigning severity levels to incidents is important because it allows you to understand the potential impact of the event. In addition, the more defined your severity classification is, the more efficiently your incident management team can respond to the problem.

On the other hand, without well-defined severity levels, it is more likely you'll spend time defining and explaining the problematic nature of incidents instead of rapidly resolving them.

Priorities

While Severity is a measurement of Impact, Priority is a measurement of urgency. Priority levels help you triage and answer the question, "Which issue needs to be fixed first?"

There are times when the severity and priority of a specific event align. For example, a high-severity incident that can disable your company's operations for the day will also be a high priority. 

However, sometimes severity and priority do not align.  For example, you discover a typo on one of your web pages.  A simple typo is not very severe because the web page can still function. However, it appears unprofessional and negatively impacts the credibility of your business. Therefore, fixing the typo may be a high priority to preserve reputation. 

Both Severity and Priority levels are essential for efficient incident management. The two measurements help you define the importance of an incident, determine who should handle it, and outline the appropriate course of action. 

However, high severity doesn't automatically escalate an incident to the top of the priority list, and high priority doesn't always mean a catastrophic incident occurred.

Root Causes

Every incident has an origin, or Root Cause. Classifying the root cause is an important step in identifying a solution. Knowing the root cause can also help develop a prevention strategy for future incidents.

Some examples as noted above might include:

  • Hardware issues
  • Software issues
  • Lack of training

Or another list for customer service might be:

  • Mail carrier issues
  • Weather delays
  • Incorrect billing

Human-related root causes are often honest mistakes. But they may also reveal inadequate training or misallocation of responsibilities.

Learn more from our article on Root Cause Analysis (RCA), and download our free 5-Why's RCA support tool.

7 Steps for How To Develop Incident Classifications

As we mentioned above, problems are an inevitable part of doing business. However, not every problem should elicit the same response. To classify incidents when they inevitably occur, it's essential to consider five key factors. 

  • The size of your incident response team
  • On-call schedules of additional IT personnel who may need to be involved
  • High and low-traffic times for your service
  • The frequency and volume of incidents
  • The kinds of metrics that will need to be tracked

In addition, when defining steps for incident classification, not every business handles incidents in the same way. Therefore, it's essential to define categories, including severity and priority levels, that are tailored to your organization's needs. The following are recommended steps you can take to categorize your incident management processes.

  1. Create High-Level Categories

    • Use data from recent incident activity (e.g., service tickets) to identify categories
    • A good starting point is 10 to 15 categories
    • If there are incidents that do not fit, adjust the categories or create an "Other" category
  2. Determine Impacts

    • This level offers insight into what is occurring in each incident
    • Identify who can be impacted by incidents: Customers? Employees? Or both?
    • Determine the organizational needs and the personnel required to respond to various incidents
  3. Configure Severity Levels

    • Decide on severity levels based on the magnitude of the problem
    • Critically severe incidents receive a lower numerical classification, and minor incidents receive a higher numerical classification
  4. Decide on Incident Priorities

    • Priority is assigned based on the incident's severity
    • Priority classifications allow you to strategically triage a multitude of problems over time
    • Consider nuances (i.e., severe incidents don't necessarily require high priority)
  5. Establish Root Cause

    • Determine whether the cause of the incident correlates with system, human, or environmental factors
    • If necessary, create more precise sub-classifications for the three main causes
    • Robust root cause classification and analysis allows your teams to plan preventative measures
  6. Test the System

    • After creating each of the above, it's time to go live
    • Gather information on how the drafted classification is working
    • Measure important metrics and KPIs, such as overall response times, first-contact resolution rates, and handle time

  7. Improve the System

    • Analyze any "Other" designations to determine which of them need to be added to the system
    • Once you've organized them, it's best to eliminate it from the classification hierarchy
    • Reorganize severity, priority, and impact classifications to better accomplish KPIs
    • Hone in on problematic root causes to prevent them from occurring again in the future
    • The goal is to improve the classification by changing the hierarchy scheme often 

Best Practices for Determining Incident Classifications

Every organization is different, the products and services they offer are unique, and the customer base is nuanced. Therefore, every incident classification system is different. There is no perfect classification.

That being said, there are some best practices you can implement to ensure you are defining a classification system that helps your organization excel.

  • Think About What Different Responses Could Be Necessary

    Each classification of an incident should relate to a specific incident response. In addition, you want to consider which personnel should be contacted for incidents in specific service areas. Establishing lines of ownership will help incorporate the most effective personnel more rapidly.

  • Tag Incidents With Keywords

    Tagging incidents with keywords can help diversify incidents that fall within the same service area. Keyword classification also helps create connections to other incidents in different categories, which can aid in identifying patterns.

  • Create Tiers of Severity for Impacted Areas

    Assigning severity levels will help define who needs to be included. Severity levels also highlight which resources need to be deployed and which escalations need to be imlemented. Examining your Service Level Agreements (SLA) can give insight into when escalations need to occur.

  • Assign Key Performance Indicators (KPIS) to Incident Classifications

    KPIs are vital for reliably tracking incidents in the various ways they are classified. Likewise, tracking incidents is essential for measuring progress toward accomplishing KPIs. KPIs should be objective so that any incident response team member can understand the relationship between an incident and the KPI consistently.

  • Integrate Classifications Into a Larger Incident Response Playbook

    All classifications should be directly integrated into specific response playbooks. This includes automatic alerts to notify required personnel. Therefore, anybody who picks up the playbook can understand how to remedy the situation. This also includes automating certain responses. Automation can begin to execute solutions before human personnel are involved, thereby speeding up response time and consistency.

  • Create Incident Documentation

    Throughout an incident, from start to finish, create documentation for review later. Establish standards for the details that must be included in documentation, depending on the incident classification.

  • Review and Revise

    Incidents are inevitable. And unfortunately, so are mediocre responses to incidents (and even complete failures). That's why routine reviews of your incident response processes are critical for improving business operations.  

    Ask questions like:

    • Could there be clearer metrics to classify incidents?
    • Should the response playbook be changed?
    • Which services have the highest volume of incidents?
    • Where and when are the most severe incidents occurring?
    • How does the speed of resolution metrics compare to the severity level?

    You can gain valuable insights from analyzing the responses to these questions.

How the Right Software Can Help Your Incident Management

Efficient incident management is largely dependent on the software you deploy. The better curated the software is for IT management, the better your personnel can resolve issues. And the happier your customers will be. 

In this section, we aim to highlight the critical characteristics that powerful IT management software should possess and how modern software can benefit your business.

  • Rapid Onboarding and Expert Support

    Onboarding new software should make your business operations easier, not harder. It should be intuitive to use but also contain helpful information should you require further assistance. There should be no need for coding, programming, or expensive consultants.

    Giva's software includes extensive training resources:

    • Video tutorials
    • Self-paced tours
    • Quick-start guides
    • FAQs

    In addition, Giva's products come with free setup assistance during your 30-day trial and beyond, guided by USA-based product experts.

  • Artificial Intelligence (AI) for Automating Certain Tasks

    Giva's AI Copilots can be powerful partners that work alongside your IT personnel to help execute tasks that can be automated, such as:

    • Scribe data and communication, and format it into smart workflows
    • Notify the correct personnel
    • Automatically trigger alerts
    • Activate automated runbooks to enhance incident responsiveness
  • HIPAA/HITECH Compliance

    Security and compliance standards are paramount for avoiding severe incidents such as cyberattacks, data breaches, and malware. Giva's HIPAA Compliance adheres to stringent parameters to keep your data secure and defend against significant threats. It's included in all editions at no additional cost and covered by a cyber liability insurance policy.

  • Data-Rich Dashboard

    A highly visual and real-time dashboard is a necessary tool for assessing the current state of your incident management processes. In real-time, you can identify critical issues and areas of weakness. You can rapidly detect trends, problem-solve, and execute timely interventions. 

    Giva's IT Service Management Software dashboard is streamlined for speed and simplicity, and customizable to display the data that's most important to your business. 

Improve Incident Classification, Improve Your Business

There's no such thing as a perfect business. Incidents will occur. The faster you can solve those problems, the better you can run your business.

The speed and quality of your incident response will depend on a robust classification system that dictates severity levels and assigns priority. From there, the necessary personnel equipped with the proper playbooks can respond and remedy the situation.

Let Giva Help Streamline Your Incident Management

Giva's IT Service Management and Customer Service ticket management software offers an intuitive workflow, with automations, and a customizable dashboard so you're in control. With the best in reporting, including tracking incident classifications, keep management informed and analyze results to better your support

Get a demo to see Giva's solutions in action, or start your own free, 30-day trial today!