What do you do if your information security incident response plan fails to meet key success factors?

Between well-structured incident response plans and the reality of events lies a chasm called "life happening." Do your part by testing your plan periodically through simulations and hiring specialized cybersecurity firms to have unbiased professionals test your environment. However, have a plan for when the plan fails. Include aspects such as managing your stress, minimizing the impact on the business, knowing your infrastructure – sometimes documentation may fail, but your deep knowledge of the business will enable you to make creative decisions to solve the problem. Always communicate! And value your team – an engaged team won't let go of your hand when the plan fails.

Pior do que um incidente de segurança da informação acontecer, é o seu plano de resposta falhar, entretanto, não é o fim do mundo. É preciso entender algo na segurança da informação que incomoda muita gente, a segurança da informação pode falhar e o plano de resposta pode não ser efetivo e não existir um culpado, e mesmo que existam culpados, não é a ação mais inteligente a criminalização dos mesmos. Respire, é momento de entender algumas coisas, por que o incidente ocorreu? E por que o plano de resposta não foi razoável? E o mais importante, quanto a empresa perdeu em negócio com essa situação. Agora elabore um plano para que esse incidente não ocorra mais, um plano de respostas mais efetivo.

Entendo que após o incidente, deve ser feita uma análise critica visando identificar onde o plano falhou, além de colher feedback das equipes envolvidas para obter insights sobre oportunidades de melhoria.

It is only possible to identify points of failure and improvements in incident response processes when we have to act on it. Therefore, it is necessary to recurrently test these plans to generate improvements and understand the flaws in the process. This way, we will have an evolution in the maturity of the process and the guarantee of protection for professionals when a real incident occurs.

It is common for the first development of an incident response plan to generate several problems and not be an assertive result, however it is essential that a first version is created so that through it we can modulate responses according to the organization's reality. In this sense, training both the execution of the plan and the evolution of professionals who work technically is essential for the document to evolve as well as the actions.

A security incident response plan must be updated on a recurring basis, either by updating contacts, considering the high turnover of professionals in the sector, or by adjustments and improvements through the evolution of the information security architecture and environment. It is essential that we review and integrate new environmental solutions, new segmentations and all period updates.

Responding to an incident can generate a trigger for connectivity with various tools, processes, technologies and areas. Therefore, it is essential to detect the necessary actions and review the tools used to validate whether they meet the necessary behavior during an incident response process. Often through these resources we identify the lack or problem regarding the availability of possibilities that a system offers us.

Resilience during an incident response is a fundamental point so that all technical controls and plan descriptions are met. This resilience will be a laborious process with people through learning, culture and appreciation of efforts. This is because it is essential that the people operating the plan have a strong mind to sustain the pressure exerted and outline their strategies accurately.