Dans les SGP, la conformité cyber n’est plus un dossier annexe. DORA et NIS2 imposent une mécanique vérifiable : risques cartographiés, fournisseurs tenus, incidents tracés, tests menés, preuves prêtes.
Pour les sociétés de gestion de portefeuille (SGP), DORA et NIS2 transforment la cybersécurité en obligation démontrable, au-delà des politiques écrites. Ce qui change concrètement tient à cinq piliers : cartographier les risques et les actifs critiques, encadrer les prestataires et la chaîne de sous-traitance, structurer la gestion des incidents avec des preuves exploitables, organiser des tests réguliers et réalistes, et conserver des éléments probants en continu. L’enjeu n’est pas seulement de “faire”, mais de pouvoir prouver, à tout moment, qui décide, qui exécute, ce qui est mesuré, et ce qui est corrigé.
Ce qui change : d’une cyber “raisonnable” à une cyber prouvable
Dans une SGP, le quotidien est fait d’arbitrages, d’outils spécialisés et de dépendances invisibles. Jusqu’ici, la cybersécurité pouvait rester une discipline de bon sens, solide sur le papier, inégale dans l’exécution. DORA et NIS2 déplacent le centre de gravité : le sujet n’est plus la conformité déclarative, mais la conformité observable. Ce basculement se lit dans un mot qui revient partout, même quand il n’est pas prononcé : la preuve.
La première marche, c’est la cartographie des risques. Pas une liste générique, mais une vision qui relie processus, données, applications, accès et scénarios de défaillance. Une SGP doit pouvoir expliquer, sans hésiter, ce qui est critique, pourquoi, et ce que cela implique en termes de mesures. La tension naît ici : cartographier, c’est aussi admettre ses angles morts. Et une fois l’inventaire posé, chaque exception devient une dette. Dans un univers où un incident se joue souvent sur un compte trop large ou un flux mal compris, l’exercice n’est pas administratif, il est tactique.
Deuxième déplacement, la gestion des fournisseurs. Les SGP fonctionnent avec des briques externes, hébergement, logiciels, données, support, infogérance, parfois en cascade. DORA et NIS2 rendent cette chaîne impossible à ignorer. Il ne suffit plus de “faire confiance” à un prestataire : il faut encadrer, suivre, et réagir. Concrètement, cela pousse à clarifier qui fait quoi, qui accède à quoi, comment les accès sont retirés, et comment la sécurité est contrôlée dans la durée. La relation change de nature : un contrat devient un mécanisme de contrôle. La vigilance se joue aussi dans la capacité à challenger des réponses standardisées et à refuser les zones floues. C’est dans ces interstices que se cachent les incidents les plus coûteux, et les plus difficiles à attribuer.
Troisième point, la gestion des incidents. Là encore, la nouveauté n’est pas l’existence d’un plan, mais son opérabilité et sa traçabilité. Un incident n’est plus seulement une panne à réparer, c’est une séquence à documenter. Qui a détecté, à quelle heure, avec quel signal. Quelles décisions ont été prises, par qui, sur la base de quels éléments. Quels impacts ont été mesurés, quelles mesures de confinement ont été appliquées, et comment le retour à la normale a été contrôlé. Dans une logique cyber-renseignement, cette chronologie est capitale : elle permet d’identifier un mode opératoire, de comprendre une propagation, et de réduire le risque de récidive. Sans traces, on reconstruit une histoire. Avec des traces, on produit des faits.
Pour mettre ces exigences en musique, certaines SGP s’appuient sur une entreprise de sécurité informatique, afin de structurer méthode, tests et documentation, sans confondre vitesse et précipitation.
Comment s’y préparer : tests, evidences, et gouvernance sans fiction
La préparation se joue dans la répétition et le réalisme. Les tests ne sont pas un exercice de communication, ils doivent créer des frottements. Tester un incident, ce n’est pas lire un scénario, c’est éprouver des délais, des rôles, des décisions, et la qualité des informations disponibles. L’objectif est double : trouver ce qui casse, et générer des preuves. Une SGP doit être capable de montrer ce qui a été testé, ce qui a été observé, et ce qui a été corrigé. Le correctif compte autant que le test, car il montre une boucle de maîtrise, pas un théâtre de conformité.
Cette logique oblige à revoir la production de preuves. Les éléments probants ne se fabriquent pas à la veille d’un contrôle. Ils s’accumulent, comme des journaux de bord : comptes rendus, validations, tickets, journaux techniques, plans de remédiation, décisions de gouvernance. La difficulté est de rester simple : trop de documents tue la lisibilité, pas assez tue la crédibilité. La bonne cible est une preuve utile, reliée à un risque identifié et à une mesure effective.
Reste la gouvernance. DORA et NIS2 imposent une clarté sans échappatoire : qui porte le risque, qui arbitre, qui accepte une exception, qui finance une correction. Une organisation peut survivre avec des zones grises, mais elle ne peut pas démontrer sa maîtrise avec des responsabilités floues. La préparation passe donc par des rôles explicites, des circuits de décision courts, et une capacité à prioriser. Car le piège, dans les SGP, est connu : traiter l’urgence technique sans traiter la cause structurelle, puis découvrir que la même faille se déplace chez un fournisseur, un outil ou un processus voisin.
Dans ce cadre, la conformité devient un avantage de renseignement interne : mieux voir son système, ses dépendances et ses signaux faibles, c’est réduire l’espace où un adversaire peut se dissimuler.
