Politique de gestion des correctifs : pourquoi en avoir une et comment la mettre en place

La plupart des politiques de gestion des correctifs échouent de la même manière. Elles semblent parfaites sur le papier, restent rangées dans un dossier SharePoint, sont présentées à l'auditeur une fois par an et n'ont pratiquement aucun rapport avec ce qui se passe réellement sur les terminaux. Les accords de niveau de service (SLA) relèvent de l'utopie. La liste des rôles mentionne une personne qui a quitté l'entreprise il y a deux ans. Personne ne peut vous dire quand elle a été révisée pour la dernière fois — ni ce qui a changé si tel a été le cas.

Une politique de gestion des correctifs est censée être le document qui garantit l'application effective des mises à jour. Elle définit quels éléments doivent être mis à jour, dans quels délais, par qui, avec quelles exceptions et comment prouver que cela a bien été fait. Lorsqu'elle est bien rédigée, elle résiste aux changements de personnel, satisfait aux exigences d'audit et offre à l'équipe un argument de poids lorsque les responsables opérationnels s'opposent à une fenêtre de maintenance. Lorsqu'elle est mal rédigée, elle n'est qu'un simple alibi de conformité.

Ce guide présente les éléments constitutifs d'une politique de gestion des correctifs efficace, les accords de niveau de service (SLA) adaptés aux délais imposés par les menaces actuelles, ainsi que la manière de structurer le document pour qu'il soit applicable et non pas simplement théorique. Les solutions RMM de Kaseya gèrent l'application des correctifs sur des millions de terminaux pour le compte de prestataires de services gérés (MSP) et d'équipes informatiques internes, ce qui permet de se faire une idée assez précise des structures de politique qui sont suivies dans la pratique et de celles qui sont discrètement ignorées.

Qu'est-ce qu'une politique de gestion des correctifs ?

Une politique de gestion des correctifs est le document de référence qui définit la manière dont une organisation identifie, évalue, déploie et vérifie les mises à jour logicielles. Elle établit les normes, les délais et les responsabilités liés à l'application des correctifs, tandis que le processus de gestion des correctifs correspond au flux de travail opérationnel quotidien utilisé pour mettre en œuvre ces normes. (Si vous avez besoin d'une définition de base avant d'aller plus loin, notre article de référence sur la gestion des correctifs constitue un excellent point de départ.)

Cette distinction est importante, car la plupart des équipes confondent les deux. Une politique n'est pas un guide opérationnel. Elle n'indique pas à un ingénieur sur quel bouton cliquer dans l'outil de gestion à distance (RMM). Elle précise à l'organisation que les correctifs critiques doivent être déployés dans un délai défini, qu'un rôle spécifique en est responsable et que toute exception nécessite une validation documentée. Les guides opérationnels permettent de mettre en œuvre la politique. La politique permet de justifier le travail opérationnel.

Pourquoi avons-nous besoin d'une politique de gestion des correctifs ?

Une politique de gestion des correctifs s'impose pour trois raisons, classées par ordre d'importance approximatif :

Le premier point concerne l'applicabilité. En l'absence de politique, chaque déploiement de correctifs donne lieu à une négociation. Les responsables d'applications plaident en faveur de reports, les divisions opérationnelles s'opposent aux redémarrages, et l'équipe chargée de la gestion des correctifs ne dispose d'aucune autorité officielle pour passer outre. Une politique approuvée par la direction confère à l'équipe chargée des correctifs un mandat formel.

Le deuxième aspect concerne l'audit. Presque tous les cadres de conformité modernes exigent une approche documentée en matière de correctifs, et les auditeurs recherchent une véritable politique, et non une simple mesure provisoire. La norme PCI DSS 4.0, par exemple, exige que les correctifs de sécurité soient installés dans un délai d'un mois à compter de leur publication pour les systèmes critiques. La loi HIPAA exige des mesures de protection techniques « raisonnables et appropriées », que les évaluateurs interprètent comme une gestion documentée des correctifs avec des résultats mesurables. La norme ISO 27001:2002, annexe A 8.8, traite explicitement de la gestion des vulnérabilités, dont l'application de correctifs constitue le cœur opérationnel. La directive NIS2, en vigueur dans toute l'UE, exige des preuves de la gestion des vulnérabilités pour les organisations concernées. Le critère CC7.1 des Trust Services Criteria de la norme SOC 2 exige la surveillance et la correction des nouvelles vulnérabilités. Aucune de ces normes n'accepte la réponse « nous appliquons les correctifs quand nous le pouvons ».

Le troisième élément est la continuité. Les personnes partent, les outils évoluent, les priorités changent. C'est grâce à une politique écrite qu'un nouveau directeur informatique peut reprendre un programme de mise à jour sans avoir à le recréer de toutes pièces.

Le cas de non-conformité en détail

Il est important de préciser clairement ce qu'exigent les principaux cadres réglementaires, car c'est souvent à cause de résumés trop vagues que les politiques finissent par ne pas respecter les exigences qui font l'objet d'un audit.

La norme PCI DSS 4.0 exige que les correctifs de sécurité critiques soient installés sur les systèmes concernés dans un délai d'un mois à compter de leur publication, et qu'une approche fondée sur les risques soit documentée pour les correctifs non critiques. La version 4.0 a renforcé les exigences en matière de hiérarchisation fondée sur les risques, ce qui signifie qu'une approche reposant uniquement sur le CVSS pourrait ne plus satisfaire un évaluateur rigoureux.

La règle de sécurité HIPAA ne fixe pas de délais précis, mais exige des entités concernées qu'elles « mettent en place des procédures visant à prévenir, détecter et signaler les logiciels malveillants » et qu'elles « mettent en œuvre des mesures de sécurité suffisantes pour réduire les risques et les vulnérabilités à un niveau raisonnable et approprié ». Dans la pratique, les mesures coercitives prises par l'OCR du HHS ont considéré les retards de plusieurs mois dans l'application de correctifs pour des vulnérabilités connues comme un manquement à la règle de sécurité.

La norme ISO 27001:2022, annexe A, paragraphe 8.8 (Gestion des vulnérabilités techniques), exige que les informations relatives aux vulnérabilités techniques soient recueillies en temps opportun, que l'exposition de l'organisation soit évaluée et que des mesures appropriées soient prises. Les auditeurs s'attendent à voir une politique écrite, des accords de niveau de service (SLA) clairement définis et des preuves de leur mise en œuvre.

La directive NIS2 impose aux entités essentielles et importantes des secteurs critiques de l'UE de gérer les vulnérabilités et les divulgations. Les modalités de mise en œuvre varient d'un État membre à l'autre, mais l'application documentée de correctifs, assortie de délais de réponse mesurables, est une exigence commune.

Le critère CC7.1 des Trust Services du SOC 2 exige que l'entité détecte les incidents de sécurité et les vulnérabilités et y réagisse. Une politique de gestion des correctifs fait partie des éléments de preuve standard examinés par les auditeurs.

Le NIST CSF 2.0, dans le cadre de la fonction « Protéger » (PR.PS-02), préconise que les logiciels soient maintenus, remplacés et supprimés en fonction des risques, ce qui, dans la pratique, implique une gestion documentée des correctifs.

Si vous rédigez une politique principalement dans le but de passer un audit, basez-vous sur le référentiel le plus exigeant auquel vous êtes soumis. Les autres en découleront naturellement.

Les éléments d'une politique efficace de gestion des correctifs

Une politique de gestion des correctifs comporte environ dix sections. Certains modèles les divisent ou les regroupent différemment, mais le fond reste le même. En omettant l'une d'entre elles, on crée une lacune qu'un auditeur ne manquera pas de repérer.

1. Objet et champ d'application

Précisez l'objectif de la politique et ce qu'elle couvre. L'objectif peut être formulé en une ou deux phrases : cette politique garantit l'identification, l'évaluation et le déploiement rapides des mises à jour logicielles afin d'assurer la sécurité, la stabilité et la conformité. Le champ d'application est plus important, mais il est souvent négligé. Il doit préciser :

• Quels sont les équipements couverts par la police (serveurs, postes de travail, ordinateurs portables, appareils mobiles, machines virtuelles, conteneurs, équipements réseau, IoT, micrologiciels)
• Quels types de logiciels (systèmes d'exploitation, applications, logiciels tiers, micrologiciels)
• Quels environnements (production, préproduction, développement, BYOD le cas échéant)
• Quels acteurs (salariés, prestataires, systèmes gérés par des tiers)

C'est souvent lorsque la portée d'une politique présente des lacunes que des anomalies sont mises en évidence lors d'un audit. Si la politique ne couvre pas explicitement les micrologiciels réseau ou les applications tierces, l'équipe risque de débattre indéfiniment pour savoir si cela aurait dû être le cas.

2. Rôles et responsabilités

Chaque section de la politique doit correspondre à un rôle bien défini. Les politiques génériques recourent à des rôles génériques ; les politiques efficaces désignent des fonctions spécifiques et précisent les responsabilités de chacune. Une structure efficace :

• Responsable de la gestion des correctifs (généralement le RSSI ou le directeur informatique). Est responsable de la politique. Approuve les exceptions. Examine les rapports de conformité. Instance de recours en dernier ressort.
• Responsable de l'équipe de gestion des correctifs (un responsable des opérations informatiques ou de la sécurité). Est en charge du programme opérationnel. Établit le calendrier de déploiement des correctifs. Assure la coordination avec les responsables des applications.
• Administrateurs système. Appliquer les correctifs sur les systèmes qui leur sont attribués. Gérer les environnements de test. Effectuer des restaurations si nécessaire.
• Responsables d'applications. Identifier les applications stratégiques pour l'entreprise. Approuver les créneaux de maintenance. Vérifier le bon fonctionnement après l'application des correctifs.
• Équipe de sécurité. Surveiller les informations sur les menaces. Signaler les vulnérabilités urgentes. Suivre les listes KEV de la CISA et les CVE liés aux ransomwares. Vérifier la conformité.
• Responsables des actifs. Tenir un inventaire précis des actifs dont ils ont la charge.
• Utilisateurs finaux. Respectez les horaires de redémarrage. Ne désactivez pas les agents de mise à jour. Signalez tout problème lié aux mises à jour.

Les noms changent, les fonctions restent. La politique énumère les fonctions et comprend une annexe qui répertorie les personnes actuellement en poste, si votre structure de gouvernance l'exige.

3. Classification des correctifs et accords de niveau de service (SLA)

Il s'agit de la section la plus importante, et c'est celle où la plupart des politiques sont dangereusement obsolètes. Les scénarios de menaces sur lesquels reposaient des modèles datant de cinq ans ne sont plus d'actualité.

La classification répartit les correctifs en fonction de leur gravité et de leur vulnérabilité, puis associe chaque niveau à un accord de niveau de service (SLA) de déploiement. Voici à quoi ressemble un modèle défendable pour 2026 :

• Urgence / Vulnérabilité activement exploitée. Vulnérabilité répertoriée dans le catalogue KEV de la CISA, pour laquelle un exploit a été publié, sur un système concerné. Déployer dans un délai de 24 à 48 heures. Mise à jour hors cycle, tests accélérés, redémarrage obligatoire.
• Critique. CVSS 9,0 ou plus, ou toute vulnérabilité sur les systèmes exposés à Internet, quel que soit le score CVSS. Déployer dans un délai de 7 à 14 jours. Tests standard, déploiement planifié.
• Risque élevé. CVSS 7,0 à 8,9, sur les systèmes internes, aucune exploitation active. À mettre en œuvre dans les 30 jours.
• Risque moyen. CVSS 4.0 à 6,9. Déploiement dans un délai de 60 à 90 jours, généralement dans le cadre des cycles de maintenance habituels.
• Faible. Score CVSS inférieur à 4,0. Déploiement dans le cadre de la maintenance courante, aucun SLA spécifique requis.

Si ces délais se sont raccourcis, c'est parce que la nature des menaces a évolué. L'analyse réalisée par VulnCheck sur le premier semestre 2025 a révélé que 32,1 % des vulnérabilités répertoriées dans le KEV avaient été exploitées dans les 24 heures suivant leur divulgation, voire avant, contre 23,6 % l'année précédente. Une politique accordant 30 jours pour corriger les systèmes connectés à Internet revient, selon les données actuelles sur les menaces, à exposer pendant plusieurs semaines des systèmes à des vulnérabilités activement exploitées.

En ce qui concerne plus particulièrement les systèmes exposés à Internet, de nombreux programmes bien établis appliquent un SLA plus strict que celui indiqué dans le tableau ci-dessus. Le rapport DBIR 2025 de Verizon a recensé 17 vulnérabilités de périphériques de périphérie figurant sur la liste KEV et a constaté que le délai médian nécessaire pour y remédier complètement était de 209 jours, alors que les attaquants pouvaient les exploiter massivement en cinq jours. Une politique qui ne tient pas compte de cet écart est une politique qui s'inscrit dans un monde figé.

Quels que soient les accords de niveau de service (SLA) que vous définissez, exprimez-les en jours ouvrables, précisez à quel moment le délai commence à courir (publication par le fournisseur, référencement sur KEV ou détection de votre part ?) et précisez ce que signifie « corrigé » (déployé et vérifié, et pas simplement envoyé à la console de gestion).

4. Exigences en matière d'inventaire des actifs

La politique doit exiger un inventaire continu et automatisé de tous les actifs concernés, avec une responsabilité clairement attribuée quant à l'exactitude de cet inventaire. Il convient de préciser les données minimales à collecter pour chaque actif (nom d'hôte, système d'exploitation, version, niveau de correctifs, propriétaire, dernière vérification), la fréquence à laquelle l'inventaire est mis à jour, ainsi que le seuil en dessous duquel le programme est considéré comme non conforme à ses propres exigences. La plupart des politiques négligent cet aspect et ne peuvent ensuite expliquer pourquoi un hôte n'a pas été mis à jour pendant six mois. La raison est toujours la même : personne ne savait qu'il existait.

5. Normes relatives aux tests de correctifs et au déploiement

Définir la manière dont les correctifs sont testés avant leur déploiement à grande échelle. La politique ne prescrit pas les détails techniques ; elle définit les exigences. Une norme applicable :

• Les correctifs de routine suivent un cycle défini (phase pilote, validation, production), avec des délais d'attente entre chaque étape.
• Les correctifs d'urgence suivent une structure en anneau compressé (test de validation sur un déploiement pilote représentatif, puis déploiement à grande échelle) avec une acceptation des risques documentée.
• Les correctifs concernant les systèmes critiques pour l'activité doivent être expressément approuvés par le responsable de l'application avant leur déploiement en production.
• Les redémarrages rendus nécessaires par les correctifs sont programmés pendant les fenêtres de maintenance approuvées, sauf en cas d'urgence où le SLA prévaut sur ces fenêtres.
• Les déploiements ayant échoué déclenchent une nouvelle tentative automatique, puis une alerte est envoyée à l'équipe chargée des correctifs si la deuxième tentative échoue.

La raison pour laquelle nous avons choisi de formuler ces éléments sous forme de normes plutôt que de procédures est de permettre à l'équipe opérationnelle de modifier ses outils et ses méthodes sans avoir à réécrire la politique. Tant que la norme est respectée, la mise en œuvre peut évoluer. Pour plus de détails sur la manière dont les équipes gèrent concrètement ces étapes, notre guide sur le processus de gestion des correctifs les détaille une à une.

6. Gestion des exceptions et acceptation des risques

Chaque environnement comporte des systèmes qui ne peuvent pas être mis à jour selon le calendrier prévu. Des applications héritées qui cessent de fonctionner avec les nouvelles bibliothèques. Des appliances de fournisseurs soumises à un contrat de maintenance qui régit les mises à jour. Des systèmes isolés physiquement, avec leurs propres créneaux de mise à jour. La politique doit prévoir un processus d'exception bien défini, et non se contenter d'une entente tacite selon laquelle « on trouvera bien une solution ».

Une clause d'exception valable comprend :

• Un formulaire de demande d'exception dûment documenté (actif, vulnérabilité, motif, mesures de contrôle compensatoires, responsable, date d'expiration)
• Un responsable de validation désigné (généralement l'autorité chargée de la gestion des correctifs pour les exceptions limitées dans le temps, avec examen par l'équipe de sécurité)
• Une durée maximale pour l'exception (90 jours constituent une valeur par défaut raisonnable, tout renouvellement nécessitant un nouvel examen)
• Une mesure de compensation obligatoire (segmentation du réseau, surveillance supplémentaire, correctifs virtuels) pour toute exception dépassant les limites du SLA initial
• Un registre central des exceptions qui fait l'objet d'un examen trimestriel et d'un rapport annuel

Cette section est importante car, sans elle, la procédure d'exception se résume à « l'équipe abandonne et passe à autre chose ». C'est ainsi que des systèmes peuvent rester exposés à des vulnérabilités connues pendant des années, sans qu'on sache pourquoi.

7. Rapports et vérification de la conformité

Précisez ce qui doit faire l'objet d'un rapport, à qui et à quelle fréquence. Une structure de reporting justifiable :

• Tableaux de bord opérationnels. Conformité aux correctifs en temps réel par groupe d'actifs, accessible en permanence à l'équipe chargée des correctifs.
• Rapports mensuels. Pourcentage de conformité des correctifs, taux de respect des SLA, nombre d'exceptions, délai moyen de déploiement des correctifs. Vérifiés par le responsable de l'équipe de gestion des correctifs et l'autorité compétente.
• Rapports trimestriels. Analyse des tendances, suivi des menaces émergentes, examen du registre des exceptions, évaluation de l'efficacité des politiques. Présentés à la direction de la sécurité.
• Rapport annuel. État des lieux de la conformité sur l'ensemble de l'exercice, synthèse de la mise en correspondance avec les référentiels, lacunes et mesures correctives. Remis à la direction générale et aux auditeurs externes.

C'est souvent au niveau des obligations de compte rendu que les constatations d'audit sont les plus faciles à prévoir. Si la politique prévoit des examens trimestriels et que vous n'êtes pas en mesure de fournir les procès-verbaux des quatre derniers, voilà la constatation.

8. Intégration de la gestion du changement

La gestion des correctifs et la gestion des changements se recoupent. La politique doit préciser comment la gestion des correctifs s’intègre dans le processus global de gestion des changements : ce qui est considéré comme un changement standard (types de correctifs pré-approuvés déployés dans des créneaux horaires définis), ce qui est considéré comme un changement normal (déploiements ponctuels ou hors cycle) et ce qui est considéré comme un changement d’urgence (réponse à une exploitation active). Il ne s’agit pas là d’une charge administrative inutile. C'est ainsi que l'équipe chargée des correctifs évite d'être bloquée par un comité de gestion des changements qui se réunit chaque semaine alors que le compte à rebours de la menace se mesure en heures.

9. Exigences en matière d'automatisation

Les politiques modernes devraient imposer explicitement le recours à l'automatisation lorsque cela est possible. La formulation est importante : il ne s'agit pas de dire « l'automatisation est encouragée », mais « le programme de correctifs utilisera des outils automatisés pour l'identification, l'analyse, le déploiement et la génération de rapports, l'intervention manuelle étant réservée aux exceptions documentées ».

Les arguments en faveur de cette approche sont d'ordre opérationnel et liés à la sécurité. L'application manuelle des correctifs, dès lors qu'elle concerne une organisation comptant plus de quelques dizaines de terminaux, entraîne des incohérences et des retards. L'automatisation, assortie de mesures de contrôle adéquates, est plus rapide, plus cohérente et plus facile à justifier. Pour une analyse plus approfondie de ce qu'il convient d'automatiser et de ce qu'il vaut mieux laisser au manuel, consultez notre article de blog consacré à la gestion automatisée des correctifs. Sur le plan des politiques, cette exigence est suffisante.

10. Révision des politiques et gestion des versions

Définissez une fréquence de révision et respectez-la. Une révision annuelle constitue le minimum requis ; une révision trimestrielle est recommandée lorsque les menaces ou les exigences de conformité évoluent de manière significative. La politique doit préciser :

• Fréquence des révisions (généralement annuelle)
• Conditions déclenchant un examen hors cycle (modifications majeures du cadre, incidents de sécurité importants, restructuration organisationnelle)
• Exigences en matière de gestion des versions (chaque version doit être datée, les modifications doivent être résumées et les versions antérieures doivent être conservées)
• Autorité compétente pour approuver les modifications apportées à la politique (généralement la même instance qui avait approuvé la version initiale)

Une politique sans historique des versions est une politique que personne ne contrôle.

Modèle de politique de gestion des correctifs

Voici un plan qui correspond aux dix sections ci-dessus. Il ne s'agit pas d'un document définitif, mais d'une structure sur laquelle nous pourrons développer les détails.

MODÈLE DE POLITIQUE DE GESTION DES CORRECTIFS

1. Objectif

2. Champ d'application

   2.1 Actifs concernés

   2.2 Types de logiciels concernés

   2.3 Environnements concernés

   2.4 Actifs hors champ et exclusions

3. Rôles et responsabilités

   3.1 Responsabilité en matière de gestion des correctifs

   3.2 Responsable de l'équipe de gestion des correctifs

   3.3 Administrateurs système

   3.4 Propriétaires d'applications

   3.5 Équipe de sécurité

   3.6 Propriétaires d'actifs

   3.7 Utilisateurs finaux

4. Classification des correctifs et accords de niveau de service (SLA)

   4.1 Classification par niveau de gravité

   4.2 Accords de niveau de service (SLA) pour le déploiement, par niveau de gravité

   4.3 Accords de niveau de service (SLA) pour les systèmes connectés à Internet

   4.4 Critères d'intervention d'urgence

5. Inventaire des actifs

   5.1 Exigences relatives aux données d'inventaire

   5.2 Fréquence des rapprochements

   5.3 Seuils de couverture

6. Test et déploiement des correctifs

   6.1 Exigences en matière d'essais

   6.2 Structure en anneau de déploiement

   6.3 Fenêtres de maintenance

   6.4 Gestion des redémarrages

   6.5 Gestion des échecs de déploiement

7. Gestion des exceptions

   7.1 Procédure de demande de dérogation

   7.2 Autorité compétente

   7.3 Durée et renouvellement de l'exception

   7.4 Commandes de compensation

   7.5 Registre des exceptions et examen

8. Rapports et conformité

   8.1 Rapports opérationnels

   8.2 Rapports mensuels de conformité

   8.3 Bilans trimestriels

   8.4 Rapport annuel de conformité

   8.5 Mise en correspondance des cadres

9. Intégration de la gestion du changement

   9.1 Classification des changements : standard, normaux et d'urgence

   9.2 Interaction avec le comité consultatif sur le changement

10. Automatisation

   10.1 Étendue de l'automatisation requise

   10.2 Critères d'intervention manuelle

11. Gouvernance par les politiques

   11.1 Fréquence des révisions

   11.2 Conditions de déclenchement d'un examen hors cycle

   11.3 Contrôle de version

   11.4 Autorité compétente

Annexes

A. Cartographie des cadres de conformité (PCI DSS, HIPAA, ISO 27001, NIS2, SOC 2)

B. Rôles attribués à des personnes spécifiques (actuels)

C. Registre des exceptions

D. Glossaire

E. Historique des révisions

C'est dans les annexes que la politique est mise à jour sans qu'il soit nécessaire de remanier constamment le document principal. Les noms, les cadres et les exceptions changent. Les engagements structurels, eux, ne devraient pas changer.

Comment une politique s'inscrit dans le cadre plus large du programme de mise à jour

Une politique constitue le cadre de référence qui régit les activités opérationnelles. Elle impose des accords de niveau de service (SLA) sans imposer d'outil particulier. Elle exige la réalisation de tests sans dicter la structure des cycles. Elle définit la fréquence des rapports sans concevoir les tableaux de bord.

Dans un programme bien rodé, la politique est le document qui permet de garantir la répétabilité du processus de gestion des correctifs, indépendamment du renouvellement du personnel et des changements d'outils. C'est également ce document qui permet de faire en sorte que les bonnes pratiques en matière de gestion des correctifs soient réellement appliquées, et non pas simplement des objectifs à atteindre. Une équipe peut décider, au titre des bonnes pratiques, de donner la priorité aux correctifs liés à Internet, mais si la politique ne l'impose pas, cette pratique disparaîtra discrètement dès que l'équipe se retrouvera sous pression.

C'est également au niveau de la politique que l'automatisation devient une obligation plutôt qu'une simple option. Dans les organisations qui n'ont pas formellement inscrit l'automatisation dans leur politique, chaque nouvel administrateur système se retrouve à devoir débattre à nouveau de la question de savoir si l'automatisation est « sûre » ou « appropriée », et cette dérive fin par éroder le programme au fil des ans. Une politique stipulant que l'automatisation est la norme, avec des exceptions clairement documentées, met fin à ce débat.

Bonnes pratiques en matière de politique de gestion des correctifs

Une politique de gestion des correctifs est l'un des documents de gouvernance les plus influents dont dispose un service informatique ou de sécurité. Bien conçue, elle confère des pouvoirs à l'équipe chargée des correctifs, fournit des preuves aux auditeurs, apporte de la clarté à l'entreprise et assure la continuité du programme. Mal conçue, elle n'est qu'un document SharePoint dont tout le monde reconnaît l'existence, mais que personne ne respecte réellement.

Les politiques qui font leurs preuves partagent certaines caractéristiques. Elles définissent clairement leur champ d'application plutôt que de se contenter d'énoncer des aspirations. Leurs accords de niveau de service (SLA) tiennent compte des délais actuels liés aux menaces, et non des modèles datant d'il y a cinq ans. Elles désignent des rôles, et non des personnes. Elles font des exceptions un processus documenté, et non une solution de contournement discrète. Elles imposent l'automatisation plutôt que de tolérer la prolifération des tâches manuelles. Et elles font l'objet d'une révision régulière, comme en atteste le contrôle des versions.

Si vous élaborez une politique à partir de zéro, inspirez-vous de la structure en dix sections ci-dessus et rédigez chaque section en vous référant au cadre réglementaire le plus exigeant auquel vous êtes soumis. Si vous mettez à jour une politique existante, commencez par les accords de niveau de service (SLA). C'est la partie la plus susceptible d'être discrètement obsolète, et c'est celle qui détermine le plus directement si la politique reflète toujours le fonctionnement prévu du programme. À partir de là, le reste du document peut être mis à jour section par section.

Comment Kaseya peut vous aider

Une politique n'est applicable que si vos outils sont réellement capables de mettre en œuvre et de démontrer ce qu'elle exige. C'est là que la plupart des programmes de correctifs échouent : le document stipule que les correctifs critiques doivent être déployés dans un délai de 14 jours, mais l'outil ne peut pas vous indiquer lesquels n'ont pas respecté le SLA le mois dernier, et cette lacune apparaît lors de l'audit.

Les solutions RMM de Kaseya sont conçues pour gérer les mises à jour en tenant compte des exigences opérationnelles découlant d'une politique de mise à jour rigoureuse. La détection continue des actifs alimente le module d'inventaire. L'analyse et le déploiement basés sur des politiques transforment la classification et les SLA en flux de travail automatisés, plutôt qu'en tâches manuelles sur tableur. La prise en charge intégrée des applications tierces comble les lacunes de couverture que la plupart des politiques mentionnent, mais que peu d'outils parviennent à combler. La gestion des exceptions, les cycles de déploiement et la restauration sont des fonctionnalités de premier ordre, et non plus des scripts personnalisés.

Pour les équipes informatiques internes, cela se traduit par une politique qu’il est possible de définir, d’imposer et de justifier sans avoir à collecter manuellement des preuves. Pour les MSP gérant les politiques de plusieurs clients, Datto RMM étend ce modèle aux politiques de correctifs par client, aux rapports SLA par client et aux types de preuves d’attestation qui satisfont l’auditeur d’un client sans qu’il soit nécessaire de créer un rapport personnalisé pour chaque mission.

C'est une question d'application. Une politique que la solution ne peut pas mettre en œuvre n'est qu'un document. Une politique que la solution met en œuvre, surveille et sur laquelle elle établit des rapports constitue un contrôle.