[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:fr:les-neuf-endroits-ou-le-cadre-de-risque-tic-de-votre-client-bancaire-entre-dans-votre-produit-rts-2024-1774-fin-de-support-vulnerabilites-code-source-comptes-et-incidents":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"fr","les-neuf-endroits-ou-le-cadre-de-risque-tic-de-votre-client-bancaire-entre-dans-votre-produit-rts-2024-1774-fin-de-support-vulnerabilites-code-source-comptes-et-incidents","Les neuf endroits où le cadre de risque TIC de votre client bancaire entre dans votre produit, RTS 2024\u002F1774 : dates de fin de support, rapports de vulnérabilités et suivi des bibliothèques, réglages qu'il ne doit pas pouvoir contourner, code source testé avant la production, comptes nominatifs pour votre personnel, et vos incidents comme ses alarmes","Le règlement délégué (UE) 2024\u002F1774, en vigueur depuis le 15 juillet 2024, précise le cadre de gestion du risque lié aux TIC que chaque entité financière applique sous DORA, et neuf de ses articles nomment le prestataire tiers de services TIC. Lu du côté du prestataire : le registre des actifs qui enregistre les dates de fin de votre support (article 4), la procédure de vulnérabilités qui vérifie que vous traitez et signalez les vulnérabilités et suit les bibliothèques tierces de votre produit (article 10), la procédure de sécurité des données et des systèmes qui répartit les rôles entre vous et le client et demande des mesures sur votre infrastructure (article 11), les connexions chiffrées sur les réseaux tiers (article 13), le code source des prestataires analysé et testé avant la production (article 16), un compte unique pour chaque membre de votre personnel ayant un accès (article 20), vos notifications d'incident comme l'une de ses sources de détection (article 23), des tests de continuité qui incluent votre service et votre insolvabilité (articles 25 et 26). Avec ce qu'un système ISO 27001 répond déjà.","2026-09-12","\nL'article 28, paragraphe 1, du règlement (UE) 2022\u002F2554, DORA, fait du cadre de gestion du risque lié aux TIC du client la chose dont votre service est une composante, et le règlement délégué (UE) 2024\u002F1774 de la Commission du 13 mars 2024, publié le 25 juin 2024 et en vigueur depuis le 15 juillet 2024, précise ce cadre en quarante-deux articles : les politiques, procédures, protocoles et outils de l'article 9, paragraphe 2, de DORA, les mécanismes de détection de l'article 10, les plans de continuité et de rétablissement de l'article 11, et un cadre simplifié pour les petites entités de l'article 16. L'essentiel est l'intendance propre du client. Neuf articles nomment le prestataire tiers de services TIC, et chacun est une question à laquelle le cadre du client doit pouvoir répondre à votre sujet, donc une question qui vous sera posée. Cet article lit ces neuf articles au Journal officiel sur CELLAR le 12 septembre 2026, du côté du prestataire. Ce n'est pas un avis juridique.\n\n## Le registre des actifs veut vos dates de fin de support, article 4\n\nL'article 4 exige une politique de gestion des actifs TIC selon laquelle l'entité tient des enregistrements pour chaque actif TIC : un identifiant unique, sa localisation physique ou logique, sa classification, son propriétaire, les fonctions métier qu'il soutient, ses exigences de continuité y compris les objectifs de délai et de point de rétablissement, s'il est exposé à des réseaux externes, ses liens et interdépendances avec d'autres actifs et, point b) ix) du paragraphe 2, le cas échéant, les dates de fin des services de support réguliers, étendus et personnalisés du prestataire tiers de services TIC, après lesquelles l'actif n'est plus supporté. Pour un prestataire, cela signifie un cycle de vie de support publié par version de produit, avec des dates, parce que le registre du client a une colonne pour cela et qu'une colonne vide est un constat au prochain audit du client.\n\n## La procédure de vulnérabilités vous vérifie, et suit vos bibliothèques, article 10\n\nL'article 10 exige des procédures de gestion des vulnérabilités qui, entre autres, vérifient si les prestataires tiers de services TIC traitent les vulnérabilités liées aux services qu'ils fournissent et s'ils signalent à l'entité au moins les vulnérabilités critiques ainsi que des statistiques et tendances en temps utile ; et qui suivent l'utilisation des bibliothèques tierces, y compris open source, utilisées par les services soutenant des fonctions critiques ou importantes, et des services développés ou personnalisés pour l'entité par un prestataire. Le règlement ajoute que l'entité demande aux prestataires d'enquêter sur les vulnérabilités pertinentes, d'en déterminer les causes profondes et de mettre en œuvre des mesures d'atténuation, et qu'elle surveille les versions et mises à jour des bibliothèques tierces, le cas échéant en collaboration avec le prestataire. L'entité elle-même exécute des analyses automatisées de vulnérabilités au moins chaque semaine sur les actifs soutenant des fonctions critiques ou importantes, et sa gestion des correctifs fixe des délais avec escalade.\n\nLu du côté du prestataire, ce sont trois livrables : un processus de traitement des vulnérabilités dont le client peut vérifier l'existence, un rapport périodique de vulnérabilités qui nomme au moins les critiques avec statistiques et tendances, et une liste des composants tiers et open source du produit avec leurs versions, c'est-à-dire la nomenclature logicielle que le [Cyber Resilience Act](\u002Fcyber-resilience-act) exige d'un fabricant pour ses propres raisons. Un prestataire qui la produit déjà pour le CRA répond à l'article 10, paragraphe 2, point d), avec le même document.\n\n## Sécurité des données et des systèmes : rôles entre vous et le client, mesures sur votre infrastructure, article 11\n\nL'article 11 exige une procédure de sécurité des données et des systèmes dont les éléments comprennent, pour les actifs ou services TIC exploités par un prestataire tiers de services TIC, point k), l'identification et la mise en œuvre d'exigences pour maintenir la résilience opérationnelle numérique conformément à la classification des données et à l'évaluation du risque lié aux TIC. Pour ce point, l'entité considère la mise en œuvre des réglages recommandés par le fournisseur sur les éléments qu'elle exploite elle-même, une répartition claire des rôles et responsabilités de sécurité de l'information entre l'entité et le prestataire, conformément à la pleine responsabilité de l'entité au titre de l'article 28, paragraphe 1, point a), de DORA, les compétences dont elle a besoin pour gérer et sécuriser le service, et des mesures techniques et organisationnelles pour minimiser les risques liés à l'infrastructure que le prestataire utilise pour ses services, en considérant les meilleures pratiques et les normes. Le point f) ii) du même article, sur les terminaux, exige des mécanismes de sécurité qui ne peuvent être modifiés, retirés ou contournés par le personnel ou par des prestataires tiers de services TIC de manière non autorisée.\n\nPour un éditeur SaaS, la répartition des rôles est le document de responsabilité partagée : quels réglages de sécurité le client configure, lesquels le prestataire exploite, et lesquels le client ne peut pas désactiver. Les mesures sur votre infrastructure sont les mesures que le périmètre de votre certificat décrit, et le cadre du client les demandera par référence à une norme.\n\n## Connexions chiffrées sur les réseaux tiers, article 13\n\nL'article 13 exige des mesures de sécurité des réseaux qui comprennent le chiffrement des connexions réseau passant sur les réseaux d'entreprise, publics, domestiques, tiers et sans fil, pour les protocoles de communication utilisés, compte tenu de la classification des données, et, pour les services réseau de l'entité, la documentation indiquant s'ils sont fournis par un prestataire intragroupe ou par des prestataires tiers. La réponse du prestataire est le chiffrement en transit de chaque connexion entre le client et le produit et entre le produit et ses sous-traitants, avec les versions de protocole écrites.\n\n## Le code source des prestataires est analysé et testé avant la production, article 16\n\nL'article 16 exige une politique d'acquisition, de développement et de maintenance des systèmes TIC, et une procédure de test et d'approbation de tous les systèmes TIC avant leur utilisation et après maintenance, proportionnée à la criticité des processus métier et des actifs concernés. La procédure contient des contrôles pour protéger l'intégrité du code source développé en interne ou par un prestataire et livré à l'entité, et prévoit que les logiciels propriétaires et, lorsque c'est faisable, le code source fourni par des prestataires tiers ou issu de projets open source sont analysés et testés avant leur déploiement en production. Pour un prestataire dont le produit est installé par le client, c'est le droit du client de tester votre version avant sa mise en service et de voir des contrôles d'intégrité sur ce que vous livrez : versions signées, sommes de contrôle, une chaîne de build que vous pouvez décrire. Pour un éditeur SaaS, c'est l'intérêt du client pour vos propres tests de version, puisque le déploiement en production se fait de votre côté.\n\n## Un compte nominatif pour chaque membre de votre personnel ayant un accès, article 20\n\nL'article 20 exige des politiques de gestion des identités selon lesquelles une identité unique correspondant à un compte utilisateur unique est attribuée à chaque membre du personnel de l'entité ou d'un prestataire tiers de services TIC accédant aux actifs informationnels et TIC de l'entité. Lorsque votre personnel de support entre dans l'environnement du client, le client lui délivrera des comptes nominatifs et attendra que vous lui disiez qui arrive et qui part ; lorsqu'il n'entre que dans votre propre environnement, le questionnaire du client vous demandera de montrer la même règle appliquée chez vous.\n\n## Vos notifications d'incident sont l'une des sources de détection du client, article 23\n\nL'article 23 exige un mécanisme de détection rapide des activités anormales qui collecte, surveille et analyse, parmi d'autres entrées, les notifications d'incident lié aux TIC d'un prestataire tiers de services TIC, détecté dans les systèmes et réseaux propres du prestataire, susceptible d'affecter l'entité. L'alerte du client est conçue pour recevoir vos notifications comme un flux, à côté de ses propres journaux et de son renseignement sur les menaces, et pour les prioriser afin de les gérer dans son délai de résolution attendu, pendant et en dehors des heures de travail. L'[article sur les incidents majeurs](\u002Farticles\u002Fwhen-your-outage-becomes-your-bank-customers-major-incident-doras-six-criteria-the-two-hour-downtime-threshold-the-four-clocks-and-the-facts-your-customer-needs-from-you) explique la suite : le délai de quatre heures chez le client commence quand il classifie, et votre notification est ce qui lui permet de classifier.\n\n## Les tests de continuité incluent votre service et votre insolvabilité, articles 25 et 26\n\nL'article 25 exige que les tests des plans de continuité des activités TIC de l'entité comprennent le test des services TIC fournis par des prestataires tiers, le cas échéant, et des procédures pour vérifier que le personnel de l'entité, ses prestataires, ses systèmes et ses services peuvent répondre adéquatement aux scénarios de l'article 26 ; pour les scénarios liés aux prestataires, l'entité tient dûment compte de l'insolvabilité ou de la défaillance du prestataire et des risques politiques dans le pays du prestataire. L'article 26 exige que les plans de réponse et de rétablissement considèrent des scénarios dans lesquels une fonction critique ou importante se dégrade ou échoue, avec l'incidence potentielle de l'insolvabilité ou d'une autre défaillance d'un prestataire, et l'instabilité politique et sociale dans le pays du prestataire et là où les données sont stockées et traitées, et qu'ils mettent en œuvre des mesures de continuité pour atténuer les défaillances des prestataires de services soutenant des fonctions critiques ou importantes. La part du prestataire est la procédure de sortie et de transition de la [liste des clauses de l'article 30](\u002Fdora\u002Fcontract-clauses), 30(3)(f), et sa volonté de participer au test de continuité du client, que le point c) de l'article 30, paragraphe 3, met déjà dans le contrat.\n\n## Ce qu'un système ISO 27001 répond déjà\n\nLe règlement délégué ne nomme aucune norme, et ce qui suit est la lecture de StandardOS de l'endroit où un système de management ISO\u002FIEC 27001:2022 produit les réponses, sans présomption de conformité. L'article 4, paragraphe 2, point b) ix), c'est l'inventaire des actifs, A.5.9, si l'inventaire porte les dates de fin de support. L'article 10, c'est la mesure de gestion des vulnérabilités, A.8.8, et les termes de signalement des fournisseurs de A.5.20 ; la liste des composants est le même enregistrement que le CRA demande. L'article 11, point k), c'est l'accord avec le fournisseur, A.5.20, et la mesure de configuration, A.8.9 ; le point f) ii), c'est A.8.1 et A.8.7. L'article 13, c'est A.8.20 à A.8.22 et la mesure de cryptographie, A.8.24. L'article 16, c'est le développement sécurisé, A.8.25 à A.8.29, avec les tests de version de A.8.29 et la gestion des changements de A.8.32. L'article 20, c'est A.5.16, gestion des identités, et A.5.18, droits d'accès. L'article 23, c'est la planification de la gestion des incidents de A.5.24 et la journalisation et la surveillance de A.8.15 et A.8.16, d'où vient la notification. Les articles 25 et 26, ce sont A.5.29 et A.5.30 et les tests de continuité qu'ils exigent. Ce que la norme ne vous donne pas, c'est le registre du client, sa classification de votre service et ses scénarios ; ce sont des questions auxquelles vous répondez par des faits, et la [fiche de données du registre](\u002Fdora\u002Fregister-of-information) tient ceux qui concernent les lieux et les sous-traitants.\n\n## Que faire avant que les questions du cadre n'arrivent\n\nPubliez un cycle de vie de support avec des dates par version. Produisez une liste de composants avec versions et un rapport périodique de vulnérabilités, et écrivez la cadence de signalement dans le contrat. Rédigez le document de responsabilité partagée qui répartit les rôles au titre de l'article 11, point k), y compris les réglages que le client ne peut pas désactiver. Documentez le chiffrement en transit avec les versions de protocole. Décrivez la chaîne de publication et ses contrôles d'intégrité. Appliquez des comptes nominatifs à votre propre personnel et proposez la notification d'arrivée et de départ pour les comptes dans l'environnement du client. Reliez vos notifications d'incident à un canal que le client peut ingérer. Et répétez la sortie avec le client quand il le demande, parce que l'article 25 dit qu'il le fera. Le [hub DORA](\u002Fdora) tient les dates du règlement et de ses actes.\n",1789383970529]