Un incident dans le secteur de l'installation n'est pas toujours un ordinateur portable piraté. C'est tout aussi souvent un technicien qui se connecte avec un mauvais compte au système de gestion du bâtiment d'un client, un coffre-fort à clés qui n'a pas été correctement fermé, ou un responsable de la planification qui clique sur un lien de phishing après lequel un mot de passe client est exposé. Ce que vous enregistrez est essentiellement le même pour chacune de ces situations : quand c'est découvert, ce qui s'est exactement passé, qui y était impliqué, quel accès était en jeu, quelle action a été prise et qui en a été informé.
Cet enregistrement est différent d'une notification auprès d'une autorité de surveillance. Un registre interne des incidents est un journal continu que vous tenez à jour, qu'un incident soit soumis à l'obligation de notification ou non. Pour les organisations qui relèvent elles-mêmes de la directive NIS2, ce registre fait partie des mesures de diligence raisonnable au titre de l'article 21. Pour le groupe beaucoup plus large d'entreprises d'installation qui ne relèvent pas directement de la loi mais sont évaluées en tant que fournisseurs, le registre est souvent exactement ce qu'un questionnaire de sécurité d'un client demande : pouvez-vous montrer que vous identifiez, enregistrez et suivez les incidents ? Que vous relieviez directement de la loi ou que vous soyez touchés uniquement par la chaîne d'approvisionnement, vous pouvez vérifier votre situation en répondant à quelques questions qui montrent votre position dans la chaîne d'approvisionnement.
Qu'est-ce qu'il faut dans le registre
Un registre d'incidents utile contient, pour chaque événement, une date et une heure de découverte, une brève description de ce qui a été observé ou signalé, et le nom de la personne qui l'a remarqué ou signalé. Vous notez également quel système, quel site ou quel client a été affecté, et quel accès a joué un rôle : un mot de passe partagé, une clé physique, un badge d'accès, une connexion VPN au réseau du client. Vous enregistrez ensuite quelle action a été prise, qui en était responsable, et si et quand le client ou l'organisation a été informé. Enfin, une ligne sur la clôture : l'incident est-il résolu, et quelque chose a-t-il changé à la suite de cela ?
Cette dernière ligne est souvent omise, alors que les autorités de surveillance et les clients la regardent précisément. Un registre qui compte seulement les notifications ne dit pas grand-chose. Un registre qui montre qu'un problème récurrent a conduit à un ajustement de la façon de travailler montre que l'organisation en tire les leçons.
La situation spécifique des techniciens sur site
Ce qui distingue le secteur de l'installation d'une entreprise de logiciels, par exemple, c'est que l'accès n'est rarement purement numérique. Un technicien qui doit se rendre chez un client a souvent à la fois une clé physique ou un badge et un compte numérique pour le système de gestion du bâtiment, l'alarme ou l'installation climatique. Un incident peut donc survenir parce qu'une clé est perdue, parce qu'un compte d'un ancien employé n'a pas été révoqué, ou parce qu'un ordinateur portable contenant des identifiants enregistrés est volé dans un véhicule. Dans le registre, cette distinction ne change pas grand-chose : il s'agit toujours de la même question, à savoir qui avait accès à quel moment et si cela était encore justifié.
Cela touche directement à la gestion des accès : qui peut accéder à quels systèmes et clés, et cet aperçu est-il à jour. Un registre d'incidents sans un aperçu continu des accès est difficile à compléter, car vous devez alors déterminer à nouveau pour chaque incident qui devait avoir accès à quoi. Un aperçu continu des mesures, des statuts et des propriétaires, comme le maintient un cyber-dossier, rend cette détermination superflue.
Tous les incidents n'ont pas besoin du même traitement
La matérialité joue aussi un rôle ici : une note de mot de passe perdue qui a été immédiatement remarquée et modifiée n'a pas le même poids qu'un accès non autorisé à un système client qui n'est découvert que plusieurs semaines plus tard. La directive et la législation nationale font la distinction entre les incidents graves et les incidents mineurs, et les autorités de contrôle examinent l'impact sur la fourniture de services et sur le client. Une partie essentielle de votre propre évaluation consiste donc à déterminer si cet incident n'affecte que le fonctionnement de votre propre entreprise, ou s'il affecte également les systèmes ou les données d'un client. Dans ce dernier cas, une obligation d'informer ce client s'impose généralement, indépendamment de la question de savoir s'il existe également une obligation légale de notification.
Les délais et seuils exacts qui s'appliquent varient selon la situation et le pays dans lequel vous êtes actif. Pour le texte exact et la source, nous vous renvoyons aux sources officielles, et pour votre situation particulière à un juriste ou à l'autorité de contrôle compétente. Un aperçu de la manière dont nous gérons les sources et de leur provenance se trouve sur la page où notre méthode est expliquée.
Ce que cela signifie concrètement dans la pratique
Une entreprise d'installation qui peut montrer comment elle enregistre et suit les incidents fournit à un client quelque chose de concret pour répondre à un questionnaire de sécurité, et dispose elle-même d'un ouvrage de référence pour le moment où les choses tournent mal à nouveau. Si vous n'avez pas encore de formulaire fixe pour ce registre, vous trouverez un point de départ et l'explication correspondante sur l'aperçu des sujets selon votre situation, et les questions fréquemment posées sur ce qui doit ou ne doit pas figurer dans un tel registre sont rassemblées sur la page contenant les réponses aux questions récurrentes.
Commencez si vous le souhaitez par l'analyse rapide gratuite : en quelques questions, vous verrez si votre organisation relève elle-même de la loi, est affectée par la chaîne d'approvisionnement, ou ni l'une ni l'autre, avec une explication pour chaque résultat.