top of page

7 most things to consider when planning for incidents

Updated: Nov 14, 2023

  1. Purpose: Understand and have a clear purpose for each incident protocol . This is the foundation of the entire incident protocols that your will develop. It is important to know exactly why and what we are trying to achieve here.

  2. Have a framework before planning.  You should have a checklist, a framework, that will help you make sure that every angle of the organization is addressed. That the impacts of the events are evaluated and that actions and communications plans are built for each of the organization components, when applicable.  Above all, you want to maintain the integrity, security and sustainability of each of these elements: Individuals, Activities and services offered, Informational, Technological and material assets, Infrastructures/building, Communications, Reputation / Perception, Contracts (this point is in certain cases, transversal), Finances, Governance, regulations and environment, Legal. Lastly, we also need to check the Insurance protection/claim process.

  3. Organized (action plan + tools)

A clear understanding of the foundation, as we saw above, will serve as a solid foundation to build your incident response plan. Having a solid protocol will:

  • Demonstrate to stakeholders that your organization takes these types of events seriously

  • Provide a formal response structure and organized methodology to make sure that the right actions are taken

  • Make sure that the response follows the framework and meet the expectations of the organization and its stakeholders (the protocol/plan is built upon the framework) 

  • Make sure everyone is aligned towards the same objectives when the incident really happen

  • Make sure all the communications and reporting tools are available, validated and ready to use

  • Make sure it can be tested multiple times before the big day

  • Make easy adjustments to the protocol throughout the year

  • Have it audited when needed

Of course, the only way to make sure that everyone will do what they are expected to do is to have implemented an automated incident response platform.

4. Information (capture and continuous)

Information is key during an incident. You should, at least, make sure:

  • Your process allows additional pieces of information to get pumped in as they arrived. For example text, images and evidence. There should not be an additional human intervention needed to gather and centralize this information during or after the event. The system you use should allow everyone to provide additional information easily, at any time, from anywhere in any circumstances. Cobalt uses a chat module that gets triggered automatically when an incident is launched, where the alert launcher, each participant involved and whoever is allowed to monitor the situation will be joined automatically. 

  • That all the information pertaining to the event is centralized. Ideally, the entire conversation made thru the chat is placed automatically by the system in the incident report. 

  • The streams of data are connected and readily available. There are two types of feeds:

  1. Human feed. Think of who and how the information should reach you. The key here is to remove any friction between the event and your incident response. You want your system and you to capture the information as quickly as possible without any interference. For example, if each of your organization members has a mobile application that allows them to signify a situation on the spot, then you know that in a matter of seconds your protocol could be activated. If you make it easy for these people to report it you know you’ll maybe get more issues raised and more contextual data (like event description, images, location, etc.). What the person sees is what you will receive. If you maximize the number of people who have your app, that your solution is highly flexible, that it allows you to capture every detail and that it is user-friendly then you know that you initiate your response on good grounds.  Think quality, quantity and speed. Does your incident response mobile app allow your people to answer event-specific questions? Can it trigger automatically an incident protocol? Does it allow for participants to provide additional information during the event?

  2. External feed. Here you should be considering an integrated source (thru API) to your incident response platform. Think of all the systems and data that could deliver value during your incident response. Whether it's at the very beginning a) when you and your team need to assess the situation in order to determine if you should trigger the protocol, and 2) at any time during the event. 

5. Time (rapidity - each second counts)

When dealing with incidents each second counts. Your incident response platform should allow you to automate everything that can be automated. You should make sure that you optimize and save time at each phase of an incident response plan AND in between each step. Here are the different phases you should be considering improving if not done yet. 

6. Flexibility

If possible, the software you use should make your life easy. You should not have to deal with constraints. Ideally, the system will adapt to what you are trying to achieve and not the other way around. You should be able to provide a solution for dealing with incident to everyone in the organization. You should be able to:

  • Ask the question you want from the start and at any time during the incident

  • Share automatically the task you want with the right team and individuals

  • Send automatically the notification you want

  • Make sure some incidents can be triggered by some teams were other events don't

  • Make sure you can have some events by some members without giving them access to other events. For example, an HR event would not necessarily need to be seen by the team or individuals that are managing IT incidents.

That is why it is important to choose wisely when acquiring or subscribing to an incident response platform. Also, why not insist on checking if the provider listens to its client and develops and adapt features quickly to provide maximum flexibility.

For keeping track of. For collecting evidence. For KPI / data. For learning and improvement. Always think of the aftermath. What information will your management and stakeholders need in the report? If you have a clear idea, only then you will be able to make sure this information is captured during the incident. You should ask these same people what they would be looking for in the report for each type of incident. What type of questions do they expect their own stakeholders to ask. Make sure the system you use, if it does not automatically capture the information like the location of the alert launcher, makes it easy for everyone to provide accurate and on-the-spot (mobile?) information and updates.


Recent Posts

See All


bottom of page