Gestion des correctifs : obligations et méthode 2026

Dans son Panorama de la cybermenace 2025, l’ANSSI décrit une année dominée par un même scénario : des équipements de bordure — VPN, pare-feux, passerelles — compromis par des vulnérabilités connues et publiées. Ivanti Connect Secure, Citrix NetScaler, Microsoft SharePoint : les correctifs existaient. Ce qui manquait, c’était la procédure pour les appliquer. Depuis le 7 novembre 2024, cette procédure n’est plus une bonne pratique : pour une partie des entreprises, c’est une obligation écrite, opposable et contrôlable.

Gestion des correctifs : ce que le droit exige vraiment

La question m’est posée dans presque chaque audit : « existe-t-il un texte qui m’impose de mettre à jour mes serveurs ? » La réponse est oui, mais elle vient de quatre directions différentes, et leur articulation détermine votre niveau d’exigence réel.

L’article 32 du RGPD : l’obligation implicite mais opposable

L’article 32 du RGPD ne prononce jamais le mot « correctif ». Il impose des mesures techniques appropriées au risque, en tenant compte de « l’état de l’art », et cite expressément à l’Art. 32(1)(b) les moyens permettant de garantir « la confidentialité, l’intégrité, la disponibilité et la résilience constantes des systèmes ». L’adverbe constantes fait tout le travail : une sécurité appropriée au jour de la mise en production, mais qui se dégrade à mesure que les vulnérabilités sont publiées, n’est pas une sécurité conforme.

L’Art. 32(1)(d) complète le dispositif en exigeant « une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles ». Autrement dit : le RGPD n’impose pas un correctif, il impose un processus de maintien du niveau de sécurité dans le temps.

La CNIL a traduit cette exigence en recommandations opérationnelles dans son Guide de la sécurité des données personnelles (version 2024, mise à jour 2026). Trois fiches sont directement concernées :

• Fiche n°6 (Sécuriser les postes de travail) : « Déployer les mises à jour critiques des systèmes d’exploitation sans délai (le cas échéant après les avoir testées) en programmant une vérification automatique hebdomadaire » et « prévoir une politique des mises à jour fonctionnelles ».
• Fiche n°9 (Sécuriser les serveurs) : « Installer les mises à jour critiques sans délai (le cas échéant après les avoir testées), en particulier les correctifs de sécurité, que ce soit pour les systèmes d’exploitation ou pour les applications, en programmant une vérification automatique hebdomadaire ». La même fiche range explicitement parmi ce qu’il ne faut pas faire : « traiter des données personnelles sur des serveurs obsolètes et ne pas prévoir le remplacement de ces derniers ».
• Fiche n°15 (Encadrer la maintenance et la fin de vie des matériels et logiciels) : interdiction d’installer des applications de télémaintenance présentant des vulnérabilités connues, et encadrement contractuel des interventions de support.

Ces fiches n’ont pas de valeur normative autonome. Elles ont une valeur probatoire considérable : lorsque la formation restreinte apprécie le caractère « approprié » d’une mesure au sens de l’Art. 32, l’écart entre votre pratique et le guide de la CNIL est le premier élément versé au débat. Vous retrouverez la même logique dans notre analyse des 12 mesures de sécurité exigées par la CNIL.

NIS2 et le règlement d’exécution 2024/2690 : l’obligation explicite

C’est ici que le paysage a basculé. La directive NIS2 impose à l’article 21(2)(e) des mesures couvrant « la sécurité de l’acquisition, du développement et de la maintenance des réseaux et des systèmes d’information, y compris le traitement et la divulgation des vulnérabilités ». Le texte reste général — mais le règlement d’exécution (UE) 2024/2690 du 17 octobre 2024, applicable depuis le 7 novembre 2024 sans transposition nationale, le décline en exigences précises.

Son annexe consacre un point entier, le point 6.6 « Gestion des correctifs de sécurité », qui impose des procédures — cohérentes avec la gestion des changements (point 6.4), la gestion des vulnérabilités (point 6.10) et la gestion des risques — garantissant que :

1. les correctifs de sécurité sont appliqués dans un délai raisonnable après leur mise à disposition ;
2. les correctifs sont testés avant leur déploiement en production ;
3. les correctifs proviennent de sources de confiance et leur intégrité est vérifiée ;
4. lorsqu’un correctif n’est pas disponible ou n’est pas appliqué, des mesures additionnelles sont mises en œuvre et le risque résiduel est accepté formellement.

Le point 6.6.2 autorise expressément une dérogation : l’entité peut choisir de ne pas appliquer un correctif « lorsque les inconvénients de son application l’emportent sur les bénéfices en matière de cybersécurité » — mais elle doit alors documenter et justifier cette décision. C’est, à ma connaissance, la première fois qu’un texte européen consacre explicitement le droit de ne pas patcher, à condition de l’écrire.

Le point 6.10 « Traitement et divulgation des vulnérabilités » complète le tableau : veille via les canaux appropriés (CSIRT, autorités compétentes, fournisseurs), scans de vulnérabilités à intervalles planifiés avec conservation des preuves, traitement « sans retard indu » des vulnérabilités identifiées comme critiques, et procédure de divulgation conforme à la politique nationale de divulgation coordonnée.

Attention au champ d’application : le règlement 2024/2690 s’impose directement aux entités de l’infrastructure numérique et des services numériques (fournisseurs de services DNS, registres de noms de domaine, fournisseurs de services cloud, de centres de données, de CDN, de services managés de sécurité, places de marché, moteurs de recherche, réseaux sociaux, prestataires de services de confiance). Pour les autres secteurs couverts par NIS2, il constitue le référentiel de fait que les autorités nationales utiliseront pour apprécier le caractère approprié des mesures. Notre checklist de conformité NIS2 et notre analyse des entités essentielles et importantes permettent de situer votre organisation.

Le CRA : l’obligation vue du côté fournisseur

Le Cyber Résilience Act (règlement (UE) 2024/2847) inverse la perspective : il ne vous impose pas d’appliquer les correctifs, il impose à vos fournisseurs de vous les fournir. L’article 13(8) exige des fabricants qu’ils assurent la gestion des vulnérabilités et fournissent des mises à jour de sécurité pendant la durée de vie attendue du produit, avec un plancher de cinq ans. Ces mises à jour doivent être gratuites — elles ne peuvent pas être conditionnées à un abonnement.

L’effet pratique pour un acheteur est considérable, et il est déjà exploitable dans vos appels d’offres : la période de support sécurité devient un critère contractuel documenté, et le fabricant doit vous notifier l’approche de sa fin. Voir aussi nos analyses de la gestion des vulnérabilités sous le CRA et des obligations des éditeurs SaaS.

Vue d’ensemble des exigences

Texte	Ce qui est exigé	Qui est concerné
RGPD Art. 32(1)(b) et (d)	Sécurité et résilience « constantes » ; procédure d’évaluation régulière de l’efficacité des mesures	Tout responsable de traitement et sous-traitant
Guide CNIL 2024, fiches 6, 9 et 15	Mises à jour critiques sans délai, vérification automatique hebdomadaire, politique de mises à jour, pas de traitement sur serveurs obsolètes	Référentiel d’appréciation de l’Art. 32
NIS2 Art. 21(2)(e)	Sécurité de la maintenance, traitement et divulgation des vulnérabilités	Entités essentielles et importantes
Règlement (UE) 2024/2690, points 6.6 et 6.10	Procédure écrite : délai raisonnable, test préalable, source de confiance, mesures compensatoires et acceptation du risque résiduel	Entités de l’infrastructure et des services numériques (référentiel de fait pour les autres)
CRA Art. 13(8)	Mises à jour de sécurité gratuites pendant la durée de vie attendue, minimum 5 ans	Fabricants de produits comportant des éléments numériques
ISO/IEC 27001:2022, mesure 8.8	Gestion des vulnérabilités techniques	Organismes certifiés ou en cours de certification

Sans inventaire, pas de gestion des correctifs

Toutes les procédures de correctifs que j’ai vues échouer avaient le même défaut d’origine : elles couvraient parfaitement le parc connu et ignoraient totalement le reste. Le point 6.6 du règlement 2024/2690 suppose un actif recensé ; il ne crée pas l’inventaire.

L’inventaire utile n’est pas une liste de machines. C’est une table croisée entre trois dimensions :

• Les actifs techniques : systèmes d’exploitation, hyperviseurs, équipements réseau, applications métier, bibliothèques et dépendances, images de conteneurs, firmwares, terminaux mobiles. Pour les logiciels que vous développez ou intégrez, la nomenclature logicielle (SBOM) est le seul moyen fiable de savoir quelles dépendances transitives vous exposent — c’est précisément ce que le CRA impose désormais aux fabricants.
• L’exposition : accessible depuis Internet, accessible depuis le réseau interne, isolé. Cette variable est la plus discriminante de toutes. L’ANSSI l’a rappelé pour 2025 : les équipements de bordure concentrent l’essentiel des compromissions initiales, parce qu’ils sont par construction exposés et souvent mal instrumentés.
• Les données traitées : votre registre des activités de traitement indique quels traitements portent sur des données sensibles au sens de l’Art. 9, sur des mineurs, sur des données bancaires. Un serveur applicatif hébergeant un traitement de santé n’a pas le même délai de correction qu’un serveur d’impression.

Le croisement de ces trois dimensions donne votre criticité par actif. Sans lui, toute grille de priorisation reste théorique. Une analyse de risques EBIOS RM ou ISO 27005 fournit le cadre méthodologique ; un audit de sécurité informatique permet de vérifier que l’inventaire correspond à la réalité, ce qui n’est presque jamais le cas au premier passage.

Prioriser les correctifs : pourquoi le score CVSS ne suffit pas

Le réflexe majoritaire consiste à trier par score CVSS et à corriger d’abord ce qui est noté 9 ou 10. C’est une méthode qui produit mécaniquement du retard : le volume de vulnérabilités critiques publiées chaque mois dépasse la capacité de traitement d’une DSI de PME, et le CVSS mesure une gravité théorique, pas une probabilité d’exploitation.

Trois signaux complémentaires changent la donne :

• L’exploitation avérée. Une vulnérabilité effectivement exploitée dans la nature n’a pas le même statut qu’une vulnérabilité théorique de score identique. Le catalogue KEV (Known Exploited Vulnerabilities) de la CISA américaine et les avis du CERT-FR signalent ces cas. Une CVE au catalogue KEV se traite comme un incident, pas comme une tâche de maintenance.
• La probabilité d’exploitation. Le score EPSS (Exploit Prediction Scoring System) estime la probabilité qu’une vulnérabilité soit exploitée dans les trente jours. Il permet de dégonfler massivement une file d’attente de CVSS 9 dont la quasi-totalité ne sera jamais exploitée.
• Votre exposition réelle. Une vulnérabilité critique sur un composant non déployé, non exposé, ou dont la fonction vulnérable est désactivée, n’est pas votre urgence. C’est le raisonnement que le point 6.10.3 du règlement 2024/2690 encourage explicitement lorsqu’il autorise à « documenter et justifier la raison pour laquelle une vulnérabilité ne nécessite pas de remédiation ».

Une grille de délais cibles

Le règlement 2024/2690 parle de « délai raisonnable » sans le chiffrer. C’est à vous de le faire, dans votre politique, et de vous y tenir : un délai que vous vous êtes fixé et que vous ne respectez pas est plus dommageable en contrôle que l’absence de délai. Voici la grille que j’utilise comme point de départ dans mes missions, à ajuster selon votre analyse de risques.

Situation	Actif exposé sur Internet	Actif interne critique	Actif interne standard
CVE au catalogue KEV ou exploitation active signalée par le CERT-FR	24 à 48 h (procédure d’urgence)	72 h	7 jours
CVSS ≥ 9,0 sans exploitation connue	7 jours	15 jours	30 jours
CVSS 7,0 à 8,9	15 jours	30 jours	60 jours
CVSS 4,0 à 6,9	30 jours	60 jours	Cycle de maintenance
CVSS < 4,0	Cycle de maintenance	Cycle de maintenance	Cycle de maintenance

Deux précisions. D’abord, ces délais courent à compter de la publication du correctif par l’éditeur, pas de sa découverte par vos équipes : c’est votre veille qui doit s’aligner, pas l’inverse. Ensuite, la ligne « procédure d’urgence » suppose un circuit décisionnel distinct du cycle normal de gestion des changements, avec une autorité de déploiement identifiée et joignable — typiquement le RSSI ou son suppléant.

La procédure de gestion des correctifs en sept étapes

Le point 6.6.1 du règlement 2024/2690 exige une procédure « cohérente avec les procédures de gestion des changements ». Concrètement, cela signifie que votre gestion des correctifs n’est pas un processus autonome : c’est une voie rapide à l’intérieur de votre gestion des changements. Voici les sept étapes qui doivent y figurer.

1. Veille. Abonnement aux avis et alertes du CERT-FR, aux bulletins des éditeurs de votre parc et, le cas échéant, aux flux de votre CSIRT sectoriel. Le point 6.10.4 impose de réexaminer périodiquement la pertinence de ces canaux — un éditeur ajouté au parc sans ajout du canal correspondant est une faille de processus classique.

2. Qualification. Pour chaque avis : l’actif est-il présent dans mon parc ? Dans quelle version ? Est-il exposé ? Traite-t-il des données personnelles, et lesquelles ? Cette étape se fait en minutes si l’inventaire existe, en jours s’il n’existe pas. C’est là que se joue l’essentiel du délai réel.

3. Priorisation. Application de la grille ci-dessus, avec une décision tracée : délai cible, responsable, fenêtre de déploiement.

4. Vérification de la source et de l’intégrité. Le point 6.6.1© l’exige explicitement : le correctif doit provenir d’une source de confiance et son intégrité doit être vérifiée (signature, empreinte). Les campagnes de faux correctifs sont un vecteur d’attaque documenté ; télécharger un patch sur un miroir non officiel annule le bénéfice de l’opération.

5. Test. Le point 6.6.1(b) impose un test avant production. En pratique, l’environnement de pré-production doit être représentatif, et la profondeur du test doit être inversement proportionnelle à l’urgence : sur une CVE activement exploitée en bordure, un test de non-régression fonctionnelle de deux heures vaut mieux qu’une campagne complète de trois semaines. Prévoyez une sauvegarde restaurable et un plan de retour arrière avant tout déploiement, y compris en urgence.

6. Déploiement et vérification. Le déploiement n’est pas la fin de l’opération : il faut vérifier que le correctif est effectivement appliqué sur l’ensemble du périmètre visé. L’écart entre « correctif poussé » et « correctif appliqué » est la source d’erreur la plus fréquente sur les parcs distribués, les postes nomades et les machines éteintes pendant la fenêtre de déploiement.

7. Documentation. Date de publication, date de qualification, date de déploiement, périmètre couvert, écarts et justification. Cette traçabilité est ce que vous produirez en contrôle CNIL ou en inspection NIS2. Sans elle, vous ne pourrez pas démontrer que vos délais sont tenus — et le fardeau de la preuve pèse sur vous au titre du principe d’accountability de l’Art. 5(2).

Le cas des correctifs qu’on ne peut pas appliquer

C’est la situation qui inquiète le plus mes clients, et c’est celle que le droit traite le mieux. Un correctif indisponible, un logiciel métier incompatible, un automate industriel dont la mise à jour invaliderait la certification : ces cas existent, et ils ne vous placent pas automatiquement en infraction.

Le point 6.6.1(d) du règlement 2024/2690 exige alors deux choses : des mesures additionnelles et une acceptation formelle du risque résiduel. Le point 6.6.2 ajoute la possibilité de renoncer volontairement à un correctif dont les inconvénients dépassent les bénéfices, sous réserve de documentation et de justification.

Les mesures compensatoires reconnues comme état de l’art sont bien identifiées :

• Isolement réseau. La fiche n°9 du guide CNIL le formule directement : « isoler les serveurs obsolètes mais essentiels et limiter le traitement de données personnelles » sur ces systèmes. Segmentation, VLAN dédié, filtrage strict des flux entrants et sortants.
• Réduction de la surface. Désactivation du composant vulnérable, fermeture du port, désinstallation du module non utilisé. Souvent la mesure la plus efficace et la moins coûteuse.
• Détection renforcée. Règles de détection spécifiques à la vulnérabilité, journalisation accrue sur l’actif concerné, alerte sur les motifs d’exploitation connus. C’est exactement le manquement retenu par la CNIL dans les sanctions de janvier 2026 contre Free et Free Mobile : les exfiltrations massives n’ont pas déclenché d’alerte en temps utile.
• Restriction d’accès. Renforcement de l’authentification, réduction du périmètre des habilitations sur les comptes pouvant atteindre l’actif vulnérable.
• Plan de remédiation daté. Une exception permanente n’est pas une exception : c’est un choix architectural non assumé. Toute dérogation doit comporter une date de réexamen et, à terme, un plan de migration ou de remplacement.

Un point de vigilance juridique important : l’acceptation du risque résiduel n’est pas une décision technique. Elle engage la responsabilité de la direction, et la directive NIS2 fait peser sur les organes de direction l’approbation des mesures de gestion des risques. Un registre des dérogations signé par le seul administrateur système n’a aucune valeur probatoire en contrôle.

Fin de support : le point aveugle des politiques de correctifs

Une politique de correctifs bien rédigée peut être parfaitement respectée et laisser passer le risque le plus grave : un système qui ne reçoit plus de correctifs du tout. Ce n’est pas un problème de gestion des correctifs, c’est un problème de gestion du cycle de vie — et c’est celui que la CNIL vise lorsqu’elle interdit de « traiter des données personnelles sur des serveurs obsolètes et ne pas prévoir le remplacement de ces derniers ».

Trois réflexes à intégrer :

• Suivre les dates de fin de support de tous les composants de l’inventaire, y compris les dépendances applicatives et les firmwares. La date de fin de support est une donnée d’inventaire au même titre que la version.
• Planifier la migration douze mois avant, pas trois. Un remplacement de socle applicatif dans l’urgence produit systématiquement des régressions de sécurité.
• Exiger contractuellement la durée de support. Depuis le CRA, c’est une obligation légale du fabricant pour les produits comportant des éléments numériques, et donc une clause que vous pouvez opposer. La période de support et le mécanisme de signalement des vulnérabilités doivent figurer au contrat.

Correctifs et chaîne de sous-traitance

Une large part de votre parc n’est pas administrée par vous. Infogérance, SaaS, hébergement managé, cloud : la gestion des correctifs se joue alors dans le contrat.

Côté RGPD, l’article 28 du RGPD impose que le contrat de sous-traitance décrive les mesures de sécurité de l’Art. 32. Une clause qui se contente d’écrire que le sous-traitant « met en œuvre des mesures appropriées » ne vous protège pas : il faut des engagements chiffrés — délais de correction par niveau de criticité, obligation d’information sur les vulnérabilités affectant le service, droit d’audit ou production d’un rapport de conformité.

Côté NIS2, le point 5.1 du règlement 2024/2690 impose d’inclure dans les contrats fournisseurs « une obligation, pour les fournisseurs et prestataires, de traiter les vulnérabilités qui présentent un risque pour la sécurité des réseaux et systèmes d’information de l’entité ». Nos analyses de la sous-traitance sécurité sous NIS2 et RGPD et de la responsabilité partagée dans le cloud détaillent la répartition réelle des tâches, qui n’est jamais celle que le commercial a décrite.

En cloud IaaS notamment, le fournisseur patche l’hyperviseur et le socle ; vous patchez le système d’exploitation invité, les runtimes et les applications. Cette frontière est la source la plus fréquente de vulnérabilités orphelines : chacun considère que l’autre s’en charge.

Quand le correctif manquant devient une violation de données

Si une vulnérabilité non corrigée est exploitée et qu’elle donne accès à des données personnelles, vous entrez dans le régime de la violation de données. Le compte à rebours de 72 heures de l’Art. 33(1) commence à la prise de connaissance, et la procédure de gestion de la fuite de données doit être déclenchée en parallèle de la remédiation technique.

Deux points méritent l’attention. D’une part, la notification à la CNIL doit décrire les mesures prises pour remédier à la violation : c’est le moment où l’absence de politique de correctifs devient visible, documentée par vous-même. D’autre part, selon votre statut, l’incident peut déclencher plusieurs notifications parallèles — CNIL sous 72 heures, ANSSI au titre de NIS2 avec une alerte précoce sous 24 heures, autorité sectorielle. Notre guide de la notification d’une cyberattaque détaille ces circuits, et le plan de réponse aux incidents doit prévoir explicitement le cas de la vulnérabilité exploitée.

L’enjeu financier n’est pas théorique. Les pénalités NIS2 atteignent 10 millions d’euros ou 2 % du chiffre d’affaires mondial pour les entités essentielles, et l’Art. 83(4)(a) du RGPD plafonne à 10 millions d’euros ou 2 % pour un manquement à l’Art. 32. Ces plafonds se cumulent, chaque autorité agissant dans son champ.

Les six erreurs que je vois le plus souvent

Confondre gestion des correctifs et mises à jour automatiques. L’activation de Windows Update ne constitue pas une politique. Elle ne couvre ni les applications tierces, ni les firmwares, ni les équipements réseau, ni les dépendances applicatives — c’est-à-dire l’essentiel de la surface d’attaque réelle.

Écrire des délais qu’on ne tient pas. Une politique annonçant « correction sous 48 heures pour toute vulnérabilité critique » alors que le délai réel est de six semaines constitue un aveu écrit. Mieux vaut un délai réaliste tenu qu’un délai ambitieux systématiquement dépassé.

Ignorer les postes nomades et les machines éteintes. Le taux de couverture affiché par l’outil de déploiement est calculé sur les machines vues. Vérifiez le dénominateur.

Ne pas tracer les exceptions. Une dérogation non écrite n’existe pas juridiquement. En contrôle, elle apparaîtra comme une négligence, pas comme une décision.

Traiter la bordure comme le reste. Pare-feux, concentrateurs VPN et passerelles doivent relever d’un cycle distinct et accéléré. C’est là que les compromissions commencent, et c’est précisément le constat de l’ANSSI pour 2025.

Séparer correctifs et tests offensifs. Un test d’intrusion qui révèle une version obsolète mais ne débouche pas sur un correctif daté et vérifié ne sert qu’à documenter votre connaissance du risque — ce qui aggrave votre situation plutôt que de l’améliorer.

Ce qu’il faut retenir

• La gestion des correctifs est une obligation juridique explicite depuis le règlement d’exécution (UE) 2024/2690, dont le point 6.6 impose une procédure écrite : délai raisonnable, test préalable, source de confiance vérifiée, mesures compensatoires et acceptation formelle du risque résiduel.
• Sous le RGPD, l’obligation est implicite mais opposable : l’Art. 32(1)(b) exige une sécurité « constante » et l’Art. 32(1)(d) une procédure d’évaluation régulière. Le guide CNIL 2024 (fiches n°6, 9 et 15) constitue le référentiel d’appréciation en contrôle.
• Le score CVSS seul produit du retard. Croisez-le avec l’exploitation avérée (catalogue KEV, avis CERT-FR), la probabilité d’exploitation (EPSS) et votre exposition réelle, puis fixez des délais cibles par combinaison criticité × exposition.
• Ne pas patcher est licite si c’est documenté. Le point 6.6.2 autorise expressément la renonciation motivée, à condition d’écrire les mesures compensatoires, d’accepter formellement le risque résiduel au niveau de la direction et de dater le réexamen.
• La fin de support est le risque le plus sous-estimé. La date de fin de support est une donnée d’inventaire ; la CNIL interdit de traiter des données personnelles sur des serveurs obsolètes sans plan de remplacement, et le CRA vous donne désormais un levier contractuel de cinq ans minimum face à vos fournisseurs.

---

Recevez nos analyses conformité chaque semaine. Décisions CNIL décryptées, échéances réglementaires, méthodes applicables : inscrivez-vous à la newsletter.

---

FAQ

Existe-t-il un délai légal pour appliquer un correctif de sécurité ?

Aucun texte ne fixe de délai chiffré universel. Le règlement d’exécution (UE) 2024/2690 parle d’un « délai raisonnable » après la mise à disposition du correctif, et la CNIL recommande dans son guide 2024 d’installer « sans délai » les mises à jour critiques, avec une vérification automatique hebdomadaire. C’est donc à chaque organisation de fixer ses propres délais cibles dans sa politique, en fonction de son analyse de risques — et de démontrer qu’elle les tient.

Peut-on être sanctionné pour ne pas avoir appliqué un correctif ?

Oui, mais indirectement. La CNIL ne sanctionne pas l’absence de correctif en tant que telle : elle sanctionne le manquement à l’obligation de sécurité de l’Art. 32 lorsque les mesures n’étaient pas appropriées au risque compte tenu de l’état de l’art. Une vulnérabilité publique, corrigée par l’éditeur depuis plusieurs mois et exploitée pour accéder à des données personnelles, caractérise ce manquement avec une facilité redoutable en procédure.

Que faire quand un logiciel métier interdit d’appliquer un correctif ?

Documentez la situation et compensez. Le point 6.6.1(d) du règlement 2024/2690 prévoit ce cas : mesures additionnelles (isolement réseau, désactivation du composant vulnérable, détection renforcée, restriction des accès) et acceptation formelle du risque résiduel par une autorité compétente au sein de l’organisation. Ajoutez une date de réexamen et un plan de migration : une exception sans échéance devient une négligence.

Qui est responsable des correctifs sur un service cloud ?

Cela dépend du modèle. En SaaS, le fournisseur patche l’ensemble de la pile applicative. En PaaS, il patche le socle et vous restez responsable de votre code et de ses dépendances. En IaaS, il patche l’hyperviseur et l’infrastructure ; le système d’exploitation invité, les runtimes et les applications vous incombent. Cette répartition doit figurer dans le contrat au titre de l’Art. 28(3)© du RGPD, et non dans la documentation commerciale du fournisseur.

La gestion des correctifs doit-elle figurer dans un document formel ?

Pour les entités soumises au règlement 2024/2690, oui : le point 6.6 impose des procédures spécifiées et appliquées. Pour les autres, la politique de correctifs s’intègre naturellement dans la politique de sécurité des systèmes d’information (PSSI), avec un renvoi depuis la procédure de gestion des changements. Dans les deux cas, l’écrit n’est pas une formalité : c’est la seule preuve exploitable en contrôle.