Gouverner les périodes de support de sécurité du règlement européen sur la cyberrésilience avec ISO 27001

Il est 08 h 20 un mardi, et le propriétaire produit d’une passerelle B2B connectée reçoit un message d’un client réglementé : « Veuillez confirmer la période de support de sécurité pour la version 4.6 du micrologiciel, le SLA de réponse aux vulnérabilités et l’éligibilité de l’équipement aux mises à jour de sécurité pendant la durée de notre contrat de service de cinq ans. »

À 09 h 00, le service Achats a transféré un questionnaire de diligence raisonnable DORA. À 10 h 15, le service juridique demande si la période de support annoncée est cohérente avec les contrats clients. À 11 h 00, le RSSI est sollicité dans le cadre d’une revue du risque fournisseur NIS2, car le produit est utilisé par un prestataire de services managés dans l’UE. Après le déjeuner, l’équipe Protection des données demande si une bibliothèque d’API non prise en charge dans le produit pourrait compromettre la sécurité des données à caractère personnel au titre du GDPR.

Le constat s’impose rapidement : l’entreprise dispose d’une feuille de route produit, d’un processus d’application des correctifs, d’un calendrier de mise en production et d’un portail de support client, mais elle ne dispose pas d’éléments probants gouvernés relatifs à ses périodes de support de sécurité.

Cette lacune est significative. Au titre du règlement européen sur la cyberrésilience, la période de support de sécurité n’est pas une simple mention produit. C’est un engagement de cycle de vie qui affecte le traitement des vulnérabilités, la disponibilité des mises à jour, la gestion des dépendances fournisseurs, la communication client, les déclarations contractuelles et la surveillance après commercialisation. Pour les fournisseurs SaaS, les fabricants d’équipements, les éditeurs de logiciels, les fournisseurs cloud et les prestataires de services TIC, la période de support devient un objet de conformité que les auditeurs et les acheteurs réglementés testeront.

La réponse opérationnelle n’est pas un nouveau tableur de conformité déconnecté. Elle consiste à gouverner la période de support de sécurité dans un système de management de la sécurité de l’information ISO/IEC 27001:2022, puis à cartographier les mêmes éléments probants avec les attentes d’audit NIS2, DORA, GDPR, NIST CSF 2.0 et de type COBIT.

C’est le modèle opérationnel Clarysec : utiliser le SMSI comme moteur d’éléments probants, utiliser des politiques opposables pour définir les responsabilités, utiliser Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pour établir la traçabilité, et utiliser Zenith Controls: The Cross-Compliance Guide Zenith Controls comme boussole de cartographie croisée de conformité.

Pourquoi la période de support de sécurité est désormais un objet d’audit

Une période de support de sécurité répond à une question simple : pendant combien de temps le fabricant fournira-t-il des mises à jour de sécurité, la remédiation des vulnérabilités, des consignes d’atténuation et le support client associé pour un produit ou une version de produit ?

En pratique, cette réponse dépend de nombreux éléments interdépendants :

• architecture produit et maintenabilité ;
• support des composants tiers et des dépendances open source ;
• engagements des fournisseurs et des services cloud ;
• processus de réception, de qualification, de remédiation et de divulgation des vulnérabilités ;
• capacité d’ingénierie, de mise en production et de tests ;
• conditions des contrats clients et obligations réglementaires ;
• circuits de réponse aux incidents et de notification des destinataires du service ;
• conservation des éléments probants et enregistrements d’approbation.

Si un fabricant promet cinq ans de support de sécurité, mais qu’une bibliothèque cryptographique critique n’est plus prise en charge au bout de trois ans, la période de support devient une décision de risque. Si un client est une entité financière soumise à DORA, cette même période de support devient un élément de l’assurance relative aux tiers TIC. Si le produit traite des données à caractère personnel, un logiciel non pris en charge peut relever de la responsabilité liée à la sécurité du traitement prévue par le GDPR. Si le produit soutient une entité essentielle ou une entité importante au titre de NIS2, la sécurité du cycle de vie devient un enjeu de sécurité de la chaîne d’approvisionnement.

NIS2 rend cet angle de gouvernance explicite. Article 20 impose aux organes de direction des entités essentielles et importantes d’approuver les mesures de gestion des risques en cybersécurité, d’en superviser la mise en œuvre et de recevoir une formation. Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, notamment l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, la sécurité dans l’acquisition, le développement et la maintenance, le traitement et la divulgation des vulnérabilités, l’évaluation de l’efficacité, l’hygiène cyber, la cryptographie, le contrôle d’accès, la gestion des actifs et l’authentification. Article 23 ajoute des obligations de notification par étapes des incidents significatifs.

DORA crée une pression comparable pour les entités financières. Il exige la gestion des risques liés aux TIC, les tests de résilience opérationnelle numérique, la gestion des incidents et la gouvernance des risques liés aux tiers TIC. DORA Article 28 couvre les principes de gestion du risque lié aux tiers TIC, et Article 30 exige des accords contractuels écrits comprenant des descriptions de service claires, des mesures de sécurité, une assistance en cas d’incident, des droits d’audit, des droits de résiliation et des dispositions de sortie.

Le GDPR ajoute la couche Protection des données. Si le produit traite des données à caractère personnel, les responsables du traitement et les sous-traitants doivent disposer de mesures techniques et organisationnelles appropriées au titre de Article 32, d’une clarté contractuelle au titre de Article 28, ainsi que d’une capacité d’évaluation des violations et de préparation à la notification au titre des Articles 33 et 34.

C’est pourquoi la période de support de sécurité au titre du règlement européen sur la cyberrésilience doit être gouvernée comme une famille de contrôles du SMSI, et non comme un champ isolé de gestion produit.

ISO 27001 comme ossature de contrôle des périodes de support de sécurité au titre du règlement européen sur la cyberrésilience

ISO/IEC 27001:2022 est utile parce qu’elle est évolutive, fondée sur les risques et orientée système de management. Elle exige que l’organisation définisse son contexte, ses parties intéressées, son domaine d’application et ses processus en interaction, puis traduise les exigences légales, réglementaires et contractuelles en appréciation des risques, traitement des risques, contrôles opérationnels et éléments probants ISO/IEC 27001:2022.

Pour la gouvernance des périodes de support de sécurité, cela signifie que l’organisation doit :

1. Identifier les produits, versions, modules, services cloud et dépendances relevant du périmètre.
2. Identifier les parties intéressées, notamment les clients, autorités de régulation, distributeurs, importateurs, intégrateurs, sous-traitants, sous-traitants ultérieurs, partenaires de réponse aux incidents et fournisseurs.
3. Enregistrer les obligations de support légales, réglementaires et contractuelles.
4. Apprécier les risques susceptibles d’empêcher le respect des engagements de support.
5. Sélectionner les contrôles relatifs à la gestion des vulnérabilités, au développement sécurisé, à l’assurance des fournisseurs, à la gestion des incidents, à la continuité d’activité, à la protection des données et aux informations documentées.
6. Créer des notes de Déclaration d’applicabilité expliquant pourquoi les contrôles s’appliquent.
7. Revoir la période de support lorsque l’architecture, les dépendances fournisseurs, l’exposition aux menaces ou les engagements clients changent.

Zenith Controls identifie trois contrôles ISO/IEC 27002:2022 liés au sujet comme points d’ancrage centraux de cette problématique de gouvernance : 5.31 Exigences légales, statutaires, réglementaires et contractuelles, 8.8 Gestion des vulnérabilités techniques et 8.25 Cycle de vie de développement sécurisé. Ce ne sont pas les seuls contrôles concernés, mais ils constituent la colonne vertébrale de la gouvernance.

Le point clé est la traçabilité. Une période de support produit doit être traçable depuis l’obligation jusqu’au scénario de risque, du scénario de risque aux contrôles sélectionnés, des contrôles aux exigences de politique, et des exigences de politique aux éléments probants.

Zenith Blueprint, phase Gestion des risques, étape 13, décrit directement cette discipline de traçabilité :

« Référencer les réglementations de manière croisée : si certains contrôles sont mis en œuvre spécifiquement pour se conformer au GDPR, à NIS2 ou à DORA, vous pouvez l’indiquer soit dans le registre des risques, dans la justification de l’impact du risque, soit dans les notes de la SoA. »

Source : Zenith Blueprint: An Auditor’s 30-Step Roadmap, phase Gestion des risques, étape 13 : planification du traitement des risques et Déclaration d’applicabilité Zenith Blueprint

Pour une période de support de sécurité au titre du règlement européen sur la cyberrésilience, la Déclaration d’applicabilité ne doit pas simplement indiquer « la gestion des vulnérabilités s’applique ». Elle doit expliquer que la gestion des vulnérabilités s’applique parce que l’entreprise a des engagements de cycle de vie au titre du règlement européen sur la cyberrésilience, des attentes NIS2 en matière de développement sécurisé et de chaîne d’approvisionnement, des exigences de diligence raisonnable de clients soumis à DORA, des obligations de sécurité GDPR lorsque des données à caractère personnel sont traitées, ainsi que des engagements contractuels de support.

De la promesse de support au cycle de vie gouverné

Une période de support de sécurité définie par le fabricant doit satisfaire six tests de gouvernance.

Premièrement, elle doit être définie. L’organisation a besoin d’une taxonomie standard, par exemple support actif, support limité à la sécurité, support étendu, support limité et non pris en charge. Chaque statut doit préciser la disponibilité des mises à jour, le traitement des vulnérabilités, la communication client et les circuits d’escalade.

Deuxièmement, elle doit faire l’objet d’une appréciation des risques. Cinq ans de support pour un produit SaaS administré dans le cloud avec des canaux de mise à jour contrôlés ne se comparent pas à cinq ans pour un équipement embarqué soumis à des contraintes de terrain, à des dépendances envers des puces tierces et à des fenêtres de déploiement gérées par le client.

Troisièmement, elle doit être approuvée. Les fonctions Produit, Sécurité, Juridique, Protection des données, Support client et la direction responsable doivent approuver la période de référence et les exceptions.

Quatrièmement, elle doit être communiquée. Les clients doivent comprendre la date de début du support, la date de fin, la méthode de mise à jour, le canal de signalement des vulnérabilités, les attentes de remédiation, les conséquences de la fin du support et les options d’extension disponibles.

Cinquièmement, elle doit être surveillée. Les dépendances évoluent. Les fournisseurs arrêtent des bibliothèques. Des vulnérabilités apparaissent. Les environnements clients changent. La gouvernance des périodes de support doit inclure la surveillance du cycle de vie des composants, la revue des fournisseurs, les flux de vulnérabilités, les journaux d’application des correctifs, les tests de mise en production et les enseignements tirés des incidents.

Sixièmement, elle doit être documentée par des éléments probants. Si un auditeur, une autorité de régulation ou un client réglementé demande une preuve, l’organisation doit présenter le registre de conformité, le registre de support produit, l’appréciation des risques, la cartographie SoA, le registre des vulnérabilités, les enregistrements de correctifs, les revues fournisseurs, les approbations de mise en production et les notifications aux clients.

Les politiques Clarysec rendent cela opérationnel. La Politique de conformité juridique et réglementaire version Entreprise Politique de conformité juridique et réglementaire exige :

« Toutes les obligations légales et réglementaires doivent être cartographiées avec des politiques, des contrôles et des responsables spécifiques au sein du système de management de la sécurité de l’information (SMSI). »

Source : Politique de conformité juridique et réglementaire, exigences de mise en œuvre de la politique, clause 6.2.1 Politique de conformité juridique et réglementaire

Pour les PME, la discipline équivalente commence par un registre plus simple. La Politique de conformité juridique et réglementaire - PME Politique de conformité juridique et réglementaire - PME indique :

« Le directeur général doit tenir à jour un registre de conformité simple et structuré listant : »

Source : Politique de conformité juridique et réglementaire - PME, exigences de gouvernance, clause 5.1.1 Politique de conformité juridique et réglementaire - PME

Un engagement relatif à une période de support doit figurer dans le registre de conformité s’il découle de la loi, d’un contrat client, d’une réglementation sectorielle ou des attentes d’un acheteur réglementé. Il ne doit pas exister uniquement dans des notes de version ou dans un texte marketing.

Construire un registre des périodes de support de sécurité en un atelier

Imaginons un fournisseur SaaS qui vend une appliance d’analyse connectée à des prestataires logistiques de l’UE et à des clients du secteur financier. Le produit comprend un agent embarqué, une API cloud, une application d’administration mobile et plusieurs bibliothèques open source. Les équipes commerciales veulent promettre cinq ans de support de sécurité pour chaque version majeure de l’appliance.

Le RSSI peut organiser un atelier ciblé avec les équipes Produit, Ingénierie, Juridique, Protection des données et Gestion des fournisseurs.

Étape 1 : créer le registre des périodes de support

Créez une ligne par version de produit et incluez :

• produit et version ;
• date de mise en production ;
• date de début du support ;
• date de fin standard du support de sécurité ;
• option de support étendu ;
• méthode de fourniture des mises à jour ;
• canal de divulgation des vulnérabilités ;
• objectif applicable aux correctifs critiques ;
• rôle dans le traitement des données, par exemple responsable du traitement, sous-traitant ou les deux ;
• fournisseurs et composants critiques ;
• secteurs clients concernés ;
• propriétaire du risque ;
• date d’approbation ;
• emplacement des éléments probants.

Ce registre devient une information documentée au titre du SMSI. Zenith Blueprint, phase Fondations et leadership du SMSI, étape 6, donne l’attente en matière de maîtrise documentaire :

« Les documents doivent comporter une identification appropriée, telle qu’un titre, éventuellement un numéro de document ou un identifiant unique, un auteur, un format approprié, ainsi qu’une revue et une approbation de leur adéquation avant utilisation. »

Source : Zenith Blueprint: An Auditor’s 30-Step Roadmap, phase Fondations et leadership du SMSI, étape 6 : informations documentées et constitution de la bibliothèque du SMSI Zenith Blueprint

La Politique PIMS de gestion des informations documentées et des éléments probants version Entreprise de Clarysec Politique PIMS de gestion des informations documentées et des éléments probants applique des principes similaires aux éléments probants de la documentation relative à la protection des données :

« Le responsable Protection des données / responsable du PIMS DOIT attribuer un identifiant de document, un propriétaire, un numéro de version, un statut d’approbation, une date d’entrée en vigueur et une date de revue dans REG12 avant de publier des informations documentées du PIMS. »

Source : Politique PIMS de gestion des informations documentées et des éléments probants, création, approbation, gestion des versions et publication, clause 4.2.1 Politique PIMS de gestion des informations documentées et des éléments probants

Même si le registre des périodes de support n’est pas un document de protection des données par défaut, la même discipline s’applique : propriétaire, version, approbation, date d’entrée en vigueur et date de revue.

Étape 2 : relier les promesses de support au traitement des risques

Pour chaque version de produit, créez des scénarios de risque, par exemple :

• une vulnérabilité critique est découverte dans une version prise en charge, mais la capacité d’ingénierie n’est pas disponible ;
• un composant tiers n’est plus pris en charge avant la fin de la période de support de sécurité déclarée ;
• un fournisseur modifie la localisation d’hébergement ou le sous-traitant et affecte la fourniture des mises à jour ;
• une vulnérabilité affecte des données à caractère personnel et déclenche une évaluation d’une violation de données à caractère personnel ;
• un client financier réglementé exige des éléments probants de résilience liés aux tiers TIC.

Les clauses 6.1.1 à 6.1.3 d’ISO/IEC 27001:2022 fournissent le moteur de planification : identifier les risques, apprécier la vraisemblance et les conséquences, désigner les propriétaires des risques, sélectionner les traitements, comparer les contrôles sélectionnés à l’Annexe A, produire la Déclaration d’applicabilité et obtenir l’approbation du risque résiduel.

Pour le risque « composant non pris en charge avant la date de fin du support », l’enregistrement de risque doit inclure les contrôles ISO/IEC 27002:2022 5.31, 8.8 et 8.25, ainsi que des contrôles fournisseurs tels que 5.19 Sécurité de l’information dans les relations avec les fournisseurs, 5.20 Prise en compte de la sécurité de l’information dans les accords fournisseurs, 5.21 Gestion de la sécurité de l’information dans la chaîne d’approvisionnement TIC, et 5.22 Surveillance, revue et gestion des changements des services fournisseurs.

Étape 3 : définir les règles relatives aux éléments probants de vulnérabilités et de correctifs

Une période de support n’est crédible que si la gestion des vulnérabilités fonctionne pendant toute cette période.

La Politique de gestion des vulnérabilités et des correctifs - PME Politique de gestion des vulnérabilités et des correctifs - PME fixe une exigence stricte pour les expositions urgentes :

« Les correctifs critiques doivent être appliqués dans les 3 jours suivant leur publication, en particulier pour les systèmes exposés à Internet. »

Source : Politique de gestion des vulnérabilités et des correctifs - PME, exigences de mise en œuvre de la politique, clause 6.1.1 Politique de gestion des vulnérabilités et des correctifs - PME

Elle exige également des enregistrements exploitables en audit :

« Un journal des correctifs doit être tenu à jour et revu lors des audits et des activités de réponse aux incidents. »

Source : Politique de gestion des vulnérabilités et des correctifs - PME, exigences de gouvernance, clause 5.4.1 Politique de gestion des vulnérabilités et des correctifs - PME

Pour les environnements d’entreprise, la Politique de gestion des vulnérabilités et des correctifs version Entreprise Politique de gestion des vulnérabilités et des correctifs exige :

« Un registre centralisé de gestion des vulnérabilités doit être tenu par l’équipe des opérations de sécurité et revu mensuellement par le RSSI ou une autorité déléguée. »

Source : Politique de gestion des vulnérabilités et des correctifs, exigences de gouvernance, clause 5.1 Politique de gestion des vulnérabilités et des correctifs

Zenith Blueprint, phase Contrôles en action, étape 19, explique l’attente opérationnelle qui sous-tend le contrôle ISO/IEC 27002:2022 8.8 :

« Tenez-vous informé des nouveaux bogues de sécurité, via les alertes des fournisseurs, les flux CVE, etc., concernant vos logiciels et matériels. Évaluez ceux qui sont pertinents, par exemple : utilisons-nous ce logiciel ? quelle est la criticité du bogue ? Appliquez rapidement les correctifs ou les mesures d’atténuation. »

Source : Zenith Blueprint: An Auditor’s 30-Step Roadmap, phase Contrôles en action, étape 19 : contrôles technologiques I Zenith Blueprint

Chaque version de produit prise en charge nécessite une chaîne d’éléments probants relative aux vulnérabilités : réception, analyse de pertinence, gravité, versions affectées, plan de remédiation, publication du correctif, consignes d’atténuation, communication client et approbation de clôture.

Étape 4 : relier le développement sécurisé à la durée de support

Le support de sécurité commence avant la mise en production. Il dépend de pratiques de développement qui rendent le produit maintenable.

La Politique de développement sécurisé - PME Politique de développement sécurisé - PME indique :

« Les composants doivent être mis à jour régulièrement lorsque des correctifs de sécurité sont publiés. Si une vulnérabilité critique est identifiée, le composant doit être mis à niveau ou remplacé immédiatement. »

Source : Politique de développement sécurisé - PME, exigences de mise en œuvre de la politique, clause 6.6.3 Politique de développement sécurisé - PME

La Politique relative aux exigences de sécurité des applications - PME Politique relative aux exigences de sécurité des applications - PME exige que les contrats et exigences :

« précisent les obligations de divulgation des vulnérabilités, les délais de réponse et l’application des correctifs. »

Source : Politique relative aux exigences de sécurité des applications - PME, exigences de gouvernance, clause 5.3.2 Politique relative aux exigences de sécurité des applications - PME

Si l’entreprise promet un support jusqu’en 2031, l’architecture doit permettre des mises à jour maintenables, le remplacement des dépendances, des chaînes de build sécurisées, des tests de non-régression et des mises en production d’urgence. Les contrôles ISO/IEC 27002:2022 relatifs au développement sécurisé, à l’architecture sécurisée, à la programmation sécurisée, aux tests de sécurité, au développement externalisé, à la séparation des environnements et à la gestion des changements deviennent des facteurs de réussite des périodes de support.

Un seul jeu d’éléments probants pour le règlement européen sur la cyberrésilience, NIS2, DORA et GDPR

Les mêmes éléments probants relatifs à la période de support peuvent satisfaire différentes discussions réglementaires, mais chaque référentiel pose la question différemment.

Les dépendances fournisseurs sont souvent le point de rupture des engagements de support. La Politique de gestion des risques de dépendance vis-à-vis des fournisseurs version Entreprise Politique de gestion des risques de dépendance vis-à-vis des fournisseurs exige :

« Registre des dépendances fournisseurs : le VMO doit tenir à jour un registre de tous les fournisseurs critiques, comprenant des informations telles que les services/produits fournis ; l’éventuel caractère de fournisseur unique ; les fournisseurs de remplacement disponibles ou la substituabilité ; les conditions contractuelles en vigueur ; et une évaluation de l’impact si le fournisseur devait défaillir ou être compromis. »

Source : Politique de gestion des risques de dépendance vis-à-vis des fournisseurs, exigences de mise en œuvre, clause 6.1 Politique de gestion des risques de dépendance vis-à-vis des fournisseurs

Zenith Blueprint, phase Contrôles en action, étape 23, avertit que les auditeurs examineront les accords fournisseurs et les éléments probants de surveillance des fournisseurs :

« Les auditeurs examineront des échantillons de contrats ou d’accords de service. Ils recherchent des clauses explicites de sécurité de l’information, telles que des délais de notification des violations, des restrictions d’accès, des obligations de traitement des données, des exigences de chiffrement ou des droits d’audit. »

Source : Zenith Blueprint: An Auditor’s 30-Step Roadmap, phase Contrôles en action, étape 23 : contrôles organisationnels Zenith Blueprint

Pour les clients soumis à DORA, ce point est critique. Les contrats relatifs aux services TIC soutenant des fonctions critiques ou importantes doivent comporter des descriptions de service claires, des conditions de sous-traitance, des mesures de sécurité, une assistance en cas d’incident, des droits d’audit et d’inspection, des droits de résiliation et des modalités de transition. Un fournisseur qui ne peut pas soutenir ces engagements peut empêcher le fabricant de formuler une promesse crédible de période de support.

Table de correspondance des contrôles pour une gouvernance de la période de support exploitable en audit

Cette table de correspondance permet aux équipes Sécurité, Juridique, Produit et Commerciales de parler le même langage. Le registre des périodes de support n’est pas seulement un élément probant relatif au règlement européen sur la cyberrésilience. C’est une assurance fournisseurs pour NIS2, une assurance relative aux tiers pour DORA, un support de sécurité du traitement pour le GDPR et un livrable de gouvernance pour la certification ISO 27001.

L’angle Protection des données : quand le non-support devient un risque

La gouvernance des périodes de support de sécurité n’est pas seulement un sujet de cybersécurité. Si le produit stocke, transmet ou traite des données à caractère personnel, un logiciel non pris en charge peut devenir un risque relatif à la vie privée.

Le GDPR s’applique au traitement effectué dans le cadre des activités d’un établissement dans l’UE et peut également s’appliquer à des organisations non établies dans l’UE qui proposent des biens ou services à des personnes situées dans l’UE ou qui surveillent leur comportement. Il définit largement les données à caractère personnel et qualifie de violation de données à caractère personnel une violation de sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l’altération, la divulgation non autorisée de données à caractère personnel traitées ou l’accès non autorisé à celles-ci.

Pour la gouvernance des périodes de support, les équipes Protection des données doivent savoir quelles versions de produit traitent des données à caractère personnel, quels systèmes sont encore pris en charge et si les vulnérabilités affectent la confidentialité, l’intégrité ou la disponibilité des données à caractère personnel.

La Politique de sécurité et de contrôle d’accès aux données à caractère personnel version Entreprise de Clarysec Politique de sécurité et de contrôle d’accès aux données à caractère personnel exige :

« Le propriétaire du système / propriétaire d’application DOIT enregistrer la couverture des évaluations de vulnérabilités pour les systèmes traitant des PII dans REG12 au moins chaque trimestre et après toute modification technique substantielle. »

Source : Politique de sécurité et de contrôle d’accès aux données à caractère personnel, configuration sécurisée et gestion des vulnérabilités, clause 4.7.4 Politique de sécurité et de contrôle d’accès aux données à caractère personnel

La Politique de gestion de la confidentialité relative aux sous-traitants, sous-traitants ultérieurs et tiers version Entreprise Politique de gestion de la confidentialité relative aux sous-traitants, sous-traitants ultérieurs et tiers ajoute une surveillance continue pour les relations à haut risque en matière de protection des données :

« Le responsable Fournisseurs / Achats DOIT surveiller trimestriellement les relations actives à haut risque avec les sous-traitants et sous-traitants ultérieurs, et annuellement les autres relations actives avec des sous-traitants et sous-traitants ultérieurs traitant des PII, au regard des conditions de diligence raisonnable, du statut contractuel, du statut d’assurance, des points ouverts et des dates de revue dans REG08. »

Source : Politique de gestion de la confidentialité relative aux sous-traitants, sous-traitants ultérieurs et tiers, surveillance continue, assistance, interface de divulgation et sortie, clause 4.5.1 Politique de gestion de la confidentialité relative aux sous-traitants, sous-traitants ultérieurs et tiers

Lorsqu’une vulnérabilité devient un incident, la Politique de gestion des incidents et violations de données à caractère personnel version Entreprise Politique de gestion des incidents et violations de données à caractère personnel exige une évaluation des déclencheurs multi-référentiels :

« Le responsable Protection des données / responsable du PIMS DOIT évaluer les déclencheurs de notification applicables, qu’ils soient légaux, sectoriels, financiers, cybersécurité, contractuels, clients ou destinataires de services, pour chaque incident à fort impact relatif aux données à caractère personnel, et enregistrer le résultat d’applicabilité dans REG01, REG08 et REG10. »

Source : Politique de gestion des incidents et violations de données à caractère personnel, classification et évaluation d’une violation de données à caractère personnel, clause 4.2.6 Politique de gestion des incidents et violations de données à caractère personnel

C’est le chevauchement opérationnel entre les engagements de support au titre du règlement européen sur la cyberrésilience, la communication d’incident NIS2, la gestion des incidents majeurs liés aux TIC au titre de DORA et la responsabilité en cas de violation au titre du GDPR.

Comment les auditeurs testent le même processus de période de support

Un processus solide de gouvernance des périodes de support doit résister à plusieurs styles d’audit. Les éléments probants changent peu, mais l’angle de l’auditeur varie.

NIST CSF 2.0 est utile comme couche de communication, car sa fonction GOVERN inclut les obligations légales, réglementaires, contractuelles et de protection des données, les objectifs de gestion des risques, l’appétence au risque, les rôles, les politiques et la supervision. Ses résultats relatifs à la chaîne d’approvisionnement couvrent la stratégie fournisseurs, la criticité, les contrats, les diligences raisonnables, la surveillance, la coordination des incidents et les dispositions de fin de relation.

Les auditeurs COBIT et de type ISACA se concentrent souvent sur la conception de la gouvernance : qui possède la décision, quel processus est défini, quels indicateurs montrent la performance, comment les exceptions sont approuvées et comment l’amélioration continue est traitée.

La Politique de sécurité de l’information version Entreprise de Clarysec Politique de sécurité de l’information énonce le principe d’auditabilité :

« Tous les contrôles mis en œuvre doivent être auditables, soutenus par des procédures documentées et par des éléments probants conservés quant à leur fonctionnement. »

Source : Politique de sécurité de l’information, exigences de mise en œuvre de la politique, clause 6.6.1 Politique de sécurité de l’information

C’est la phrase que chaque période de support de sécurité doit pouvoir satisfaire.

Étendre, raccourcir ou arrêter le support sans créer de fausse assurance

Les moments de gouvernance les plus difficiles ne surviennent pas au lancement du produit. Ils surviennent lorsque la réalité change.

Vous pouvez devoir étendre le support parce que des clients réglementés dépendent du produit, qu’une migration n’est pas faisable ou qu’un client sectoriel a des besoins contractuels de continuité. Vous pouvez devoir raccourcir ou restreindre le support parce qu’un fournisseur retire la maintenance de sécurité, qu’un composant devient impossible à corriger, qu’une plateforme atteint ses limites techniques ou que l’architecture du produit ne peut pas prendre en charge en sécurité une classe de vulnérabilités.

Un changement maîtrisé de période de support doit inclure :

• le déclencheur du changement, par exemple fin de vie fournisseur, vulnérabilité critique, contrat client ou changement réglementaire ;
• les produits, versions, clients et secteurs affectés ;
• l’analyse d’impact sur les données à caractère personnel et les services critiques ;
• la revue de faisabilité fournisseur et composant ;
• l’appréciation des risques et la décision relative au risque résiduel ;
• le registre des périodes de support mis à jour ;
• la notification client et la position contractuelle mises à jour ;
• les notes SoA mises à jour lorsque les contrôles ou obligations changent ;
• l’approbation de la direction et la date de revue.

La Politique de divulgation coordonnée des vulnérabilités version Entreprise Politique de divulgation coordonnée des vulnérabilités est utile lorsque le changement est motivé par une vulnérabilité :

« Un plan de remédiation ou d’atténuation doit être élaboré pour toutes les vulnérabilités confirmées. La mise en œuvre du correctif doit être priorisée selon la gravité. Par exemple, les vulnérabilités critiques doivent être corrigées ou atténuées dans un délai de 14 jours lorsque cela est faisable, ou plus tôt lorsqu’une exploitation active est détectée, tandis que les problèmes de gravité inférieure doivent être traités dans un délai raisonnable. »

Source : Politique de divulgation coordonnée des vulnérabilités, exigences de mise en œuvre, clause 6.6 Politique de divulgation coordonnée des vulnérabilités

Si un correctif complet ne peut pas être fourni immédiatement, des contrôles compensatoires, la désactivation de fonctionnalités, une surveillance renforcée ou des consignes de configuration client peuvent être acceptables temporairement, mais la décision doit être documentée et communiquée.

Liste de contrôle pratique Clarysec pour la préparation des périodes de support

Utilisez cette liste de contrôle avant de publier ou de renouveler tout engagement de période de support de sécurité au titre du règlement européen sur la cyberrésilience.

• Le produit et la version sont-ils inscrits dans le registre des périodes de support ?
• La date de fin du support est-elle approuvée par le produit, la sécurité et la direction responsable ?
• Les facteurs légaux, réglementaires et contractuels sont-ils cartographiés dans le registre de conformité ?
• Le scénario de risque lié à la période de support est-il inclus dans le registre des risques ?
• Les contrôles sont-ils cartographiés dans la Déclaration d’applicabilité, notamment 5.31, 8.8 et 8.25 lorsqu’ils sont applicables ?
• Les fournisseurs et composants critiques sont-ils cartographiés dans le registre des dépendances fournisseurs ?
• Existe-t-il des éléments probants montrant que les composants peuvent être corrigés ou remplacés pendant la période de support ?
• Les responsabilités de réception, de qualification, de remédiation et de divulgation des vulnérabilités sont-elles définies ?
• Les SLA relatifs aux correctifs critiques sont-ils alignés sur la politique et les contrats clients ?
• Les journaux des correctifs, les enregistrements de mise en production et les décisions relatives aux vulnérabilités sont-ils conservés ?
• Les systèmes traitant des données à caractère personnel sont-ils couverts par des éléments probants d’évaluation des vulnérabilités lorsque des PII sont traitées ?
• Les notifications aux clients, les déclarations de support et les conditions contractuelles sont-elles cohérentes ?
• Existe-t-il un processus permettant d’étendre, de raccourcir ou d’arrêter le support avec approbation du risque ?
• Les revues de direction reçoivent-elles les informations relatives aux risques des périodes de support, aux fournisseurs, aux vulnérabilités et aux incidents ?
• Les éléments probants peuvent-ils être produits sous 48 heures pour un audit client ou une demande d’autorité de régulation ?

La Politique PIMS de surveillance, d’audit et d’amélioration version Entreprise Politique PIMS de surveillance, d’audit et d’amélioration renforce la discipline de revue de direction pour les programmes de protection des données :

« La direction générale DOIT revoir les entrées relatives aux non-conformités du PIMS, aux actions correctives, aux résultats de surveillance, aux résultats d’audit, aux risques relatifs à la vie privée, à l’assurance des fournisseurs et aux changements concernant les parties intéressées dans REG12 lors de chaque revue de direction. »

Source : Politique PIMS de surveillance, d’audit et d’amélioration, revue de direction du PIMS, clause 4.3.5 Politique PIMS de surveillance, d’audit et d’amélioration

Pour la gouvernance des périodes de support de sécurité, le même rythme de revue doit s’appliquer à l’ensemble du SMSI : vulnérabilités, performance d’application des correctifs, assurance des fournisseurs, engagements clients, incidents, exceptions de support et actions correctives doivent alimenter la revue de direction.

Rendre la période de support de sécurité défendable

Le règlement européen sur la cyberrésilience modifie la logique de la sécurité produit. Il pousse les fabricants et fournisseurs de logiciels à penser au-delà du jour de mise en production. La période de support de sécurité devient une promesse de cycle de vie qui doit être conçue, gouvernée, surveillée et documentée par des éléments probants.

Pour les RSSI, la leçon est claire : ne laissez pas la période de support uniquement dans le marketing produit. Pour les responsables conformité, ne construisez pas un silo d’éléments probants séparé pour le règlement européen sur la cyberrésilience. Pour les auditeurs, testez si les engagements de support sont traçables aux risques, aux contrôles, aux fournisseurs, aux incidents et aux approbations documentées. Pour les responsables métier, rappelez-vous qu’une période de support crédible peut devenir un avantage commercial, en particulier lors de ventes à des secteurs réglementés NIS2, à des entités financières DORA et à des clients sensibles à la protection des données.

Clarysec aide les organisations à opérationnaliser cette approche grâce à :

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pour construire la traçabilité du SMSI, les informations documentées, la cartographie SoA et la préparation à l’audit ;
• Zenith Controls: The Cross-Compliance Guide Zenith Controls pour cartographier les contrôles ISO/IEC 27002:2022 avec NIS2, DORA, GDPR, NIST CSF 2.0 et les attentes d’audit ;
• des packs de politiques Entreprise et PME pour la gestion des vulnérabilités, le développement sécurisé, la conformité juridique, les dépendances fournisseurs, les éléments probants de protection des données et la réponse aux incidents ;
• des registres et workflows d’éléments probants pratiques qui transforment les promesses de période de support en gouvernance auditable.

Votre prochaine étape est simple : choisissez une version de produit phare et constituez son dossier d’éléments probants relatif à la période de support de sécurité. Cartographiez l’obligation, approuvez la période de support, testez le processus de gestion des vulnérabilités, validez les dépendances fournisseurs, confirmez la communication client et conservez les enregistrements.

Si vous pouvez défendre un produit, vous pouvez déployer le modèle à l’échelle. Si vous ne pouvez pas défendre un produit, la lacune n’est pas documentaire. Elle est liée à la gouvernance.

Téléchargez Zenith Blueprint, utilisez Zenith Controls pour cartographier vos éléments probants, ou demandez une évaluation de préparation Clarysec afin de transformer les périodes de support de sécurité au titre du règlement européen sur la cyberrésilience en gouvernance ISO 27001 exploitable en audit.