Registre des incidents : revue, journal, preuves d'audit

Le registre des incidents

Chaque incident reçoit une référence permanente, INC-12, et la numérotation n'a jamais de trou : un incident annulé garde son numéro. Gravité, catégorie, responsable et dates suffisent pour commencer ; le reste vient quand vous en savez plus. Un incident passé se saisit avec ses vraies dates.

Quatre niveaux de gravité, catégories paramétrables
Ouvert, en cours, résolu, clôturé : le statut n'avance que vers l'avant
Rouvrir ou annuler un incident avec une raison obligatoire, réservé aux administrateurs du registre
Recherche dans les titres, les descriptions, les applications et les serveurs liés
Durée calculée une fois l'incident résolu

Registre des incidents avec gravité, statut, dates de détection et de résolution

La revue formelle de l'incident

Chaque incident a sa revue : un document riche, créé depuis un modèle en cinq parties (description détaillée, impact, cause racine, actions correctives, enseignements) dans la langue de la personne qui l'écrit. Chaque enregistrement crée une version, et la revue est figée à la clôture de l'incident.

Modèle modifiable par vos administrateurs de la documentation
Titres, listes, tableaux et images collées
Versionnée, rangée dans la documentation avec sa propre référence
Les droits sur les incidents suffisent pour la rédiger
Le journal enregistre chaque changement, et aucune entrée ne se modifie ni ne se supprime

Incident clôturé avec sa description et sa revue : résumé, impact, cause racine, actions

Des preuves pour l'auditeur

Des données personnelles ont-elles été touchées ? Fallait-il notifier l'autorité, et quand l'a-t-on fait ? Qui a été informé ? L'incident enregistre ces faits avec leurs dates, et les garde : un incident qui porte des faits réglementaires ne peut pas être supprimé.

Données personnelles concernées, notification aux autorités requise, notifié le, parties informées
Rapport PDF d'un incident, dans la langue de l'écran
La clôture verrouille tout : champs, revue, journal, liens et fichiers
Incidents confidentiels visibles des seuls administrateurs du registre, du déclarant et du responsable
Les faits que l'article 33(5) du RGPD et NIS2 demandent de documenter

Incident avec données personnelles concernées et autorité notifiée le 11 juillet

Relié à votre système d’information

Reliez un incident aux serveurs, aux applications et aux technologies qu'il a touchés. Chacun affiche alors ses incidents, en lecture seule, sur sa propre fiche. Les actions de suivi deviennent des tâches qui portent la référence de l'incident, et les documents et les pièces jointes restent avec lui.

Actifs, applications et technologies, avec des suggestions tirées de ce qui est déjà lié
Les incidents affichés sur la fiche de chaque application, serveur et technologie
Tâches de suivi créées depuis l'incident
Documents de la base de connaissances et pièces jointes
Les liens suivent les droits de lecture de chacun

Relations d'un incident : trois serveurs, deux applications SAP et VMware ESXi

Et encore

Import et export CSV

Reprenez vos incidents passés depuis un tableur, revues comprises, et exportez tout le registre.

Plaid et MCP

Demandez à Plaid combien d'incidents majeurs ont été ouverts cette année, ou la fiche complète de l'un d'eux, journal et revue compris. Les incidents confidentiels restent exclus. Les mêmes données sont ouvertes à vos clients IA par le serveur MCP en lecture seule.

Notes antidatées

Les notes du journal portent l'heure de l'événement. L'heure de leur enregistrement est gardée à part et ne se modifie pas.

Droits

Les lecteurs consultent, les contributeurs créent et rédigent, les administrateurs du registre rouvrent, annulent, suppriment et lèvent une restriction.