Les exigences de cybersécurité occupent une place croissante dans la négociation des contrats IT.
Questionnaires de sécurité, annexes techniques, obligations de notification des incidents, exigences d’audit, plans de continuité, localisation des données, encadrement de la sous-traitance ou encore exigences particulières concernant l’hébergement : pour les prestataires IT, SaaS ou cloud, la négociation du volet sécurité peut désormais devenir aussi importante que celle des conditions commerciales ou des niveaux de service.
Ces exigences ne répondent toutefois pas toutes à la même logique.
Certaines traduisent simplement le niveau de sécurité que le client estime nécessaire au regard de ses activités et de ses risques. D’autres résultent directement de ses propres obligations réglementaires, qu’il doit en pratique répercuter sur ses prestataires.
NIS2, DORA ou encore, dans un autre contexte, les exigences applicables à certains services cloud au titre de la loi SREN illustrent cette évolution.
La cybersécurité ne constitue donc plus seulement une exigence technique : elle structure de plus en plus le contrat lui-même.
Un client qui confie tout ou partie de son système d’information, de ses données ou d’une fonction essentielle à un prestataire doit naturellement s’assurer que celui-ci présente un niveau de sécurité adapté.
Il est donc normal que le contrat traite notamment :
Ces exigences doivent cependant rester cohérentes avec la nature du service fourni, les risques concernés et la capacité réelle du prestataire à respecter les engagements souscrits.
Une obligation de sécurité n’est pas meilleure parce qu’elle est plus longue ou plus détaillée.
L’enjeu de la négociation consiste donc à identifier les mesures réellement nécessaires et à les traduire en engagements contractuels suffisamment précis pour être utiles, sans transformer le contrat en catalogue d’exigences techniques déconnectées du service.
La situation est différente lorsque le client est lui-même soumis à une réglementation qui lui impose de maîtriser les risques liés à ses fournisseurs.
Dans ce cas, certaines demandes contractuelles ne relèvent plus seulement de sa politique interne de sécurité.
Le client doit pouvoir démontrer qu’il maîtrise les risques résultant du recours à son prestataire. Le contrat devient l’un des instruments de cette maîtrise.
C’est particulièrement visible avec DORA.
Les entités financières soumises au règlement doivent encadrer contractuellement leurs relations avec leurs prestataires tiers de services TIC. Le règlement prévoit directement un ensemble de stipulations concernant notamment la description des services, les lieux de traitement et de stockage des données, leur disponibilité, authenticité, intégrité et confidentialité, leur restitution, les niveaux de service, l’assistance en cas d’incident, la coopération avec les autorités ou les conditions de résiliation.
Des exigences supplémentaires s’appliquent lorsque les services TIC soutiennent une fonction critique ou importante, notamment en matière de sécurité, de continuité, de notification, d’audit et de contrôle.
Pour le prestataire, certaines clauses qui pourraient sembler particulièrement exigeantes ne sont donc pas nécessairement le résultat d'une volonté de son client de « surcontractualiser » la relation : elles peuvent être nécessaires à sa propre conformité réglementaire.
Pour aller plus loin : DORA et prestataires IT : comprendre et négocier les exigences contractuelles des acteurs financiers.
La même logique se retrouve avec NIS2.
La directive ne réglemente pas seulement la sécurité interne des entités concernées. Elle impose également de prendre en compte la sécurité de la chaîne d’approvisionnement, y compris les relations entre l’entité et ses fournisseurs ou prestataires directs.
Une entreprise soumise à NIS2 doit donc intégrer dans son analyse des risques les vulnérabilités propres à ses fournisseurs, la qualité globale de leurs produits et de leurs pratiques de cybersécurité ainsi que les risques associés à la relation.
Là encore, cette obligation finit naturellement par se traduire dans les processus de référencement et dans les contrats : exigences de sécurité, questionnaires fournisseurs, notification des incidents, contrôle de la sous-traitance, coopération ou audit.
Le prestataire peut ainsi subir indirectement les effets d’une réglementation à laquelle il n’est pas lui-même soumis.
C’est un point essentiel dans la négociation : comprendre pourquoi l’exigence est formulée permet de distinguer ce qui peut réellement être négocié de ce qui répond à une contrainte réglementaire du client.
Pour aller plus loin : NIS2 et prestataires IT : quand les exigences de cybersécurité se répercutent dans les contrats.
Pour le prestataire, la bonne réaction n’est donc ni d’accepter systématiquement toutes les exigences de sécurité de son client, ni de considérer qu’elles sont nécessairement excessives.
Il faut d’abord comprendre d’où vient l’exigence.
Est-elle liée :
La réponse détermine largement la marge de négociation.
Lorsqu’une exigence résulte directement de DORA ou d’une autre réglementation applicable au client, demander sa suppression pure et simple peut être illusoire.
En revanche, son périmètre, ses modalités de mise en œuvre et la répartition des responsabilités restent souvent à négocier.
Un droit d’audit peut par exemple être légitime sans justifier un accès permanent et sans limite aux systèmes du prestataire. Une obligation de notification peut être nécessaire sans que tout événement technique mineur doive être signalé dans l’heure. Une exigence de sécurité peut être obligatoire dans son principe sans imposer nécessairement la mesure technique particulière initialement demandée.
La multiplication des questionnaires et annexes de sécurité crée enfin un risque très concret pour les prestataires : accepter contractuellement des engagements qui ne correspondent pas à leurs pratiques réelles.
Une clause peut avoir été copiée d’un référentiel groupe, d’un précédent contrat ou d’une réglementation sans que le prestataire ait vérifié qu’il est techniquement et organisationnellement capable de la respecter.
Or une exigence de cybersécurité intégrée au contrat devient une obligation contractuelle.
Le prestataire doit donc associer les équipes techniques et sécurité à la négociation et vérifier que les engagements pris correspondent effectivement aux mesures mises en œuvre.
Le travail juridique consiste alors à faire le lien entre trois niveaux : l’exigence réglementaire, la réalité technique et l’engagement contractuel.
La cybersécurité modifie profondément la négociation des contrats IT.
Pour le client, le contrat permet de maîtriser une partie des risques qu’il externalise auprès de ses fournisseurs et, lorsqu’il est soumis à une réglementation particulière, de démontrer qu’il respecte ses propres obligations.
Pour le prestataire, l’enjeu consiste à comprendre ce qui justifie les exigences formulées, à identifier celles qui sont réellement imposées au client et à négocier des engagements compatibles avec la réalité de son service.
La bonne question n’est donc plus seulement : « cette clause de sécurité est-elle acceptable ? » mais : « pourquoi est-elle demandée, quelle obligation cherche-t-elle à couvrir et comment la traduire correctement dans le contrat ? »
Les exigences de cybersécurité peuvent également résulter d’obligations directement applicables au fournisseur ou à ses produits. C’est notamment le cas du Cyber Resilience Act, qui impose de nouvelles exigences de cybersécurité aux fabricants de produits comportant des éléments numériques.
Pour aller plus loin : Cyber Resilience Act : quelles obligations pour les éditeurs de logiciels et fabricants de produits connectés ?
Withlaw accompagne clients et prestataires dans la négociation des exigences de cybersécurité intégrées aux contrats IT, SaaS et cloud, notamment pour :
L’objectif est de parvenir à des engagements de cybersécurité qui répondent aux contraintes du client sans imposer au prestataire des obligations disproportionnées ou qu’il ne serait pas en mesure de respecter.