Contrat avec un prestataire IT après NIS2 : clauses de sécurité, SLA et notification des incidents

Après NIS2, un contrat avec un prestataire IT ne devrait pas se limiter à une déclaration de conformité, à une clause générale de sécurité et à un taux mensuel de disponibilité. Il doit traduire les risques associés au service en responsabilités clairement réparties, niveaux de service mesurables, circulation rapide de l’information en cas d’incident, accès aux éléments de preuve et plan de réversibilité réellement applicable. Le point de départ est la criticité du service et la répartition effective des contrôles entre les parties. C’est seulement sur cette base qu’il est possible de définir les mesures de sécurité, les délais, les droits de vérification et les obligations de notification à intégrer au contrat.

Le contrat comme dispositif de maîtrise des risques

La revue des contrats ne doit pas commencer par un modèle standard de clause de sécurité, mais par une cartographie des dépendances de l’organisation à l’égard de ses prestataires. Pour chacun d’eux, il convient d’identifier les services, processus, systèmes, données et sites concernés, puis d’évaluer les conséquences d’une indisponibilité ou d’une atteinte à la sécurité. L’analyse doit porter en priorité sur les dépendances dont la défaillance pourrait interrompre l’activité, compromettre le respect des engagements ou compliquer la gestion d’un incident. Toutes les prestations IT ne nécessitent donc pas le même niveau de protection contractuelle.

La classification de la criticité d’un prestataire doit résulter d’une analyse d’impact sur l’activité et d’une appréciation des risques, et non de la seule valeur du contrat. Une vigilance particulière s’impose lorsque l’entreprise demeure responsable de la continuité et de la gestion des incidents, tandis que le prestataire contrôle les informations techniques, les journaux d’événements, les sauvegardes ou l’environnement nécessaire au rétablissement du service. L’organisation doit également désigner un propriétaire du risque fournisseur. Sans cette fonction, les responsabilités restent dispersées entre les achats, l’IT, la sécurité et le pilote du processus concerné.

Le contrat doit être conçu à partir de scénarios de perturbation : panne du service, attaque, perte ou altération de données, indisponibilité du personnel du prestataire, rupture dans la chaîne de sous-traitance ou fin de la relation contractuelle. Pour chaque scénario, il faut déterminer les actions attendues de chaque partie, les responsabilités, les circuits d’information et les conditions de rétablissement. Ces éléments permettent ensuite de fixer les niveaux de disponibilité, les délais de prise en charge et de restauration, la documentation requise et les droits de vérification.

Une promesse de haute disponibilité ne précise ni la durée maximale acceptable d’indisponibilité d’un système de pilotage de la production, ni le point de départ du calcul de l’interruption, ni la partie tenue de fournir les données nécessaires à l’évaluation de l’incident. Elle ne garantit pas davantage l’accès aux copies des journaux, aux informations sur les sous-traitants ou aux données permettant de transférer le service en toute sécurité. Ces lacunes apparaissent généralement lors d’une panne, lorsque la répartition des responsabilités ne peut plus rester implicite.

La référence à NIS2 ou aux exigences applicables du KSC doit conclure l’analyse des risques et des responsabilités, et non remplacer le contenu opérationnel du contrat. Une vision plus large des enjeux de gouvernance est présentée dans l’article NIS2 pour les entreprises industrielles : organisations concernées, obligations introduites et préparation au-delà du seul périmètre IT. Les modifications contractuelles doivent toujours être adaptées au rôle de l’organisation, à la criticité du service et à la répartition réelle des contrôles entre les parties.

Périmètre du service et répartition des responsabilités

La répartition des obligations doit être décrite dans une annexe technique, et non laissée dans une définition générale de l’objet du contrat. Cette annexe devrait préciser les actifs et environnements couverts, les catégories de données, les lieux de traitement et de fourniture du service, les interfaces, les plages de support et les exclusions. Sans ces informations, il est impossible de déterminer avec précision où s’arrête la responsabilité du prestataire, quel événement déclenche la mesure du SLA ou qui sécurise les composants situés à l’interface entre les systèmes.

Il est préférable de définir les mesures de sécurité par le résultat attendu, la partie responsable et la preuve d’exécution, tout en conservant les détails technologiques dans une documentation technique maîtrisée. Cette approche limite le risque d’obsolescence rapide du contrat. Le catalogue standard de mesures du prestataire ne peut être accepté qu’après comparaison avec les risques propres au service et traitement des écarts constatés. La matrice des responsabilités doit distinguer le propriétaire de la mesure, son exécutant et l’autorité habilitée à approuver les dérogations.

Lorsque l’environnement est administré par le prestataire, le contrat doit également encadrer les accès privilégiés : séparation des tâches, méthodes d’authentification, traçabilité des opérations d’administration et retrait immédiat des droits après un changement de fonction ou la fin de la relation. Une simple déclaration affirmant que des sauvegardes sont réalisées ne suffit pas si le client ignore qui les chiffre, où elles sont stockées, qui peut les restaurer et quel document atteste le résultat du test de restauration.

Le prestataire devrait tenir à jour la liste des sous-traitants ayant une incidence sur le service, avec la description de leur rôle et des lieux de traitement, et leur imposer des exigences au moins équivalentes à celles convenues avec le client. Le contrat doit préciser quelles modifications nécessitent un accord préalable et lesquelles donnent seulement lieu à une information et à une nouvelle appréciation des risques. La certification d’un système de management peut contribuer à cette évaluation, mais elle ne remplace pas les responsabilités définies pour le service concerné. Cette articulation est approfondie dans l’article NIS2 et NF EN ISO 27001 : ce qu’apporte la certification et ce qui reste nécessaire pour répondre aux exigences du KSC.

Des clauses de sécurité vérifiables

Une clause de sécurité ne devient véritablement opposable et pilotable que lorsqu’elle définit le résultat attendu, son périmètre d’application, la fréquence des actions, les modalités de preuve et le traitement des dérogations. Des formulations telles que « conformément aux bonnes pratiques » ou « avec toute la diligence requise » peuvent compléter les exigences, mais elles ne permettent pas, à elles seules, d’évaluer si le prestataire a correctement exécuté son obligation. Pour chaque mesure, il convient d’identifier le propriétaire de l’exigence, la durée de conservation des preuves et la partie habilitée à accepter une exception.

Les exigences ainsi formulées devraient couvrir au minimum la gestion des vulnérabilités et des mises à jour, le maintien d’une configuration sécurisée, le chiffrement, la protection et la conservation des journaux, les sauvegardes, les tests de restauration, la gestion des changements et le contrôle des accès. La fréquence des revues d’habilitations, des tests de restauration et du reporting, ainsi que les délais de traitement des vulnérabilités, doivent découler de l’évaluation des risques du service. Ils ne devraient pas être identiques pour tous les prestataires.

Toute dérogation doit être consignée dans un registre avec sa justification, son échéance de traitement, le propriétaire du risque et les mesures compensatoires. Son acceptation suppose de vérifier que ces mesures ramènent effectivement le risque à un niveau admis par l’organisation.

Une clause prévoyant des sauvegardes régulières reste incomplète si elle ne précise pas les données et systèmes couverts, la durée de conservation, la protection contre la modification ou la suppression, les règles d’accès et la fréquence des tests de restauration. Elle devrait également définir la manière dont le prestataire signale l’échec d’une sauvegarde ou d’un test, la personne qui approuve les actions correctives et le rapport attestant leur clôture. De même, l’obligation de corriger les vulnérabilités exige une méthode de classification, des délais de traitement proportionnés au risque, des règles de report des mises à jour et la documentation des mesures temporaires.

Les preuves doivent être réparties entre celles transmises périodiquement et celles disponibles sur demande. La première catégorie peut comprendre les synthèses de vulnérabilités, les rapports de mise à jour, les résultats des tests de restauration et les confirmations de revues d’accès. Après un incident, une modification significative ou la constatation d’un écart, des résultats détaillés de tests, des journaux d’événements, l’historique des changements, le registre des exceptions et le plan d’actions correctives peuvent être nécessaires. Le périmètre, les responsables et la durée de conservation de ces éléments peuvent être alignés sur les principes décrits dans l’article Documentation NIS2 et KSC avant un contrôle : politiques, registres et preuves réellement nécessaires.

Le droit de vérification doit être gradué et rester applicable, y compris à un fournisseur de services cloud. Un premier niveau peut comprendre l’examen documentaire et une réunion de clarification ; le niveau suivant peut reposer sur des rapports indépendants ou des tests convenus. Un audit sur site peut être réservé aux situations de risque accru, d’incident majeur ou d’absence de preuves crédibles. Le contrat doit encadrer les préavis, la confidentialité, le périmètre technique et le traitement des constats, sans accorder au client des droits impossibles à exercer dans un environnement mutualisé.

Un SLA orienté résilience, pas seulement disponibilité

Le SLA doit découler d’une analyse d’impact sur l’activité, et non du catalogue standard d’indicateurs du prestataire. Le pilote du processus définit d’abord la durée d’interruption tolérable, la perte de données acceptable et les conséquences d’une indisponibilité sur la production, le service client, les règlements et les obligations juridiques. Ces éléments servent ensuite à établir les objectifs de temps de rétablissement, les exigences relatives aux solutions de substitution et aux modes dégradés, ainsi que les priorités des demandes. Un taux mensuel de disponibilité ne permet pas de déterminer si une panne unique survenant à un moment critique immobilisera le processus au-delà de la tolérance de l’organisation.

Outre la disponibilité, le contrat devrait fixer le délai d’accusé de réception, le délai de début du diagnostic, le temps de rétablissement de la fonction et le délai de suppression de la cause, ainsi que la fréquence des communications, les niveaux d’escalade et les modalités d’intervention hors des horaires habituels. Le temps de réaction n’est pas le temps de rétablissement, et l’activation d’une solution de contournement ne signifie pas que le problème est définitivement résolu. La distinction entre ces notions permet aux équipes opérationnelles de savoir quand elles pourront reprendre leur activité et au propriétaire du service de déterminer quand le prestataire devra avoir achevé l’analyse des causes et mis en œuvre une action corrective durable.

Pour un système de conduite d’un processus de production, un incident critique peut exiger une escalade immédiate et une communication continue jusqu’à l’activation du mode dégradé. Une défaillance identique dans un environnement de formation peut recevoir une priorité moindre. La classification doit donc être fondée sur l’impact métier, et non sur la seule description technique du défaut. Lorsque l’organisation dispose de données historiques fiables, elle devrait tenir compte, pour fixer les seuils, des temps réels de réaction et de rétablissement, des résultats de disponibilité et du nombre de pannes récurrentes.

Le mécanisme de mesure doit préciser la source des données, le fuseau horaire, les événements déclenchant et arrêtant le chronomètre, les heures convenues de fourniture du service, les fenêtres de maintenance et les règles de reclassement d’un incident. Les exclusions doivent être regroupées dans une liste fermée et vérifiable. Elles ne peuvent pas couvrir les événements relevant de la responsabilité du prestataire. La cohérence entre ces dispositions et la préparation opérationnelle réelle peut être évaluée dans le cadre d’un audit NIS2 dans une entreprise industrielle : comment vérifier si l’organisation est prête à assumer ses nouvelles obligations.

Les crédits de service et les indemnisations symboliques ne rétablissent pas un processus et ne réduisent pas les conséquences d’un arrêt. L’obligation de présenter un plan d’amélioration, l’escalade au niveau de la direction, des tests de résilience complémentaires et le droit de résilier le contrat en cas de non-respect durable ou répété des niveaux convenus sont généralement plus structurants. Une sanction financière peut renforcer la responsabilisation, mais elle ne remplace ni le dispositif de rétablissement du service, ni l’élimination des causes, ni la prévention des récidives.

Incidents et obligations de notification

Le contrat devrait obliger le prestataire à signaler sans délai tout événement susceptible d’affecter le service, les données, la continuité d’activité ou la sécurité du client. La première alerte ne doit pas dépendre de la confirmation complète de la cause, de l’étendue des dommages ou de la qualification juridique de l’événement. Le délai contractuel doit intégrer une marge permettant au client de mener sa propre évaluation et de respecter, le cas échéant, les délais de notification externes. Il doit être déterminé en fonction de la criticité du service et de la disponibilité d’un point de contact joignable 24 heures sur 24, et non selon la seule commodité organisationnelle des parties.

Le flux d’information doit être structuré en quatre étapes : alerte initiale, points de situation, rapport post-incident et analyse des causes racines. Pour chaque étape, il convient de définir les données attendues, le canal autorisé, les destinataires, la fréquence des mises à jour et les règles d’escalade en l’absence de réponse. La première notification devrait au minimum mentionner l’heure de détection, les actifs et services affectés, l’impact estimé, les actions engagées, les indicateurs techniques disponibles, le risque de propagation et l’heure prévue de la prochaine mise à jour. La liste des contacts doit prévoir des suppléants et être testée périodiquement, y compris en dehors des heures ouvrées.

Si le prestataire détecte un trafic inhabituel dans l’environnement hébergeant une application critique, il devrait alerter le client avant même de déterminer s’il s’agit d’une violation avérée. Le client déclenche son propre processus de gestion des incidents, désigne la personne habilitée à prendre les décisions, mobilise l’équipe de réponse et, le cas échéant, l’assureur, puis détermine qui valide la notification externe et la communication aux clients. Le prestataire préserve les journaux et traces techniques convenus, contribue à l’analyse, à l’endiguement et à l’évaluation du périmètre de l’événement, mais ne reprend pas à son compte la responsabilité réglementaire du client.

Les clauses devraient également définir les règles de conservation et de mise à disposition des preuves, la protection de leur intégrité, la traçabilité des décisions et la préparation des informations nécessaires aux notifications et à l’analyse ultérieure des causes racines. Les délais, destinataires et contenus des notifications externes doivent être vérifiés au cas par cas au regard du droit en vigueur, du statut de l’organisation et de la nature de l’événement. Les registres de notifications, de décisions, d’escalades et d’actions doivent être mis en cohérence avec l’article Documentation NIS2 et KSC avant un contrôle : politiques, registres et preuves réellement nécessaires, tandis que le calendrier de mise en conformité peut être rapproché de l’article Mise en œuvre de NIS2 après l’inscription au registre KSC : plan d’action jusqu’au 3 avril 2027.

Mise en œuvre, surveillance et réversibilité sécurisée

La signature d’un avenant ne clôt pas le processus de gestion du prestataire. Le responsable du contrat doit organiser des revues périodiques des résultats du SLA, des incidents, des dérogations, des actions correctives, des changements de sous-traitants et de l’actualité des preuves attestant le respect des exigences. Le pilotage doit s’appuyer sur un registre des contrats précisant au minimum la date de renouvellement, le responsable, la criticité du service et l’état de validation des mesures de sécurité. Une déclaration de conformité ne remplace ni les rapports, ni les résultats des tests, ni les enregistrements démontrant l’exécution des obligations.

Avant le renouvellement du contrat ou toute modification importante du service, il convient de réévaluer sa criticité, ses dépendances techniques et opérationnelles, la concentration des services chez un même prestataire, l’applicabilité des mesures de sécurité et la capacité à basculer vers une solution de remplacement. Cette revue permet de décider si un avenant suffit ou si une nouvelle procédure d’achat est nécessaire. Lorsqu’un prestataire stratégique refuse un audit ou une modification contractuelle, l’organisation doit documenter l’écart et choisir entre la mise en place d’une mesure compensatoire, l’acceptation formelle du risque résiduel ou le changement de prestataire.

Le plan de réversibilité doit être opérationnel avant même la résiliation du contrat. Il devrait couvrir la restitution et le transfert des données dans un format exploitable, l’assistance à la migration, le maintien de la continuité pendant la transition, le retrait des accès, la suppression des copies et la confirmation de l’exécution de ces opérations. Les enregistrements nécessaires à des fins juridiques, probatoires et d’audit doivent parallèlement être conservés. Un test pertinent consiste à restaurer les données auprès d’un autre prestataire, puis à vérifier leur exhaustivité, le temps de migration et la possibilité de désactiver les anciens comptes.

La mise à niveau du portefeuille contractuel doit commencer par les services ayant le plus fort impact sur l’activité, puis les écarts doivent être hiérarchisés selon leurs conséquences et leur urgence. L’efficacité des mécanismes retenus peut être vérifiée au moyen d’un exercice de gestion d’incident et d’un audit par échantillonnage des preuves. Les résultats des revues de SLA, des incidents, des dérogations, des actions correctives et des tests de réversibilité montreront si les exigences fonctionnent réellement ou restent de simples clauses contractuelles.

Le périmètre d’évaluation peut être rapproché de l’article Audit NIS2 dans une entreprise industrielle : comment vérifier si l’organisation est prête à assumer ses nouvelles obligations. Les obligations de l’organisation doivent également être déterminées en fonction de son statut, présenté dans l’article Directive NIS2 : quelles organisations sont concernées et quelles entreprises doivent satisfaire aux nouvelles exigences ?