3 Biggest Mistakes to Avoid When Creating an Incident Management Program

Incident prevention is a major focus of every IT organization, as even the smallest “situation” has the potential to significantly damage a company’s reputation — a slippery slope to eroding client trust, hindering sales and chipping away at your customer base. 

Although it is not always possible to predict — and prevent — every potential threat, GRC teams can certainly plan and prepare for some of the most obvious threats, particularly situations relating to regulatory requirements, third-party risks, cybersecurity threats and operational disruptions. A well thought out incident management program that aligns with your overall GRC program and information security policies will help you mitigate the impact a situation may have on your business while minimizing harm to employees, customers and partners. However, this is often easier said than done. 

Here are the three biggest mistakes GRC teams make when creating an incident management program:

1. No Incident Management Plan

During our recent webinar How to Simplify State and Local Government Incident Management, we took a poll – and we discovered that two thirds of the respondents didn’t have a fully documented plan!

An incident management plan is the foundation of your program and will help you assess incidents to determine the potential risks and impact to your systems and controls. For instance, it will help you answer: Will a threat impact a single site or multiple facilities? Will any data be impacted and, if so, are there any government or regulatory organizations you will need to notify? How will you measure the full scope of impact? 

A fully documented incident response plan, along with a GRC tool to help you track all the activities related to the management of incidents, will help ensure that if and when you’re under the pressure of an incident, you can make the correct decisions and take the appropriate actions to bring the situation back under control quickly and with as little disruption to day-to-day activities as possible.

2. No Defined Roles

Every incident management plan should clearly define team roles and responsibilities. This is especially important if your organization has internal silos, for example, if each group has its own operational IT support team that will need to be involved in any incident response.

It’s important that everyone involved in an incident response knows in advance who will be coordinating communication with the various stakeholders and how they will be sharing updates. Also, you will want to identify who will be managing incident activities, as well as capturing data and evidence as appropriate.

3. No Review Cycle

Your incident management plan should be a living document, not a “one and done” item that is reviewed once and then put on a shelf somewhere, never to be looked at again. By including regular reviews as part of your incident management plan, you’ll be able to identify new opportunities for improvement, as well as emerging threats, and make updates as appropriate.

At the very least, you should be testing your general plan once a year and specific components to your plan more often. For example, you can institute a quarterly test that rotates between your organization’s various businesses, teams or siloes.

Running an incident management program means you must be able to effectively assess incidents to determine the impact to your systems, risks and controls. To do this well, you need an incident management plan that aligns with your overall GRC program and infosec policies, clearly defines team roles and responsibilities, and is regularly reviewed to identify opportunities for improvement.

 

To learn more tips on how to implement effective Incident Management programs, watch our on-demand webinar How to Simplify State and Local Government Incident Management.