NIS2 renforce les obligations de cybersécurité applicables à de nombreuses organisations européennes. Mais ses effets ne s’arrêtent pas aux seules entités directement soumises à la directive.
En imposant aux entités concernées de maîtriser les risques liés à leur chaîne d’approvisionnement et à leurs prestataires, NIS2 influence également les relations contractuelles avec les fournisseurs IT, SaaS, cloud ou de services numériques.
Questionnaires de sécurité, exigences techniques, notification des incidents, contrôle de la sous-traitance, audits : un prestataire peut ainsi être confronté aux effets de NIS2 sans être lui-même directement soumis au texte.
Les entités soumises à NIS2 doivent mettre en œuvre des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées pour gérer les risques pesant sur la sécurité de leurs réseaux et systèmes d’information.
Parmi les domaines expressément concernés figure la sécurité de la chaîne d’approvisionnement, y compris les aspects liés à la sécurité concernant les relations entre l’entité et ses fournisseurs ou prestataires directs.
L’entité doit notamment prendre en compte les vulnérabilités propres à chaque fournisseur et la qualité globale des produits et des pratiques de cybersécurité de ses fournisseurs et prestataires.
Le recours à un prestataire ne permet donc pas d’externaliser la responsabilité de la maîtrise du risque.
Pour le client soumis à NIS2, la sécurité du fournisseur devient elle-même un élément de sa propre conformité.
NIS2 ne fournit pas un modèle d’annexe sécurité à intégrer aux contrats.
En revanche, pour maîtriser effectivement les risques liés à ses fournisseurs, le client doit obtenir les informations et les engagements dont il a besoin.
Cette exigence peut notamment se traduire contractuellement par des dispositions relatives :
La négociation de ces clauses devient ainsi l’un des moyens par lesquels l’entité soumise à NIS2 organise la maîtrise des risques associés à sa chaîne d’approvisionnement.
Pour autant, toute exigence formulée par un client soumis à NIS2 n’est pas nécessairement imposée par NIS2.
La directive fixe des objectifs et impose des mesures de gestion des risques. Elle laisse une place importante à l’appréciation des mesures appropriées et proportionnées au regard des risques concernés.
Un client peut donc parfaitement décider d’aller au-delà de ce qui est strictement nécessaire au titre de NIS2, notamment en appliquant ses propres politiques groupe, référentiels de sécurité ou modèles contractuels.
Cette distinction est importante dans la négociation.
Lorsqu’une clause est présentée comme « obligatoire au titre de NIS2 », il faut identifier l’exigence réglementaire qu’elle cherche réellement à satisfaire, puis vérifier si la rédaction proposée constitue la seule manière d’y répondre.
Le principe de l’exigence peut être difficilement négociable alors que ses modalités de mise en œuvre le restent.
La gestion des incidents constitue un bon exemple.
NIS2 soumet les entités concernées à un dispositif de notification échelonné en cas d’incident significatif, avec notamment une alerte précoce dans les 24 heures après en avoir pris connaissance, suivie d’une notification dans les 72 heures et, en principe, d’un rapport final dans le mois.
Lorsqu’un incident affectant un prestataire est susceptible d’avoir des conséquences sur les services du client, celui-ci doit donc disposer suffisamment rapidement des informations nécessaires pour respecter ses propres obligations.
Il est dès lors légitime que le contrat impose au prestataire une obligation de notification.
Mais cela ne signifie pas nécessairement que tout événement de sécurité, indépendamment de son impact sur le service du client, doive être signalé selon un délai uniforme extrêmement court.
La clause doit permettre au client de respecter ses obligations sans imposer au prestataire un mécanisme de notification déconnecté de la nature et de la gravité des événements concernés.
La même logique s’applique aux mécanismes de contrôle.
Le client doit être en mesure d’évaluer la sécurité de ses fournisseurs et de vérifier que les mesures annoncées sont effectivement mises en œuvre.
Cela peut justifier la communication de certifications, rapports d’audit, questionnaires de sécurité ou autres éléments de preuve et, dans certaines situations, un droit d’audit contractuel.
Mais NIS2 ne justifie pas à elle seule un droit d’accès général, permanent et sans condition aux systèmes, locaux ou informations du prestataire.
La négociation peut notamment porter sur les conditions de déclenchement de l’audit, son périmètre, sa fréquence, les modalités pratiques de sa réalisation, la confidentialité des informations accessibles et la possibilité de recourir en priorité à des rapports ou certifications existants.
Là encore, il faut distinguer le besoin légitime de contrôle du client des modalités contractuelles proposées pour y répondre.
La sécurité de la chaîne d’approvisionnement conduit également les clients à s’intéresser davantage aux propres fournisseurs de leurs prestataires.
Pour un service SaaS ou cloud, la prestation peut dépendre de plusieurs acteurs : hébergeur, fournisseur de services cloud, éditeur de composants logiciels, prestataires de support ou autres sous-traitants techniques.
Le client peut donc souhaiter disposer d’informations sur cette chaîne, encadrer certaines modifications ou imposer au prestataire de répercuter certaines exigences de sécurité à ses propres sous-traitants.
Ces demandes doivent toutefois rester cohérentes avec la réalité du modèle de fourniture du service.
Un SaaS standardisé reposant sur une infrastructure mutualisée ne peut pas nécessairement être géré selon les mêmes mécanismes qu’une prestation informatique entièrement dédiée.
Pour le prestataire, l’enjeu n’est pas seulement juridique.
Les réponses données à un questionnaire de sécurité, les engagements figurant dans une annexe technique ou les garanties données pendant la négociation peuvent devenir des obligations contractuelles.
Il faut donc éviter d’accepter une clause parce qu’elle est présentée comme « NIS2 compliant » sans vérifier qu’elle correspond effectivement aux pratiques et capacités du prestataire.
Les équipes juridiques, techniques et sécurité doivent pouvoir confronter :
l’exigence réglementaire du client, le risque qu’elle cherche à couvrir, la mesure réellement mise en œuvre par le prestataire et l’engagement finalement inscrit dans le contrat.
C’est à cette condition que la conformité du client ne se transforme pas en accumulation d’engagements impossibles à tenir pour son fournisseur.
NIS2 renforce incontestablement la place de la cybersécurité dans les relations avec les prestataires IT.
Mais la directive ne signifie pas que toutes les exigences formulées par un client deviennent automatiquement non négociables.
Pour le client, il s’agit d’obtenir les engagements nécessaires à la maîtrise de sa chaîne d’approvisionnement et à sa propre conformité.
Pour le prestataire, il s’agit de comprendre quelle obligation réglementaire se trouve derrière la demande, puis de négocier des modalités adaptées au service et aux risques concernés.
C’est précisément cette distinction entre l’exigence réglementaire et sa traduction contractuelle qui permet de sécuriser la relation sans surcontractualiser la cybersécurité.
Withlaw accompagne clients et prestataires IT dans la prise en compte des exigences NIS2 dans leurs relations contractuelles, notamment pour :
L’objectif est de permettre au client de satisfaire à ses obligations de cybersécurité tout en construisant avec ses prestataires des engagements proportionnés, opérationnels et effectivement applicables.