Création de protocoles d'incidents - Les 7 éléments à considérer

1. Objectif : Comprendre pourquoi et se donner un objectif clair pour chaque protocole d'incident. C’est le fondement de l’ensemble des protocoles d’incident que vous développerez. Il est important de savoir exactement pourquoi et ce que nous essayons de réaliser ici.

2. Établir un cadre avant de se lancer. Vous devriez disposer d’une liste de contrôle, donc d’un cadre, qui vous aidera à vous assurer que tous les aspects de l’organisation et de sa communauté soient pris en compte. Que les impacts potentiels des incidents/événements soient évalués. Que, le cas échéant, des plans d'actions et de communications soient construits pour chacune des composantes de l'organisation. Vous souhaitez avant tout maintenir l'intégrité, la sécurité et la pérennité de chacun de ces éléments : Individus, activités et services offerts, actifs informationnels, technologiques et matériels, Infrastructures/bâtiment, Communications, réputation/perception, Contrats (ce point est dans certains dossiers, transversaux), Finances, gouvernance, réglementation et environnement, juridique. Enfin, nous devons également vérifier le processus de protection/réclamation d’assurance.

3. Organisé (plan d'action + outils)

Une compréhension claire des fondements, comme nous l’avons vu ci-dessus, constituera une base solide pour élaborer votre plan de réponse aux incidents.

Développer un protocole d'incident solide permettra de:

• Démontrez aux parties prenantes que votre organisation prend ce type d’événement au sérieux

• Fournir une structure de réponse formelle et une méthodologie organisée pour garantir que les bonnes actions sont prises

• S'assurer que la réponse (à l'incident) suit le cadre et répond aux attentes de l'organisation et de ses parties prenantes (le protocole/plan est construit sur le cadre)

• S'assurer que tout le monde est aligné sur les mêmes objectifs lorsque l'incident se produit réellement

• S'assurer que tous les outils de communication et de "reporting" sont disponibles, validés et prêts à être utilisés

• S'assurer qu'il peut être testé plusieurs fois avant le grand jour

• Apporter des ajustements faciles au protocole tout au long de l’année

• Le faire auditer si nécessaire

Bien entendu, la seule façon de s’assurer que chacun fera ce qu’il est censé faire le moment venu est d’avoir mis en place une plateforme automatisée de réponse aux incidents.

4. Informations (sur le fait et en continu)

L’information est essentielle lors d’un incident. Vous devez au moins vous assurer que :

• Votre processus permet à des informations supplémentaires d’être introduites au fur et à mesure de leur apparition. Par exemple du texte, des images et des preuves. Aucune intervention humaine supplémentaire ne devrait être nécessaire pour recueillir et centraliser ces informations pendant ou après l’événement. Le système que vous utilisez doit permettre à chacun de fournir des informations complémentaires facilement, à tout moment, de n'importe où et en toutes circonstances. Cobalt utilise un module de chat qui se déclenche automatiquement lorsqu'un incident est lancé, où le lanceur d'alerte, chaque participant impliqué et toute personne autorisée à surveiller la situation seront automatiquement réunis dans un même canal.

• Que toutes les informations relatives à l'événement soient centralisées. Idéalement, l’intégralité de la conversation effectuée via le chat est automatiquement sauvegardée, par le système, dans le rapport d’incident.

• Les flux de données sont connectés et facilement disponibles. Il existe deux types de flux :

1. Information provenant de l'interne. Pensez à qui et comment les informations doivent vous être transmises. La clé ici est d’éliminer toute friction entre l’événement et votre réponse à l’incident. Vous souhaitez que votre système et vous capturiez les informations le plus rapidement possible sans aucune interférence, aucun délai. Par exemple, si chacun des membres de votre organisation dispose d’une application mobile qui lui permet de signaler une situation, alors vous savez qu’en quelques secondes votre protocole pourrait être activé. Si vous permettez à ces personnes de le signaler facilement, plus d'évènements seront soulevés et vous récoletrez plus de données contextuelles et statistiques (comme la description de l'événement, les images, le lieu, etc.). Ce que la personne voit, c'est ce que vous recevrez. Si vous maximisez le nombre de personnes qui possèdent votre application, que votre solution est très flexible, qu'elle vous permet de capturer chaque détail lors d'incidents et qu'elle est conviviale, alors vous savez que vous déclencherez votre réaction sur de bonnes bases. Pensez qualité, quantité et rapidité. Votre application mobile de réponse aux incidents permet-elle à vos collaborateurs de répondre à des questions spécifiques à un événement ? Peut-il déclencher automatiquement un protocole d'incident ? Cela permet-il aux participants de fournir des informations supplémentaires pendant l’événement ?

2. Information provenant de l'externe. Ici, vous devriez envisager une source intégrée (via l'API) à votre plateforme de réponse aux incidents. Pensez à tous les systèmes et données qui pourraient apporter de la valeur lors de votre réponse aux incidents. Que ce soit au tout début a) lorsque vous et votre équipe devez évaluer la situation afin de déterminer si vous devez déclencher le protocole, et 2) à tout autre moment de l'événement.

5. Temps (rapidité – chaque seconde compte)

Lorsqu’il s’agit d’incidents, chaque seconde compte. Votre plateforme de réponse aux incidents doit vous permettre d’automatiser tout ce qui peut l’être. Vous devez vous assurer d'optimiser et de gagner du temps à chaque phase d'un plan de réponse aux incidents ET entre chaque étape. Voici les différentes phases que vous devriez envisager d'améliorer si ce n’est pas encore fait.

6. Flexibilité

Le logiciel que vous utilisez devrait vous faciliter la vie. Vous ne devriez pas avoir à faire face à des contraintes. Le système devrait s’adapter à ce que vous essayez d’atteindre et non l’inverse. Vous devez être en mesure de fournir une solution pour gérer les incidents à tous les membres de l'organisation. Vous devriez, entre autres, être capable de:

• Pose des questions aux parties prenantes (et obtenir des réponses instantanément) dès le début et à tout moment pendant l'incident

• Assigne automatiquement les tâches que vous souhaitez avec la bonne équipe et les bons intervenants

• Envoyer automatiquement la/les notification(s) souhaitée(s)

• Vous assurer que certains incidents peuvent être déclenchés par certaines équipes alors que d'autres événements ne le sont pas.

• Vous assurer que vous pouvez organiser certains événements pour certains membres sans leur donner accès à d'autres événements. Par exemple, un événement RH ne doit pas nécessairement être vu par l'équipe ou les personnes qui gèrent les incidents informatiques.

C’est pourquoi il est important de bien choisir lors de l’acquisition ou de l'abonnement à une plateforme de réponse aux incidents. Aussi, pourquoi ne pas insister pour vérifier si le prestataire est à l’écoute de son client et développe et adapte rapidement des fonctionnalités pour vous offrir une flexibilité maximale. Le contexte et les incidents évoluent rapidement, les plateformes doivent en faire tout autant.

7. Rapport

Pourquoi?

• Pour garder une trace de tout...vraiment tout!

• Pour recueillir des preuves.

• Pour KPI/données.

• Pour apprendre et se perfectionner.

• Pensez toujours aux après-coups. Qu'est-ce que peut avoir engendré cet événement. Quelles conséquences en découlent.

• De quelles informations votre direction et vos parties prenantes auront-elles besoin dans le rapport ?

• Si vous avez une idée claire de ce qui pourrait être nécessaire des suites de cet incident, alors seulement vous pourrez vous assurer que ces informations sont bien capturées lors de l'incident.

• Demandez aux parties qui seront potentiellement impliquées des suites de l'incident, ce qu’elles rechercheront (ex.: preuves pour enquête éventuelle) dans le rapport pour chaque type d’incident.

• Quels types de questions s’attendent-ils à recevoir de leurs partenaires? Et de quoi auront-ils besoin?

• Assurez-vous que le système que vous utilisez, s'il ne capture pas automatiquement les informations telles que l'emplacement du lanceur d'alerte, qu'il permette à tout le moins à chacun de fournir facilement des informations et des mises à jour précises via une application mobile.