Croissance et maîtrise des risques liés aux technologies de l’information et de la communication (TIC)

Du côté des exigences réglementaires, on notera ainsi en :

• 2017 : les lignes directrices de l’EBA sur l’externalisation vers des fournisseurs de services en nuage
• 2018 : le règlement délégué de PSD2 sur l’authentification forte et les normes sécurisées de communication
• 2019 : les lignes directrices, toujours de l’EBA, sur la gestion des risques liés aux TIC et à la sécurité
• 2020 : les lignes directrices de l’ESMA sur l’externalisation vers des fournisseurs de services en nuage … avec un peu de retard sur sa collègue
• 2021 : la modification de l’arrêté du 3 novembre sur le contrôle interne du risque informatique
• Juillet 2021 : la notice ACPR sur la gestion des cyber-risques dans le secteur de l’assurance
• Juillet 2021 : la notice ACPR sur la gestion du risque informatique dans les secteurs de la banque, des services de paiement et des services d’investissement
• Et enfin, la proposition de règlement sur la résilience opérationnelle numérique du secteur financier, dont on attend (avec impatience) la validation par le Parlement et le Conseil

Arrivé parmi les derniers de la longue file de risques inclus dans exigences réglementaires, le risque lié aux TIC bénéficie de l’expérience des régulateurs. Qu’il s’agisse de la gestion des risques opérationnels (évaluation en fréquence et sévérité, évaluation de l’efficacité des palliatifs), de la gestion des risques liés à l’externalisation (analyse préalable, exigences contractuelles, suivi des indicateurs, réversibilité), ou de pures problématiques de sécurité (cryptage, redondance), les textes réglementaires les plus récents montrent clairement une maîtrise issue du retour des expériences passées.

Les établissements se trouvent donc, une fois n’est pas coutume, devant des exigences réglementaires pleines de bon sens, dont la mise en place présente une véritable amélioration de la maîtrise des risques, plutôt qu’une énième couche de contraintes sans réelle valeur ajoutée.

Importance des systèmes de TIC dans la finance

Pour comprendre pourquoi les régulateurs du monde financier s’intéressent soudain de beaucoup plus près aux risques TIC, il faut comprendre à quel point les établissements sont devenus dépendants de leurs systèmes informatiques, tant des applications historiques que des nouvelles technologies.

La montée en puissance des systèmes de TIC dans la finance est en phase avec la montée en puissance de l’informatique et du numérique dans son ensemble : des activités commerciales sophistiquées à la gestion des clients, toutes les étapes reposent désormais sur des systèmes informatiques. Registres distribués, robots-conseillers ou RPA font les gros titres, mais ne doivent pas couvrir le fait que le reporting le plus élémentaire ou les transactions financières quotidiennes sont traitées par des systèmes informatiques beaucoup plus critiques.

Importance des systèmes historiques

L’automatisation ayant fait ses preuves, de nombreuses initiatives ont été lancées pour améliorer le taux d’automatisation dans les institutions financières. Le trading algorithmique est un exemple d’automatisation bénéficiant de l’évolution des infrastructures de marché. Google a montré ce que l’automatisation pouvait apporter en automatisant la génération de revenus à partir de la publicité, ce qui a motivé de nombreux projets de marketing. En termes de productivité, l’automatisation des opérations permet au personnel de se concentrer sur les exceptions et les décisions à valeur ajoutée. Cependant, cela a mis en évidence le concept de dette technologique, où les systèmes et infrastructures existants peuvent limiter la mesure dans laquelle un processus peut être automatisé.

La conséquence directe de la croissance de l’automatisation est la montée en puissance des FinTechs. La plupart essaient d’utiliser des technologies plus efficaces que celles des institutions financières pour optimiser des processus spécifiques. Cependant, la plupart dépendent encore de l’infrastructure des services financiers, qui a été construite au fil des décennies par les institutions financières et n’est pas nécessairement compatible.

Interdépendance des systèmes

Un exemple typique d’interconnectivité est la chaîne d’actions initiée à partir d’un paiement. Par exemple, les activités transactionnelles sur les marchés financiers nécessitent un accès aux marchés, aux courtiers, la capacité de calculer les prix, d’envoyer des confirmations aux systèmes internes et à ceux des contreparties, de générer les reportings réglementaires, etc. Les activités de paiement par cartes doivent, elles, gérer des flux aller-retour d’informations, d’interrogations et d’autorisations, ainsi que le chiffrement de bout en bout. Ceci implique de nombreuses étapes qui, pour être automatisées, ne sont pas visibles par la plupart des acteurs. Cependant, des défaillances dans un maillon de la chaîne peuvent affecter l’ensemble du processus, chez plusieurs acteurs simultanément.

L’indisponibilité ou la simple perte de performances des systèmes utilisés affectent gravement les opérations. En particulier dans les activités de paiement, le temps nécessaire pour compléter une opération est un élément critique. Ainsi, quel que soit le degré d’innovation, il n’y a pas d’exemple de nouvel acteur sans une infrastructure technologique solide.

Dépendance aux données

Les données sont la pierre angulaire des services financiers. Les conditions des prêts sont décidées en fonction des données des contreparties et de leur environnement, les investissements sont réalisés en fonction des données des marchés en essayant d’analyser les évolutions potentielles, les nouveaux produits sont lancés à partir des espérances de développement issues des données marketing. Post-acquisition, tous les clients sont surveillés grâce aux données de leurs opérations et la comparaison avec leurs pairs.

Pour répondre à ces besoins, toute une industrie s’est développée au cours des dernières décennies. Des noms tels que Bloomberg, Factset, Markit ou Reuters sont familiers car déjà utilisés pour fournir des indices sur de nombreux aspects de l’économie. Les bourses qui n’abritent plus de salles de marché sont devenues de puissants fournisseurs de données (NYSE TEchnologies, ICE Data Services …). En outre, certains fournisseurs se consacrent à la gestion des données, car au sein des organisations, l’utilisation de données est souvent gérée de manière incrémentale, entraînant des surcoûts et parfois une diminution de l’intégrité des données. La création et la maintenance d’une source de données fiable est une tâche complexe pour les grandes organisations.

La donnée s’est également invitée là où le papier régnait en maître : GED, OCR, signature électronique. La digitalisation des contrats fait reposer l’édifice juridique des établissements sur les systèmes de données, là où le scan de documents présentait autrefois une double sécurité. Il en résulte un besoin de nouveaux acteurs, comme les tiers de confiance certifiés, et la nécessité de cadrer et de tracer les processus d’approbation afin d’éviter une jurisprudence basée sur la défiance des systèmes.

Dépendance aux tiers

Comme nous venons de le voir, les compétences en matière de TIC deviennent très spécialisées, et les établissements financiers peuvent difficilement toutes les internaliser. Ils ont donc un besoin croissant de recours à la prestation. L’utilisation du cloud computing est en augmentation et fait l’objet d’une attention réglementaire spécifique. Cependant, il s’agit d’un aspect de la délégation d’une partie de l’infrastructure à des tiers, alors que l’externalisation peut aller jusqu’à l’ensemble des métiers de l’informatique.

L’externalisation métier est pertinente en particulier pour les petites structures, qui du fait de la concurrence ont besoin de se recentrer sur leur cœur de métier, et cherchent à externaliser au maximum les fonctions non opérationnelles. Mais pas seulement. Les initiatives réglementaires ou les contraintes du marché ont parfois augmenté le besoin de puissance de calcul. Solvabilité II ou FRTB sont deux exemples qui nécessitent de modifier le nombre de machines exécutant des calculs avec toute la connectivité associée. Dans ce cas, s’appuyer sur des entreprises spécialisées capables de déployer rapidement des capacités de traitement et de fournir des garanties de gestion et de mise à niveau est une décision très tentante. L’ensemble de l’infrastructure en tant que service (IaaS) est une industrie à part entière avec les services financiers comme clients prisés.

Une extension naturelle de l’infrastructure est le logiciel. Le développement, la maintenance et la mise à niveau d’un système informatique est une tâche complexe. Le débat sur Buy vs Build (choix d’acheter un progiciel externe ou de développer en interne) dure depuis longtemps, et penche de plus en plus vers le choix externe. Et ce choix est de plus en plus multi-acteurs. Au lieu d’un fournisseurs externe et d’un service informatique interne, on trouve maintenant une couche de développeurs spécialisés, qui adaptent des progiciels complexes en développant des fonctionnalités spécifiques requises par les clients. Dans le pire des cas, ces caractéristiques spécifiques ont changé le progiciel à tel point  que les mises à niveau ont été rendues difficiles. Une solution a donc été de déléguer la gestion du progiciel pour s’assurer qu’il serait maintenu par le fournisseur ou le développeur, y compris des mises à niveau en temps opportun.

Identification des risques liés aux TIC

Après cet aperçu de l’étendue de l’exposition des établissements aux TIC et à leurs acteurs, il est aisé de comprendre pourquoi la gestion des risques liés aux TIC est devenue un enjeu majeur de la gestion des risques dans les établissements.

De très spécialisés par le passé (relations avec les fournisseurs de cloud, exigences de PCA), les textes réglementaires se sont adaptés à cette complexité et couvrent aujourd’hui la plupart des risques identifiables.

Définition

Tout comme les risques opérationnels, les risques liés aux TIC ont la particularité de comprendre aussi bien des risques issus de failles internes que de menaces externes.

La définition des risques liés aux TIC et à la sécurité dans les lignes directrices de l’EBA est la suivante :

• Risque de perte découlant d’une violation de la confidentialité, d’une défaillance de l’intégrité des systèmes et des données, de l’inadéquation ou de l’indisponibilité des systèmes et des données, ou de l’impossibilité de modifier les technologies de l’information dans un délai et pour des coûts raisonnables, lorsque l’environnement ou les exigences métiers changent. Cela inclut les risques de sécurité découlant de processus internes insuffisants ou de défaillance de ces processus, ou bien d’événements externes, tels que des cyberattaques ou une sécurité physique insuffisante

Les cyberattaques sont toujours plus nombreuses, notamment depuis que le travail à distance, généralisé par la pandémie, a déclenché une augmentation des flux externes de données, et plus récemment depuis que la France a été montrée du doigt comme l’un des pays les plus laxistes en matière de cybersécurité. Il s’agit aussi du risque le plus visible par le public.

Cependant, la définition montre bien que la cybersécurité est loin d’être la seule préoccupation en matière de risques TIC. En effet, dans les établissements financiers, de nombreux systèmes critiques fonctionnent en permanence, qu’ils soient ou non accessibles de l’extérieur. Pour le bon déroulement des activités, les problèmes de disponibilité des systèmes ou d’intégrité des données sont tout aussi importants, plus fréquents, et peuvent avoir des conséquences tout aussi désastreuses et coûteuses que les attaques externes.

Typologies de risques

Les lignes directrices de l’EBA, reprises en grande partie par le projet de règlement, ont ainsi classé les risques TIC en cinq catégories :

• Disponibilité et continuité
• Intégrité des données
• Sécurité
• Risques liés aux changements
• Risques liés aux externalisations

Cette segmentation peut avoir des chevauchements (changement créant des problèmes d’intégrité des données, événements de sécurité affectant la disponibilité des systèmes…) mais fournit un point de départ qui rejoint de nombreuses demandes réglementaires. Elle met également en lumière les sources de risques les moins visibles (risque de régression, manque de contrôle des prestations externes).

L’étendue des risques considérés est encore plus visible lorsque l’on entre dans le détail de chacun d’entre eux :

La disponibilité et la continuité couvrent tous les aspects du maintien des systèmes en conditions de fonctionnement ainsi que les actions de restauration de ces systèmes lorsqu’ils sont compromis. Toutes les entités financières maintiennent des sites de sauvegarde à partir desquels elles peuvent exécuter leurs applications lorsque leurs sites principaux sont compromis. Avec la complexité croissante des systèmes, garantir que ces sites peuvent remplir leur objectif doit être testé régulièrement. Les tests complets doivent idéalement garantir que les systèmes fonctionnent, que toutes les données sont accessibles en amont et en aval et que les utilisateurs peuvent faire fonctionner les systèmes. Les tests de continuité sont complexes. Pour être pleinement convaincant sur les volumes de production, certains tests sont nécessaires pour prouver qu’ils peuvent gérer une période typique, au moins une journée complète. Cette « lecture en direct » signifie la commutation du système en direct sur le site de sauvegarde et nécessite une planification très minutieuse pour garantir que le test n’impacte pas directement la production.

La sécurité est un domaine spécifique avec des compétences et des équipes dédiées. Les cyberattaques prennent le plus souvent plusieurs semaines à préparer avec divers test d’accès via le phishing, des vulnérabilités d’infrastructure ou des faiblesses d’organisations très spécifiques. Cependant, une fois qu’une intrusion a eu lieu, le but de l’attaquant est généralement de ne pas être détecté pour avoir le temps de mettre en place des éléments supplémentaires de son attaque. Le CSIRT (Computer Security Incident Response Team) doit être vigilant pour réagir aux intrusions suffisamment rapidement pour s’assurer que les dommages sont limités ou que les zones compromises sont séparées du reste de l’organisation. L’une des difficultés de la surveillance de la sécurité est qu’elle doit s’appliquer à de nombreux types d’accès différents depuis des aspects très techniques de l’infrastructure (réseau, serveurs…) jusqu’au fonctionnement interne d’applications spécifiques où la configuration et la gestion des accès peuvent créer des combinaisons complexes à surveiller.

La gestion du changement est souvent considérée comme l’une des principales activités des équipes informatiques, car les systèmes évoluent constamment. Mais le changement peut être à l’origine d’incidents très coûteux. L’incident d’Euronext en octobre 2020 est né de ce qui était prévu comme une migration standard. Avec l’augmentation de la connectivité des systèmes et l’évolution constante, les tests de continuité et de non-régression sont cruciaux. Cependant, il est difficile de couvrir tous les cas possibles, de même que de reproduire le volume sous lequel les systèmes sont prévus pour fonctionner. Cela explique que les tests et l’assurance qualité peuvent représenter plus d’un quart du budget informatique. L’importance d’améliorer la qualité et la rapidité du développement est primordiale et a généré de nombreuses initiatives, de l’automatisation des tests à l’émergence de DevOps pour de nombreuses institutions.

L’intégrité des données peut être décrite comme l’assurance de l’exactitude et de la cohérence des données tout au long de leur cycle de vie. L’importance des données est difficile à ignorer car pratiquement toutes les institutions se sont tournées vers l’analyse massive de données pour suivre leurs activités, connaître leurs clients, analyser les informations de marchés ou développer leurs activités. Les exigences réglementaires, telles que BCBS 239 ou le RGPD, ont également apporté leur lot de contraintes concernant la maîtrise des données. La gouvernance des données et la création de golden sources est devenue cruciale à la fois pour maintenir l’intégrité des données au sein des systèmes et pour réduire les coûts d’exploitation. Avec d’innombrables entrées de données dans une vaste architecture informatique et la nécessité de maîtriser les coûts des fournisseurs, les problématiques de données ont engendré des besoins de structuration croissants.

Enfin, la maîtrise des risques liés à l’externalisation vise à couvrir les risques générés par le recours à des prestataires dans diverses situations. Cela peut aller de l’impact d’un processus entièrement externalisé à la conséquence d’une seule activité spécialisée, voire à un simple développement commandé en externe. L’utilisation de solutions basées sur le Cloud implique également la maîtrise de tous les risques ci-dessus. Que ce soit dans le cas d’applications externalisées ou d’hébergement en cloud, le risque de changement est partiellement géré par le fournisseur, mais la responsabilité reste chez l’établissement. La gestion du risque d’externalisation doit donc être proportionnée au risque. Elle peut aller de la formalisation d’obligations contractuelles générales à une commande et un suivi très précis entre l’établissement et ses prestataires, jusqu’à la mise à disposition d’un environnement spécifique sous contrôle de l’établissement.

Evaluation des impacts

La difficulté d’évaluer les impacts des risques liés aux TIC est que l’origine de la plupart des risques est identifiée par les équipes informatiques alors que les impacts affectent principalement les utilisateurs. Malheureusement, la communication entre les deux communautés reste difficile dans la plupart des cas. Certains utilisateurs n’ont pas une compréhension assez claire des systèmes impliqués dans leurs activités pour se rendre compte de la dépendance de leurs opérations à l’égard de ceux-ci. Ce n’est guère surprenant étant donné la difficulté que même les professionnels de l’informatique ont à évaluer les interdépendances entre systèmes.

L’évaluation des interdépendances est encore plus difficile lorsque des tiers interviennent dans les processus. Pour couvrir le risque d’un ensemble interconnecté, les établissements et les régulateurs ont dû passer au concept de résilience opérationnelle. Pour illustrer la nécessité de cette démarche, examinons la mesure d’impact sur une occurrence de risque lié aux TIC selon différentes sources.

Evaluation interne

D’un point de vue purement informatique, la plupart des systèmes peuvent être reconstruits en un temps limité et souvent bien estimé. Réinstaller un système complet à partir d’un nouveau matériel, en utilisant une copie de sauvegarde récente, équivaudra au coût du matériel, des licences logicielles potentielles et du temps des différentes équipes informatiques susceptibles d’être impliquées. La connexion du système à ses nombreuses sources de données plausibles et aux systèmes en aval nécessitera des tests supplémentaires. La taille et la réactivité des équipes auront un impact car plusieurs équipes spécialisées disponibles instantanément et capables de travailler ensemble successivement sont plus coûteuses qu’une seule équipe généraliste.

Ce coût est généralement une fraction des montants impliqués dans l’utilisation des systèmes des institutions financières, qu’il s’agisse du montant transféré depuis un système de paiement, généré par une activité de trading ou susceptible d’être perdu suite à une indisponibilité prolongée. En comparant les coûts de retour à l’activité avec les revenus issus de l’utilisation des systèmes et les conséquences des pannes sur le résultat financier total, le département informatique peut budgéter les ressources de backup et de retour à la normale.

Evaluation systémique

Cependant, la perte évaluée à ce stade est généralement sous-estimée. Une évaluation des risques devrait également prendre en compte d’autres impacts tels que la perte de confiance des clients et des dommages à la marque, qui sont plus difficiles à estimer. Sur le plan financier, les amendes contractuelles ou réglementaires pour manquement aux obligations devraient également être prises en considération.

Par exemple, l’indisponibilité d’un système pour une activité de trading ou de paiement peut conduire au non-respect d’obligations contractuelles entraînant des conséquences importantes. Côté marchés, des systèmes comme SWIFT imposent des obligations strictes et prévoient généralement des sanctions lorsqu’elles ne sont pas remplies. Côté retail, une défaillance des systèmes de paiement peut avoir un impact d’image immédiat par le biais des réseaux sociaux. Les contrats avec les gros vendeurs prévoient donc également des performances cibles assorties de sanctions. Enfin, si les contrats des systèmes commerciaux prévoient des sanctions financières, des systèmes comme Target2 ou CHAPS sont sous la supervision directe des banques centrales, et les violations peuvent rapidement attirer l’attention des superviseurs.

Limitation des impacts

L’un des aspects de la solution consiste à se concentrer sur la continuité informatique. Si toutes les conséquences de la défaillance d’un système sont difficiles à évaluer, avoir des processus de sauvegarde et de rétablissement rapide est la solution la plus simple pour faire face à la plupart des problèmes.

L’importance de la continuité informatique est généralement définie par un objectif de processus de récupération (RPO) et un objectif de temps de récupération (RTO). Les applications critiques ont généralement un RPO défini à 0. Cela signifie que la récupération permettra au processus d’être restauré sans perdre aucune étape. Par exemple, aucune transaction n’est perdue lors du passage à la solution de sauvegarde. De même, le RTO définit un temps auquel le système est censé être à nouveau disponible. Malheureusement, les établissements financiers majeurs sont susceptibles d’avoir des centaines d’applications avec un RPO de 0 ou un RTO court (quelques heures). Cet objectif reste donc atteignable dans le cas d’un incident ponctuel, sur une application qui n’en impacte pas d’autres, mais devient inatteignable en cas de dysfonctionnement massif, les ressources nécessaires pour assurer la restauration complète dans les temps impartis étant exorbitantes.

D’autres considérations peuvent venir impacter la capacité de restauration. Par exemple, si une partie d’un processus repose sur un système avec des attentes moindres, l’ensemble du processus pourrait être affecté par le fait que ce système ne soit pas restauré dans le même laps de temps. La nécessité est donc de s’assurer que le processus informatique est considéré comme un tout. Cette approche étend l’évaluation d’impact d’un système à un processus. Cependant, elle n’est efficace que lorsque l’ensemble des participants sont sollicités dans la préparation des plans de rétablissement. Or, aujourd’hui encore, cette responsabilité reste trop souvent du ressort des services informatiques. Même si les clients internes et les principaux clients externes sont pris en compte, dans la plupart des cas, cela se fait sans  analyse de bout en bout.

Espérons que les derniers textes réglementaires, qui exigent une information, voire une participation, de l’ensemble des acteurs concernés dans les projets informatiques, permettront d’améliorer cet aspect de la prévention des risques.

Actions préventives et correctrices

Afin de prévenir les risques liés aux TIC, les derniers textes réglementaires vont bien au-delà de la simple continuité des systèmes. Dans les lignes directrices de l’EBA et le projet de règlement, on trouve ainsi des exigences concernant :

• La formation
• La connaissance des processus et des systèmes liés
• La documentation
• La sécurité
• Le contrôle interne
• La collecte et l’analyse des incidents
• Le reporting

Si depuis plusieurs années les établissements ont commencé à sensibiliser leurs employés à la prévention des cyberattaques (phishing, virus, chevaux de Troie, etc.), les nouvelles exigences couvrent la sensibilisation aux risques informatiques de toute nature, la formation aux règles de prévention des risques et une formation plus approfondie à la sécurité. A l’instar des formations sur la lutte anti-blanchiment, les régulateurs imposent également une fréquence au moins annuelle de formation, ainsi qu’une formation spécifique des dirigeants effectifs. Même pour les établissements bien équipés dans ce domaine, le changement de périmètre et l’obligation de fréquence, qui induit une obligation de suivi, devrait nécessiter quelques ajustements. Pour d’autres, ce sera l’occasion de renforcer un axe de prévention bien nécessaire.

La grande nouveauté apportée par les textes est l’exigence d’une cartographie des processus préalable à la cartographie des systèmes. En effet, pour éviter le silotage des directions informatiques et opérationnelles, les régulateurs exigent que la criticité des opérations soit d’abord évaluée côté métier, avec toutes les interactions liées, puis seulement étendue aux systèmes qui les sous-tendent. Cette volonté de transversalité se retrouve également dans les exigences de pilotage de projets, où l’ensemble des acteurs concernés, et spécifiquement les acteurs métier, ont une obligation de participation active. Cerise sur le gâteau, les lignes directrices EBA comme le projet de règlement incluent spécifiquement dans ces exigences les EUC (End User Computing, ou applications bureautiques utilisées par les opérationnels sans passer par le département informatique). Et dans ce cas, l’effort sera inversé, avec l’obligation pour les opérationnels d’inclure de département informatique dans leurs projets.

L’obligation de documentation est également renforcée, puisqu’elle couvre l’ensemble des processus de prévention et de détection des risques liés aux TIC. Du cadre de gestion des risques aux processus projet, en passant par la charte SSI, les codes source, le recensement des externalisations ou la cartographie des risques, les régulateurs exigent une formalisation complète des ressources liées au TIC. Celle-ci couvre aussi bien les processus amont (cartographies, recensement, procédures, contractualisation) qu’aval (incidents, plans d’action, reporting).

La partie sécurité couvre des éléments classiques qui ne devraient pas changer les mesures déjà en place dans la plupart des établissements : sécurité physique, SIEM, authentification forte, limitation des comptes à privilège, etc. C’est sur la partie tests que le projet de règlement prévoit des contraintes beaucoup plus exigeantes que les dispositions actuellement en place : obligation de tests approfondis au moins tous les trois ans (cumulée à l’exigence à un an de l’EBA pour les systèmes critiques), par des testeurs accrédités, conduits selon des principes en attente de normes techniques des ESAs, le tout sous la surveillance des superviseurs. Bien que le règlement ne soit pas finalisé, il est fortement recommandé aux établissements de prévoir rapidement un renforcement de cette activité, car l’exigence de certification des tiers risque de créer une rareté des ressources disponibles lors de la première réalisation de tests suivant la publication.

Les textes n’introduisent pas d’élément particulièrement nouveau en matière de contrôle interne par rapport à la gestion habituelle des risques opérationnels. Les risques liés aux TIC faisant partie des catégories bâloises historiques, à une question de terminologie près, les établissements devront sans doute tout au plus ajuster leurs plans de contrôle existants. Le principe de faire suivre les risques par une fonction de contrôle indépendante est normalement intégré depuis longtemps par les établissements, de même que l’intervention de l’audit interne. Le principe de correction et de plans d’actions, formalisé dans le règlement, n’introduit pas non plus d’idées radicalement nouvelles. Pour que les nouveaux textes soient gérables par les établissements, il fallait au moins un élément sur lequel les établissements puissent cocher la case sans trop d’effort.

Le principe de collecte et d’analyse des incidents ne devrait pas non plus beaucoup changer les habitudes en place. Ce type de suivi est en effet depuis longtemps au cœur de l’évaluation des performances, tant des services informatiques que des fournisseurs externes. Là où les textes introduisent des nouveautés, c’est en termes de reporting des incidents. En effet, là où habituellement l’informatique lavait son linge sale en famille”, les nouvelles réglementations exigent une remontée des incidents vers l’organe de direction, immédiatement en cas d’incident majeur, … ainsi que vers les autorités de supervision. Le RGPD est passé par là.

Cette obligation de reporting ne se limite pas aux incidents. La volonté affichée des textes est d’une part d’impliquer bien plus directement les dirigeants effectifs et autres organes de direction dans la gestion des risques liés aux TIC, et d’autre part de renforcer la supervision, les connaissances et l’implication des superviseurs dans ce domaine. Ainsi, un appétit au risque spécifique aux TIC doit être proposé à l’organe de surveillance. L’organe de direction assume la responsabilité globale du cadre de gestion des risques liés aux TIC … et au-delà des reportings voulus par le texte, aura sans doute des exigences d’information bien plus approfondies qu’aujourd’hui. Quant aux superviseurs, le projet de règlementation prévoit explicitement leur information dans un certain nombre de cas : modification des systèmes critiques, externalisations informatiques, résultat des tests de continuité, incidents majeurs. Leur autorisation préalable est également nécessaire pour l’externalisation des tâches de contrôle des risques, ainsi que pour la validation de la portée des tests d’intrusion.

Même si beaucoup de choses sont déjà en place dans les établissements, en particulier dans les plus gros, on voit que la mise en place de l’intégralité des exigences engendrera tout de même un effort important. Celui-ci sera encore plus important pour les petites structures, moins bien préparées au départ, et encore plus brutal pour les entités non bancaires, qui subiront de plein fouet l’impact du règlement sans être passés par l’étape intermédiaire des lignes directrices EBA. A ces dernières, nous conseillons vivement de réaliser dès à présent un état des lieux de l’effort à fournir pour parvenir à une conformité minimale sur l’ensemble des points requis.

Stratégie des établissements

Devant l’étendue des risques et des mesures requises pour les couvrir, les établissements font (ou feront) face à la nécessité d’opérer des choix stratégiques en matière de systèmes informatiques, et donc indirectement en matière de processus opérationnels liés.

Pour chaque système et chaque processus dépendant, les choix se réduisent à quatre actions exclusives les unes des autres :

• Cesser l’activité générant le risque
• Accepter le risque
• Transférer le risque
• Atténuer le risque

Cesser une activité à cause du risque qu’elle engendre est une méthode assez extrême. Hormis dans le cas de risques inacceptables par rapport à l’appétit au risque de l’établissement, ce choix est généralement réservé à des stratégies d’arbitrage, entre le rapport coût bénéfice de plusieurs activités dont la poursuite est remise en question. Sortir du numérique dans l’absolu n’est pas une option. Au contraire, la pandémie de 2020 a montré que l’utilisation de l’informatique et de la digitalisation était non seulement incontournable, mais qu’elle était nécessaire lors d’un changement radical du contexte opérationnel.

L’acceptation du risque tel qu’il est et son inclusion dans l’appétit au risque suppose une décision au niveau le plus élevé de l’organisation. Cela ne s’envisage donc que lorsqu’il n’y a pas de moyen efficace de gérer certains risques liés aux TIC, ou lorsque le coût de mise en œuvre de ces moyens est disproportionné par rapport aux bénéfices du système en l’état, même pondéré par les risques potentiels. Ce cas sera néanmoins de plus en plus rare, puisque les mesures globales d’atténuation du risque deviendront obligatoires de toute façon. Pour qu’un risque informatique brut soit intégré à l’appétit au risque de l’établissement, il faudra donc qu’aucune des mesures d’atténuation du risque imposées par les nouveaux textes réglementaires ne présente la moindre efficacité.

Transférer le risque consiste à déplacer l’activité chez un tiers, souscrire à une assurance ou prévoir un accompagnement externe spécifique en cas d’événements explicites. L’externalisation est clairement une option pour les risques liés à l’infrastructure, à des logiciels non ou peu interconnectés, et parfois à des processus entiers lorsqu’ils sont suffisamment autonomes (KYC, calculs de risque). Le transfert de coût reste toutefois limité par l’obligation qu’ont les institutions de contrôler leurs prestataires de services critiques. Dans ce cas, le gain existe lorsque l’expertise du prestataire en maintenance ou en sécurité dépasse largement celle d’une solution internalisée.

L’assurance du risque informatique est en pleine expansion, et en évolution. Auparavant limité à la responsabilité civile professionnelle des SSII ou à l’assurance des actifs corporels, le secteur de l’assurance a trouvé une opportunité avec l’entrée en vigueur du RGPD et de ses sanctions anormalement élevées. La montée en puissance des cyberattaques et les défaillances des infrastructures de marché ont également élargi le champ des possibles pour les assureurs … et pour les acteurs financiers, qui ont commencé à arbitrer entre coûts de contrôle interne et coût de réduction du risque. Cette solution peut être performante notamment pour les petites structures, chez lesquelles les capacités de contrôle interne ou d’expertise IT sont limitées. L’activité est toutefois relativement nouvelle pour les assureurs, et les actuaires manquent de recul pour assurer un pricing stable. Il faudra donc attendre encore quelques années pour savoir si cette solution est pérenne, voire présente des opportunités de croissance.

Dans la plupart des cas, les risques liés aux TIC sont atténués. De plus, en imposant des mesures globales, applicables à l’ensemble des actifs et projets informatiques, les textes réglementaires récents permettent des économies d’échelle sur les mesures d’atténuation du risque. Ils favorisent donc l’internalisation des compétences de maîtrise des risques liés aux TIC. Dans ce contexte, les coûts d’assurance ou de surveillance des externalisations deviennent des coûts supplémentaires. La réglementation est donc clairement en train d’influencer la stratégie des établissements vers l’atténuation des risques.

Conclusion

Le principal changement apporté par les derniers textes réglementaires, et repris dans le projet de règlement, est le changement en matière de gouvernance. En imposant l’inclusion des risques liés aux TIC dans l’appétit au risque de l’établissement, il implique l’organe de surveillance. En exigeant que l’organe de direction définisse, supervise et soit responsable du cadre de gestion des risques informatiques, il implique les dirigeants effectifs. Enfin, il exige pour le risque informatique le même cadre de maîtrise du risque et de reporting (tant en interne que vis-à-vis des superviseurs) que celui appliqué à tous les risques fondamentaux des établissements financiers.

Si le projet de règlement est adopté en l’état, ou dans un état proche de sa forme actuelle, les risques liés aux TIC viendront donc s’ajouter à la gestion des risques des établissements au même titre que le risque de crédit, de marché ou de liquidité. Culturellement, les établissements sont-ils prêts à un changement aussi radical ?

Traditionnellement, les risques liés aux TIC sont gérés par le département informatique. La récente montée en puissance de la fonction de RSSI, souvent rattachée au département Risques, a commencé à poser la question de la légitimité d’une gestion des risques assurée par le département qui les initie. Une question réglée par les nouveaux textes, puisque ceux-ci exigent que les risques liés aux TIC soient gérés par une fonction de contrôle indépendante.

La question qui se pose est donc de savoir avec quel enthousiasme cette réorganisation des responsabilités va être reçue. Par les départements informatiques d’abord, qui vont voir leurs responsabilités diminuer, mais surtout qui vont se retrouver surveillés et supervisés, là où ils jouissaient d’une autonomie et d’une indépendance dont ils profitaient largement. Par les directions métier ensuite, qui vont devoir s’impliquer dans les projets informatiques là où ils avaient l’habitude de déléguer ces tâches à des départements MOA ou à d’autres ressources externes. Pour les directions générales, enfin, qui voient leur niveau de responsabilité augmenter dans un domaine où leur courbe d’expérience n’en est qu’à ses débuts.