La formation de sensibilisation à la sécurité dans le développement de logiciels ne constitue pas un chapitre distinct de la directive, mais découle de l'obligation de diligence : l'obligation de prendre des mesures techniques et organisationnelles appropriées contre les risques pour les systèmes d'information et les réseaux. La sensibilisation des employés est l'une des mesures qui en découle, car une grande partie des incidents commencent par une erreur humaine : un courrier d'hameçonnage ouvert, un mot de passe partagé, un accès mal configuré que personne ne remarque.
En outre, la directive énonce une deuxième obligation distincte qui ne concerne pas les employés mais l'administrateur lui-même : celui-ci doit également se former et superviser la mise en place de la cybersécurité au sein de l'organisation. Il s'agit d'une obligation différente de l'obligation de formation pour le personnel, avec un objectif distinct et un responsable différent. Pour une entreprise de logiciels soumise à l'obligation de diligence, ou qui doit faire face aux exigences NIS2 d'un client, la distinction entre ces deux niveaux est exactement là où surgit beaucoup de confusion.
Ce que l'obligation de diligence demande à l'organisation
L'obligation de diligence ne décrit pas un programme de formation fixe avec un nombre minimum d'heures ou un prestataire obligatoire. Ce que la directive demande plutôt, c'est qu'une organisation montre une attention appropriée à la sensibilisation à la sécurité comme élément de sa gestion des risques. En pratique, cela signifie : les employés qui travaillent avec du code, des données clients ou des environnements de production doivent savoir ce qu'est l'ingénierie sociale, comment reconnaître une demande suspecte et ce qu'ils doivent faire s'ils doutent.
Dans une entreprise de logiciels, l'accent est souvent mis sur quelques risques spécifiques qui ne s'appliquent pas à toutes les PME : l'accès au code source, les secrets dans les fichiers de configuration et la tentation de sécuriser les environnements de test de manière plus laxiste que la production. Un programme de sensibilisation qui n'avertit que contre les courriels d'hameçonnage, mais ne dit rien sur le partage d'une clé API dans un message de chat, manque précisément le risque qui se produit le plus souvent dans la chaîne de développement. Ceux qui veulent documenter cela systématiquement trouveront dans l'aperçu des sujets par secteur comment d'autres mesures de l'obligation de diligence s'y rattachent, telles que la gestion des accès et l'enregistrement des incidents.
L'obligation distincte de l'administrateur
Outre l'obligation de formation du personnel, la directive impose une responsabilité propre à l'administrateur : celui-ci doit lui-même posséder une connaissance suffisante pour pouvoir évaluer les mesures prises et pouvoir estimer les risques associés à l'organisation. Il ne s'agit pas d'un complément à la formation du personnel, mais d'une obligation autonome, adressée à celui qui est responsable en dernier ressort.
Cette distinction est pertinente car elle est souvent ignorée : une entreprise organise un apprentissage en ligne pour tous les employés et pense avoir ainsi satisfait à l'obligation de l'administrateur. Ou le directeur d'une entreprise de logiciels suppose que sa propre expérience technique suffit, sans que rien ne soit documenté. Les deux situations révèlent un écart entre ce qui se passe réellement et ce qui est démontré comme étant organisé. Pour la mise en œuvre précise de cette obligation, et pour ce qui est spécifique au pays dans la transposition nationale, le texte officiel de la directive est le point de départ approprié ; nous enregistrons dans la base de connaissances les publications que nous avons vues et quand.
Ce que cela signifie pour une entreprise de logiciels en pratique
Une entreprise de logiciels qui relève elle-même de l'obligation de diligence, ou qui reçoit un questionnaire de sécurité d'un client soumis à cette obligation, reçoit généralement deux types de questions à la fois : existe-t-il un programme de sensibilisation à la sécurité pour les employés, et la direction a-t-elle elle-même suivi ou organisé des activités de formation. Celui qui ne peut démontrer que le premier point se retrouve sur papier avec une obligation sans réponse que le questionnaire pose clairement.
Pour déterminer si, et dans quel rôle, cela s'applique à votre organisation, il est utile de commencer par identifier le secteur, la taille et la position dans la chaîne d'approvisionnement. C'est exactement par là que le contrôle NIS2 gratuit commence : en quelques questions, il devient clair si une organisation est elle-même assujettie, ne subit l'impact que par un client, ou aucun des deux.
Documenter : preuve et responsable
Une obligation de formation qui n'existe que dans les esprits n'est pas démontrable lors d'une inspection ou d'un questionnaire. Ce qui fonctionne, c'est de documenter pour chaque obligation un statut, une preuve et un responsable : quand quel groupe d'employés a suivi quelle formation, et y a-t-il eu un moment distinct où le dirigeant a été informé des mesures prises et des risques de l'organisation. Les deux doivent figurer dans un dossier, non dans deux e-mails distincts.
De nombreux doutes courants sur ce qui relève précisément de l'obligation de formation, et comment cela s'articule avec d'autres mesures de l'obligation de diligence, sont détaillés dans la questions fréquemment posées. Vous y trouverez également comment secria.eu tient à jour les sources et quand une page a été vérifiée pour la dernière fois, accessible via l'explication sur la manière dont l'information est construite.
Souhaitez-vous d'abord savoir si ce sujet s'applique à votre organisation, ou seulement s'il vous atteint par un client ? Effectuez le contrôle NIS2 gratuit ou consultez les sujets ; tous deux sont accessibles sans compte et donnent immédiatement une étape concrète à suivre.