Abordez l'audit déjà prêt.

Le Règlement (UE) 2022/2554 sur la résilience opérationnelle numérique (DORA) s’applique aux entités financières de l’UE. Il établit des exigences en matière de gestion des risques TIC, de signalement des incidents TIC, de tests de résilience opérationnelle numérique (y compris les tests de pénétration fondés sur les menaces, TLPT, pour les entités significatives), de gestion des risques TIC liés aux tiers et de partage d’informations sur les cybermenaces. DORA est entré en vigueur le 17 janvier 2025. Acuna couvre les exigences DORA sur les quatre volets : cartographie des référentiels dans Comply, contrôles TIC et inventaire des actifs dans Implement, gestion des incidents et des tiers dans Operate, et constats TLPT et actions correctives dans Assure.

Le Chapitre IV de DORA exige que les entités financières maintiennent un programme de test de résilience opérationnelle numérique. Cela inclut les évaluations de vulnérabilités, les tests de sécurité réseau, l’analyse des lacunes et les revues de sécurité des applications. Les entités significatives doivent également conduire des tests de pénétration fondés sur les menaces (TLPT) au moins tous les trois ans, simulant des attaques réelles contre les systèmes de production actifs à partir de renseignements sur les menaces. Les TLPT doivent être réalisés par des testeurs qualifiés et les résultats communiqués à l’autorité nationale compétente. Acuna suit la planification des TLPT, les constats et les actions correctives dans le volet Assure.

SOC 2 Type I évalue si les contrôles sont conçus de manière appropriée à un point précis dans le temps. SOC 2 Type II évalue si ces contrôles ont fonctionné efficacement sur une période, généralement de 6 à 12 mois. Le Type II est plus rigoureux car il exige des preuves d’un fonctionnement soutenu, et non simplement que les contrôles existent sur le papier. La plupart des acheteurs entreprises exigent un rapport Type II. Acuna est conçu pour la collecte continue de preuves pendant la période d’observation Type II, avec des tâches récurrentes, le scoring de santé des contrôles et des dossiers de preuves prêts pour l’audit.

Dans Acuna, les enregistrements de preuves suivent quatre états : Brouillon (en cours de compilation), Soumis (envoyé pour approbation), Approuvé (verrouillé et horodaté) et Expiré (plus en vigueur). Chaque enregistrement capture les dates de collecte, de revue et d’expiration, prend en charge les pièces jointes versionnées et peut être relié à plusieurs contrôles avec des notes par lien. Les approbateurs reçoivent des notifications et peuvent demander des modifications avant d’accepter. Les preuves approuvées contribuent aux métriques d’efficacité des contrôles et de préparation aux audits. Les preuves expirées sont signalées visuellement et ne peuvent pas être supprimées sans l’approbation d’un administrateur, préservant ainsi la piste d’audit.

Acuna prend en charge quatre types de sources de données KPI. La saisie manuelle est destinée aux métriques extérieures à la plateforme (scores de tests de pénétration, résultats d’enquêtes). Les KPI calculés se calculent automatiquement à partir des données de conformité en temps réel via une bibliothèque de métriques prédéfinie (regroupée par catégories Conformité, Opérations, Risques, Contrôles, Général et Assure), un créateur de requêtes personnalisées avec filtres et opérateurs, ou un flux d’efficacité et d’exécution alimenté par les contrôles. Les connecteurs extraient des valeurs de services externes intégrés. L’API externe/webhook reçoit des valeurs entrantes de systèmes qui envoient des données à Acuna. Des seuils de conformité par élément avec des barres de progression codées par couleur sont disponibles pour les sources calculées.

Assure est la couche de preuves et de préparation aux audits. Il gère les enregistrements de preuves tout au long de leur cycle de vie (Brouillon, Soumis, Approuvé, Expiré), relie les preuves aux contrôles, suit les dates de revue et d’expiration, et regroupe les preuves pour les audits internes ou externes. Assure gère également les constats : observations d’audit, non-conformités et actions correctives avec échéances et responsabilités. Le volet fournit des tableaux de bord de préparation aux audits indiquant la couverture des preuves, les prévisions d’expiration et le nombre de constats ouverts, afin que vous sachiez exactement où vous en êtes avant l’arrivée d’un auditeur.

La préparation aux audits dans Assure est une métrique composite pilotée par trois facteurs : la couverture des preuves (pourcentage de contrôles avec au moins un enregistrement de preuve approuvé et non expiré), la santé des contrôles (remountée depuis la complétion des tâches) et le nombre de constats ouverts (non-conformités et observations non résolues). Chaque facteur contribue à un score global de préparation affiché sur le tableau de bord Assure. Lorsque des preuves expirent ou qu’un constat est en retard, le score baisse automatiquement. Cela offre aux responsables conformité un chiffre unique à communiquer à la direction et aux auditeurs, soutenu par des détails accessibles jusqu’à chaque contrôle et artefact sous-jacent.

Un tableau de bord RSSI est une vue consolidée des indicateurs de sécurité, de risque et de conformité dont un Responsable de la sécurité des systèmes d’information a besoin pour piloter son programme. Les tableaux de bord RSSI performants combinent : posture de conformité multi-référentiel (ISO 27001, NIS2, DORA, SOC 2), registre des risques avec scoring et tendances, maturité des contrôles par domaine, et préparation aux audits à venir. Dans Acuna, chaque RSSI configure son tableau de bord via RBAC pour afficher uniquement son périmètre, ses KPI, et les risques dont il répond. La direction voit le résumé. Les analystes voient leurs contrôles. Un seul système, des vues distinctes selon le rôle.

Un rapport SOC 2 est le document issu d’une mission d’attestation : un cabinet d’experts-comptables indépendant examine les contrôles d’une organisation de services au regard des critères de services fiduciaires de l’AICPA et émet une opinion formelle. Le rapport est un document privé — contrairement à un certificat ISO 27001, il n’est pas vérifiable publiquement. Il est communiqué sous NDA aux clients entreprises et prospects qui le demandent lors de la due diligence fournisseur. Les équipes achats et sécurité examinent trois éléments dans un rapport SOC 2 : l’opinion de l’auditeur (sans réserve ou avec exceptions), la description du système (quels services et systèmes étaient dans le périmètre), et le tableau des exceptions (contrôles en échec ou en déviation pendant la période d’audit). Un périmètre trop étroit ou une opinion avec réserve soulève des questions que l’acheteur posera. Un rapport Type II avec une opinion sans réserve et un périmètre adapté est l’artefact qui conclut des contrats entreprises là où un questionnaire sécurité fournisseur seul ne suffirait pas. Le rapport est généralement renouvelé chaque année — d’où le caractère continu de la période d’observation plutôt qu’un exercice ponctuel.

La préparation et l’audit SOC 2 prennent généralement six à dix-huit mois selon le point de départ. La période d’observation pour un rapport Type II est d’au minimum six mois — l’auditeur doit constater le fonctionnement effectif des contrôles pendant au moins cette durée. Le premier rapport Type II n’est donc disponible qu’environ six mois après la mise en service des contrôles. Les organisations qui partent de zéro consacrent en général deux à quatre mois à la préparation — cadrage, mise en œuvre des contrôles, outillage et collecte initiale des preuves — avant d’ouvrir la période d’observation. Le délai total atteint ainsi neuf à douze mois pour un premier Type II. Le Type I va plus vite : il s’agit d’une évaluation à un instant donné, sans période d’observation. Certaines organisations l’utilisent comme jalon vers le Type II, pour mettre un rapport entre les mains des clients plus tôt pendant que les preuves Type II s’accumulent. Le principal facteur de retard n’est pas l’audit lui-même mais la période d’observation : les contrôles doivent fonctionner sans interruption et les preuves être collectées de façon continue. Commencer la collecte de preuves en amont — avant l’ouverture formelle de la fenêtre d’observation — est le moyen pratique de compresser le calendrier global.

Le registre d’informations DORA est le registre, exigé par l’article 28 du Règlement (UE) 2022/2554, de l’ensemble de vos arrangements contractuels pour l’utilisation de services TIC fournis par des tiers. Chaque entité financière doit le tenir à jour, le maintenir au niveau de l’entité et, le cas échéant, au niveau sous-consolidé et consolidé du groupe, et le mettre à disposition de son autorité de surveillance compétente — en France, l’AMF ou l’ACPR selon le type d’entité — sur demande. Il constitue l’ossature du régime de risque tiers de DORA : les superviseurs l’utilisent pour voir, à l’échelle du secteur financier, de quels prestataires le système dépend. Le registre n’est pas un inventaire ponctuel. C’est un enregistrement vivant qui doit refléter votre chaîne d’approvisionnement TIC telle qu’elle est réellement, y compris quels arrangements soutiennent des fonctions critiques ou importantes, car ceux-ci entraînent des exigences contractuelles et de supervision plus strictes. Le registre documente chaque arrangement contractuel TIC : le prestataire, le service, s’il soutient une fonction critique ou importante, et les clauses contractuelles exigées par DORA. Les autorités européennes de supervision fixent le modèle détaillé et les champs par des normes techniques. Un registre tenu dans un tableur, séparé des relations fournisseurs qu’il décrit, est exact le jour de sa création et erroné la semaine où un contrat change sans mise à jour — c’est précisément l’échec que vise l’exigence DORA de tenir le registre à jour.

DORA impose aux entités financières de détecter, gérer, classifier et signaler les incidents liés aux TIC. Les incidents majeurs doivent être signalés à l’autorité compétente — en France, l’AMF ou l’ACPR — par étapes : une notification initiale, puis un rapport intermédiaire au fil de l’évolution, et un rapport final une fois la cause racine établie. La classification de ce qui constitue un incident « majeur » repose sur des critères fixés par le règlement et ses normes techniques, couvrant notamment le nombre de clients affectés, la durée, l’étendue géographique, les pertes de données et l’impact économique. Les entités peuvent également signaler volontairement des cybermenaces significatives. Avant de signaler, vous classifiez. DORA et ses normes techniques définissent les seuils qui séparent un incident majeur d’un incident courant. Une classification correcte détermine si le délai de signalement s’applique. DORA structure le signalement en trois étapes : notification initiale dans les 4 heures suivant la classification comme majeur, et au plus tard 24 heures après la prise de connaissance ; rapport intermédiaire dans les 72 heures ; rapport final avec analyse des causes dans le mois. Ces délais sont fixés par le RTS 2025/301, avec les modèles de rapport dans l’ITS 2025/302, en vertu de l’article 19 de DORA.

Les tests de pénétration fondés sur les menaces (TLPT, threat-led penetration testing) constituent la forme avancée de tests de résilience que DORA impose aux entités financières identifiées comme significatives. Contrairement aux scans de vulnérabilités ou aux tests de pénétration classiques, le TLPT simule les tactiques, techniques et procédures de véritables acteurs de menace contre les systèmes de production en activité, en couvrant les fonctions critiques ou importantes qui soutiennent l’activité. Il est réalisé par des testeurs externes qualifiés, cadré et validé avec l’autorité compétente — AMF ou ACPR en France — et conduit au moins tous les trois ans. Le TLPT s’appuie sur le cadre TIBER-EU pour les tests fondés sur les menaces. Le TLPT se situe à l’extrémité exigeante du pilier tests de DORA. La plupart des entités concernées mènent un programme général de tests de résilience ; les entités significatives y ajoutent le TLPT, car le règlement considère leur perturbation comme un risque systémique plus élevé. Un test de pénétration standard vérifie si des faiblesses connues peuvent être exploitées. Le TLPT est guidé par le renseignement : il part d’une image des menaces qui ciblent réellement votre type d’entité, puis teste si vos systèmes en production et vos équipes résisteraient à ces comportements adverses spécifiques.

En vertu de l’article 23 de NIS2, les entités essentielles et importantes doivent signaler les incidents significatifs à leur CSIRT national ou à l’autorité compétente par étapes : une alerte précoce dans les 24 heures suivant la prise de connaissance de l’incident, une notification d’incident plus complète dans les 72 heures, et un rapport final dans le mois suivant cette notification. En France, l’ANSSI est l’autorité nationale de cybersécurité chargée de recevoir ces signalements. Un incident est significatif s’il a causé ou est susceptible de causer une perturbation opérationnelle grave ou une perte financière importante, ou s’il a affecté d’autres personnes par des dommages matériels ou immatériels considérables. Ces délais sont fixés à l’article 23(4) de la directive et sont identiques dans chaque État membre. La structure par étapes permet aux autorités d’obtenir un signal rapide, puis une image complète au fil de la résolution. Le délai de signalement ne commence qu’une fois l’incident qualifié de significatif — d’où l’importance d’une classification rapide et exacte, autant que du signalement lui-même. Le signalement est une séquence, et non un dépôt unique : alerte précoce à 24 heures, notification à 72 heures avec une évaluation plus détaillée, rapport final dans le mois couvrant la cause racine et les mesures d’atténuation. Si l’incident est toujours ouvert au bout d’un mois, vous déposez un rapport d’avancement puis un rapport final une fois résolu.