Do I Need An Incident Management Process?
Does your organization have a defined incident management or problem management process? If not, it may be a good idea to spend some time formally defining your incident management process and plan for how your technology and cybersecurity teams respond to incidents. Having even a simple incident management process helps reduce confusion about who is responsible for what and how high of a priority an incident may be, things you want to avoid in the heat of an incident response.
Implementing an incident management process starts with the following:
- Define what constitutes an incident, which typically means something is broken and needs to be fixed, vs. a problem which is the underlying root cause of the incident.
- Define what the different levels of severity of an incident are in your company. Severity can range from minor interruption (i.e. a printer isn’t working) to a major disruption (our network is down). You may also want to define the severity based on who is affected – is it only corporate back-office functions or is engineering or machinery involved? Is the incident customer-facing or internal?
- Define what happens once an incident is identified. Who picks up and responds to the incident first, is it your technology team or vendor helpdesk? Where or who should they go to next if things get more technical?
- Define how you will track incidents. Is there a ticketing system, or is it just a spreadsheet? Or are things better done over e-mail?
- Define who needs to be notified of an incident depending on the level of severity, and put together some communication templates depending on the intended audience
There’s no need to overcomplicate it or define more structure than is really needed by your company, and there is no one-size fits all approach. However, if you haven’t had a conversation to answer any of the questions above (or if you haven’t in a while), it’s a good time to revisit this topic and ensure your teams responding to incidents are on the same page.
This article is a good read on implementing an incident management process if you’re doing so for the first time.