Des réponses directes aux questions GRC.

ISO 27001 est la norme internationale pour les systèmes de management de la sécurité de l’information (SMSI). Publiée par l’ISO/IEC, elle définit les exigences pour l’établissement, la mise en œuvre, le maintien et l’amélioration continue d’un SMSI. La révision 2022 inclut 93 contrôles répartis sur quatre thèmes : organisationnel, humain, physique et technologique. La certification requiert un audit externe accrédité démontrant que le SMSI répond à toutes les exigences des clauses et que les contrôles de l’Annexe A sélectionnés sont mis en œuvre et efficaces. Acuna prend en charge l’intégralité du cycle de vie ISO 27001, de la définition du périmètre à la préparation des audits.

NIS2 (Directive (UE) 2022/2555) est la directive européenne sur la cybersécurité pour les entités essentielles et importantes. Elle étend le périmètre de NIS1, introduit des exigences de sécurité renforcées en vertu de l’article 21, et impose le signalement des incidents dans les 24 heures (alerte précoce), 72 heures (notification) et un mois (rapport final). Les entités essentielles comprennent l’énergie, les transports, le secteur bancaire, la santé, l’eau et l’infrastructure numérique. Les entités importantes couvrent les services postaux, la gestion des déchets, la chimie, l’alimentation, l’industrie manufacturière et les fournisseurs numériques comptant 50 employés ou plus, ou un chiffre d’affaires de 10 millions d’euros ou plus. Acuna cartographie les articles NIS2 sur les contrôles, gère le risque de la chaîne d’approvisionnement et suit les délais de signalement des incidents.

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.

La GRC (Gouvernance, Risques et Conformité) est une discipline de management large couvrant la manière dont une organisation dirige sa stratégie, gère ses risques et respecte ses obligations réglementaires dans tous les domaines. Un SMSI (Système de management de la sécurité de l’information) est une mise en œuvre spécifique de la gouvernance et de la gestion des risques centrée sur la sécurité de l’information, se conformant généralement à ISO 27001. Un SMSI est une composante d’un programme GRC plus large. Acuna est une plateforme GRC qui prend en charge la gestion d’un SMSI comme l’un de ses cas d’usage, aux côtés de la protection des données, de la continuité d’activité, du risque fournisseur et de la gestion des risques d’entreprise.

La cartographie de contrôles inter-référentiels identifie les points de recoupement entre les exigences de différents référentiels. Par exemple, ISO 27001 A.8.5 (contrôle d’accès) et NIS2 article 21(2)(i) (gestion des accès) décrivent essentiellement la même pratique. En cartographiant ces recoupements, les organisations mettent en œuvre et prouvent un contrôle une seule fois au lieu de dupliquer l’effort par référentiel. Dans Acuna, les cartographies peuvent être directes (manuelles), dérivées via 58 mesures de référence organisées en 11 domaines, ou suggérées par l’IA avec des scores de confiance. La cartographie par lot permet d’aligner des domaines entiers en une seule opération.

La Déclaration d’applicabilité (DdA) est un document obligatoire dans ISO 27001 qui liste tous les contrôles de l’Annexe A, indique si chacun est applicable ou non applicable au périmètre du SMSI de l’organisation, fournit une justification pour les exclusions, et référence le statut de mise en œuvre de chaque contrôle applicable. La DdA est un artefact clé de l’audit : les auditeurs l’utilisent pour vérifier que la sélection des contrôles est fondée sur les risques et que les contrôles exclus disposent d’une justification documentée. Dans Acuna, la DdA est gérée directement dans le volet Comply avec les marquages d’applicabilité et les champs de justification par contrôle.

Une Analyse d’impact relative à la protection des données (AIPD) est requise en vertu de l’article 35 du RGPD lorsque le traitement est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes. Cela inclut le profilage systématique avec des effets juridiques, le traitement à grande échelle de catégories particulières de données et la surveillance systématique d’espaces publics. Une AIPD doit décrire le traitement, évaluer la nécessité et la proportionnalité, identifier les risques et définir les mesures d’atténuation. Si le risque résiduel reste élevé après atténuation, le responsable du traitement doit consulter l’autorité de contrôle en vertu de l’article 36. Les workflows AIPD figurent sur la feuille de route du module Protection des données d’Acuna ; actuellement, les activités de traitement peuvent être documentées et reliées aux contrôles et aux actifs pour préparer les AIPD.

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.

Les critères de services fiduciaires (Trust Services Criteria, TSC) sont les référentiels publiés par l’AICPA sur lesquels un cabinet d’experts-comptables indépendant évalue les contrôles d’une organisation de services. Il existe cinq catégories. La Sécurité (critères communs, CC) est obligatoire et figure dans tout rapport SOC 2. Les quatre autres — Disponibilité (A), Intégrité du traitement (PI), Confidentialité (C) et Vie privée (P) — sont optionnelles : les organisations les incluent lorsqu’elles sont pertinentes pour les services fournis et pour ce que les acheteurs attendent. La plupart des éditeurs SaaS retiennent la Sécurité comme socle et ajoutent la Disponibilité lorsque les engagements de disponibilité comptent pour les acheteurs, la Confidentialité lorsque le traitement des données d’entreprise est un argument commercial, la Vie privée lorsque le service traite des données personnelles en volume, et l’Intégrité du traitement pour les flux transactionnels ou financiers. Les critères communs sont subdivisés en CC1 à CC9. CC6 couvre les contrôles d’accès logiques et physiques — provisionnement, authentification, accès par rôles et revue périodique des droits. CC7 couvre les opérations et la surveillance des systèmes. CC9 couvre la gestion des risques et le risque fournisseur, dont CC9.2, qui exige le suivi des prestataires tiers et des contrôles qu’ils opèrent pour votre compte. CC6 recoupe étroitement ISO 27001 A.5.15–A.5.18 ; CC9.2, A.5.19–A.5.23 — les organisations qui courent les deux référentiels réutilisent ces preuves plutôt que de maintenir des jeux de contrôles distincts.

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.

SOC 2 et ISO 27001 traitent tous deux des contrôles de sécurité de l’information, mais leur architecture diffère. ISO 27001 produit un certificat : délivré par un organisme de certification accrédité, valable trois ans, reconnu mondialement et vérifiable publiquement. SOC 2 produit un rapport d’attestation : émis par un cabinet d’experts-comptables agréé, distribué de manière privée, renouvelé chaque année, et devenu la norme sur le marché entreprise américain. ISO 27001 exige un SMSI formel avec un périmètre documenté, une analyse des risques et une Déclaration d’applicabilité pour les 93 contrôles de l’Annexe A. SOC 2 s’organise autour des critères de services fiduciaires de l’AICPA — la Sécurité (CC) est obligatoire, les quatre autres catégories sont optionnelles. Le recoupement des contrôles est important : CC6 (contrôles d’accès logiques) recoupe ISO 27001 A.5.15–A.5.18 ; CC9.2 (suivi des fournisseurs), A.5.19–A.5.23 ; CC7 (opérations), les contrôles ISO 27001 A.8.x. Les organisations qui courent les deux référentiels cartographient une fois et réutilisent les preuves plutôt que de maintenir des jeux parallèles. Le choix dépend de vos acheteurs. ISO 27001 est l’attente sur le marché entreprise européen et international. SOC 2 est la norme du marché américain et est fréquemment exigé par les services achats d’entreprises américaines avant signature. De nombreuses organisations actives sur les deux marchés — dont des sociétés françaises visant l’accès au marché américain — poursuivent les deux démarches.

Supplier Shield est le logiciel de gestion des risques tiers (TPRM) d’Acuna. Il vous offre un registre de fournisseurs noté, une note de sécurité externe actualisée chaque jour pour chaque fournisseur, des campagnes d’évaluation assistées par IA qu’un évaluateur humain valide, un portail fournisseur pour les réponses externes, et un journal d’activité inviolable qui sert de preuve d’audit pour DORA, NIS2 et ISO 27001. Les fournisseurs sont notés selon trois dimensions, la dépendance, l’intégration et l’impact, qui se combinent en un seul niveau de risque à code couleur. C’est un module de la plateforme GRC Acuna, hébergée en Suisse, qui couvre plus de 50 référentiels, de sorte que les preuves recueillies ici sont réutilisables dans l’ensemble de votre programme de conformité.

Dans Acuna, une mesure est une pratique de niveau modèle tirée de bibliothèques organisées selon des référentiels tels qu’ISO 27001 et NIST CSF. Elle décrit ce qui doit être fait. Un contrôle est l’enregistrement opérationnel que vous créez à partir d’une mesure : typé (préventif, détectif ou correctif), doté d’un responsable, d’un statut, et relié à des exigences, actifs, processus et risques spécifiques. Vous mettez en œuvre et attestez au niveau du contrôle ; les mesures standardisent la pratique sous-jacente dans l’ensemble de votre programme. Une mesure peut générer plusieurs contrôles dans différents périmètres.

Chaque contrôle dans Acuna affiche un badge de santé codé par couleur : vert (sain), orange (à risque) ou rouge (défaillant). La santé est principalement déterminée par la complétion des tâches récurrentes : une tâche complétée à temps score 100 (sain), complétée en retard score 75 (à risque), en cours sans échéance dépassée score 75, et non démarrée après l’échéance score 0 (défaillant). Ces scores remontent en cascade à travers les mesures et les exigences, de sorte que les glissements opérationnels apparaissent dans les vues de contrôle et de programme, et non uniquement dans une liste de tâches. Cliquez sur n’importe quel badge de santé pour obtenir une décomposition expliquant quelles tâches ont contribué au score actuel.

Aiko est l’assistant IA intégré d’Acuna, accessible depuis chaque page via l’icône Aiko flottante. Il aide pour les questions de conformité sur les exigences des référentiels et les approches de contrôle, les guides de navigation avec des liens internes vers les pages pertinentes, les synthèses de statut de la posture de conformité et des tâches en attente, et l’identification des lacunes là où les exigences manquent de mesures ou de contrôles reliés. Aiko utilise le même budget de tokens affiché sur le tableau de bord Admin → Agents IA, et toutes les conversations sont contextuelles, la date actuelle étant incluse pour les conseils sensibles au temps.

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.

Comply est l’endroit où vous gérez les référentiels, les exigences et l’applicabilité. Vous importez ou créez des référentiels réglementaires (ISO 27001, NIS2, DORA, SOC 2, RGPD et autres), examinez chaque exigence, marquez l’applicabilité avec justification, et établissez des cartographies inter-référentiels afin que les exigences qui se recoupent partagent les mêmes mesures et contrôles. Le volet affiche une posture de conformité en temps réel par référentiel : pourcentage de couverture, nombre de lacunes et statut au niveau des exigences, afin que les responsables conformité et les auditeurs voient l’état du programme sans ouvrir de tableurs.

Dans Comply, chaque exigence peut être marquée Applicable ou Non applicable avec un champ de justification obligatoire. Pour ISO 27001, cela produit la Déclaration d’applicabilité (DdA). Les décisions d’applicabilité se propagent en aval : lorsqu’une exigence est marquée non applicable, ses mesures et contrôles reliés sont exclus des calculs de couverture. Les auditeurs peuvent filtrer la liste des exigences par statut d’applicabilité et exporter la DdA comme artefact versionné. Les modifications d’applicabilité après le marquage initial sont tracées dans la piste d’audit avec l’utilisateur, l’horodatage et la raison du changement.

Implement est l’endroit où vous construisez l’ossature opérationnelle de votre programme de conformité. Vous créez des mesures à partir de bibliothèques organisées ou de définitions personnalisées, instanciez des contrôles à partir de ces mesures, assignez des responsables, définissez des statuts et reliez les contrôles aux exigences qu’ils satisfont. Le volet gère également votre inventaire d’actifs (systèmes informatiques, espaces de données, emplacements physiques), le registre des processus et le catalogue des risques. Tout est connecté : un contrôle est relié à une ou plusieurs exigences, à un ou plusieurs actifs, et éventuellement à des risques, permettant de tracer depuis une clause du référentiel jusqu’au système et à l’équipe spécifiques responsables.

Dans Implement, chaque mesure représente une pratique de sécurité ou de conformité (ex. : « Les revues d’accès sont effectuées trimestriellement »). Les mesures sont reliées en amont à une ou plusieurs exigences à travers les référentiels : une mesure peut satisfaire simultanément des clauses d’ISO 27001, de NIS2 et de SOC 2. Les contrôles sont les instances opérationnelles des mesures : ils portent un responsable, un statut de mise en œuvre, un type de contrôle (préventif, détectif, correctif) et des preuves reliées. Cette hiérarchie à trois niveaux (exigence, mesure, contrôle) est la manière dont Acuna évite le travail dupliqué dans les programmes multi-référentiels.

Operate est la couche d’exécution au quotidien. Il gère les tâches récurrentes (avec des fréquences et des responsables configurables), les objectifs et les KPI, le suivi des incidents et les registres de tiers. Les tâches pilotent la santé des contrôles : lorsqu’une tâche récurrente est complétée à temps, le contrôle relié reste vert ; lorsqu’elle glisse, le contrôle passe à l’orange ou au rouge, et ce statut remonte en cascade jusqu’à la mesure et l’exigence. Operate héberge également le tableau de bord KPI avec des sources de données manuelles, calculées, par connecteur et par webhook, offrant à la direction une visibilité en temps réel sur les performances du programme.

Chaque contrôle peut avoir une ou plusieurs tâches récurrentes, par exemple « Revoir les droits d’accès trimestriellement » ou « Tester la restauration des sauvegardes mensuellement ». Les tâches se voient affecter un responsable, une fréquence (quotidienne, hebdomadaire, mensuelle, trimestrielle, annuelle ou personnalisée) et une date d’échéance. Une tâche complétée à temps score 100 (sain). Complétée en retard score 75 (à risque). En cours sans dépassement score 75. Non démarrée après l’échéance score 0 (défaillant). Ces scores remontent au contrôle parent, puis à la mesure, puis à l’exigence : une tâche manquée apparaît ainsi comme une lacune visible à chaque niveau du programme.

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.

Acuna attribue à chaque fournisseur une note de sécurité de A à F, calculée à partir de son exposition publique, et l’actualise chaque jour, sans aucune action de la part du fournisseur ni de votre équipe. Il s’agit d’OSINT, le renseignement en sources ouvertes : un signal externe, tiré entièrement de l’empreinte publique du fournisseur, que vous confrontez à ce qu’il déclare dans son questionnaire. La note OSINT reflète cinq domaines : la sécurité du domaine et de la messagerie, le chiffrement, la sécurité web, l’exposition aux fuites de données et la réputation. Vous pouvez ouvrir chaque note pour en voir le détail. Cette note figure aux côtés du niveau de risque à trois dimensions (dépendance, intégration, impact) sur le profil du fournisseur.

L’Analyse d’impact sur l’activité (AIA) dans Acuna évalue chaque processus métier selon des dimensions d’impact configurables : financier, réglementaire, réputationnel et dépendance opérationnelle. Chaque dimension est notée sur une échelle cohérente, et un score de criticité composite est calculé automatiquement. Le score oriente la priorisation : les processus les plus critiques reçoivent en premier leurs cibles RTO/RPO/DMTA, et les comités de résilience disposent d’une liste de priorités classée. Les résultats de l’AIA alimentent les tableaux de bord de direction, se connectent aux plans de reprise et sont reliés aux dépendances en termes d’actifs et de fournisseurs qui soutiennent chaque processus.

Le RTO (Objectif de délai de reprise) définit le délai dans lequel un processus doit être restauré après une perturbation. Le RPO (Objectif de point de reprise) définit la perte de données acceptable, mesurée en temps. La DMTA (Durée maximale tolérable d’absence) définit la durée maximale absolue pendant laquelle un processus peut être indisponible avant que l’impact ne devienne inacceptable pour l’organisation. Dans Acuna, les trois sont enregistrés par processus et reliés à l’unité métier responsable. La plateforme signale les incohérences, par exemple un RPO qui dépasse la DMTA, et compare les cibles aux capacités de reprise réelles lors des exercices.

Risques d’entreprise dans Acuna fournit un registre des risques structuré où chaque risque est évalué sur la probabilité et l’impact selon des dimensions configurables (financier, opérationnel, réputationnel, réglementaire). Les risques sont reliés aux contrôles, actifs, processus et responsables. Le module prend en charge les plans de traitement des risques (atténuer, accepter, transférer, éviter) avec suivi des actions, recalcul du risque résiduel après la mise en œuvre des contrôles, et visualisation par carte de chaleur pour le reporting de direction. Les données de risques s’intègrent avec les autres modules : un fournisseur à risque élevé dans Supplier Shield ou un contrôle défaillant dans Implement remonte automatiquement comme événement de risque.

Un plan de traitement des risques documente la manière dont une organisation traite les risques identifiés. Quatre options standards existent : atténuer (mettre en œuvre des contrôles pour réduire la probabilité ou l’impact), accepter (reconnaître le risque avec une validation formelle), transférer (déplacer le risque vers un tiers via une assurance ou une externalisation) et éviter (éliminer l’activité qui crée le risque). Dans Acuna, chaque option de traitement est suivie avec un responsable, une date d’échéance, des contrôles reliés et un statut d’avancement. Une fois les actions de traitement terminées, le risque résiduel est recalculé et le registre des risques se met à jour automatiquement, offrant aux auditeurs une piste claire avant/après.

Le module Protection des données fournit un registre de confidentialité opérationnel centré sur les activités de traitement (registre article 30 du RGPD). Un assistant guidé en 7 étapes couvre la finalité, la base juridique, les personnes concernées, les catégories de données, la conservation et les transferts, avec un flux de travail en quatre états (Brouillon, En revue, Approuvé, À mettre à jour). Les activités sont reliées aux actifs via un inventaire de données avec des grilles de données personnelles, aux tiers avec le statut de l’accord de traitement des données (ATD) et le suivi des pays de transfert, et aux référentiels (RGPD et LPD suisse préconfigurés). Un diagramme de flux de données interactif visualise la circulation des données personnelles au sein de l’organisation. Un tableau de bord de confidentialité affiche la distribution des statuts des activités de traitement, la couverture de l’inventaire, la complétude des ATD et les affectations de référentiels. Le module prend également en charge la migration structurée depuis OneTrust.

Vanta est conçu pour les entreprises qui obtiennent leur première certification SOC 2. Pour les organisations gérant simultanément plusieurs référentiels (ISO 27001, SOC 2, NIS2, DORA, RGPD), les origines mono-référentiel de Vanta montrent leurs limites. Les meilleures alternatives à Vanta pour les programmes multi-référentiels sont des plateformes conçues pour la conformité continue sur des obligations matures et interdependantes. Acuna est conçu dès le départ pour la cartographie de contrôles multi-référentiels, les preuves partagées et une piste défendable à l’échelle de l’entreprise. Drata et OneTrust traitent chacun des problèmes adjacents. Choisissez en fonction de si votre programme consiste à approfondir la conformité ou à décrocher votre première certification.

OneTrust se positionne comme une plateforme d’entreprise centrée sur la confidentialité, la plus solide pour les organisations où la protection des données (RGPD, CCPA) est au cœur du programme GRC. Les meilleures alternatives à OneTrust pour plus de profondeur GRC sont des plateformes qui intègrent protection des données, sécurité, qualité et programmes d’audit dans un rythme opérationnel unique plutôt que dans des silos parallèles. Acuna est conçu pour les responsables conformité gérant des programmes multi-référentiels où la protection des données est l’une des obligations parmi d’autres (ISO 27001, SOC 2, NIS2, ISO 9001, RGPD). La tarification est basée sur l’organisation et non par siège, et l’architecture prend en charge la qualité, la confidentialité et la sécurité dans des preuves partagées.

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 calendrier de conformité est une vue structurée de chaque revue, audit, évaluation, renouvellement et délai réglementaire qu’un programme de conformité doit respecter. Les organisations gérant plusieurs référentiels (ISO 27001, SOC 2, RGPD, NIS2) font face à des dizaines d’obligations récurrentes par an, des audits internes trimestriels aux audits de surveillance annuels en passant par les revues des fournisseurs. Un logiciel de calendrier de conformité consolide ces obligations dans une vue unique, suit la responsabilité et signale ce qui est en retard. Sans cela, les délais vivent dans Outlook et dans des tableurs, rendant les obligations manquées fréquentes. Dans Acuna, le calendrier couvre chaque référentiel, chaque cycle, chaque responsable, avec des alertes avant les échéances.

Le Registre des Activités de Traitement (RAT, ou ROPA en anglais) est le registre interne exigé par l’article 30 du RGPD. Il documente comment votre organisation traite des données personnelles : finalités, catégories de données, destinataires, transferts hors UE ou EEE, durées de conservation et mesures de sécurité. Responsables de traitement et sous-traitants doivent le tenir par écrit et le présenter à l’autorité de contrôle sur demande — en France, la CNIL. C’est la source de vérité dont une AIPD, une demande d’accès, une évaluation de violation et une analyse de transfert tirent leurs informations. La gestion de la confidentialité d’Acuna traite chaque activité de traitement comme un enregistrement vivant relié à votre inventaire d’actifs et de fournisseurs, afin que les personnes les plus proches des données maintiennent le registre à jour.

L’Analyse d’Impact relative à la Protection des Données (AIPD) est obligatoire en vertu de l’article 35 du RGPD lorsque le traitement est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes. L’article 35(3) cite trois cas qui en exigent toujours une : le profilage systématique et étendu produisant des effets juridiques, le traitement à grande échelle de données sensibles, et la surveillance systématique à grande échelle d’une zone accessible au public. Le Comité européen de la protection des données (CEPD) ajoute neuf critères ; en cumuler deux ou plus impose en principe une AIPD. La gestion de la confidentialité d’Acuna intègre un filtre automatique sur ces critères CEPD pour chaque activité de traitement, de sorte que la question est tranchée lors de l’enregistrement de l’activité, et non dans un projet séparé.

En vertu de l’article 33 du RGPD, le responsable de traitement doit notifier la violation de données personnelles à l’autorité de contrôle compétente — en France, la CNIL — dans les meilleurs délais et, si possible, dans les 72 heures après en avoir pris connaissance, sauf si la violation est peu susceptible d’engendrer un risque pour les personnes. Lorsque la violation est susceptible d’engendrer un risque élevé, le responsable doit également informer les personnes concernées en vertu de l’article 34. Le délai court à partir de la prise de connaissance, et non de la fin de l’investigation ; l’article 33(4) autorise une notification par étapes au fur et à mesure que les faits se précisent. Toute violation doit être documentée en vertu de l’article 33(5), qu’elle atteigne ou non le seuil de notification.

En vertu de l’article 12(3) du RGPD, le responsable de traitement doit répondre à une demande d’accès aux données personnelles (DSAD) dans les meilleurs délais et au plus tard dans un délai d’un mois à compter de sa réception. Ce délai peut être prolongé de deux mois supplémentaires pour des demandes complexes ou nombreuses, soit un maximum de trois mois, à condition d’informer la personne dans le premier mois et d’en exposer les motifs. L’unité juridique est le mois civil, et non 30 jours. La gestion de la confidentialité d’Acuna suit chaque DSAD par rapport à une échéance de réponse avec un compte à rebours codé par couleur, enregistre la prolongation autorisée avec sa justification, et relie la demande aux activités de traitement qui détiennent les données de la personne.

L’Accord de traitement des données (ATD, ou contrat sous-traitant) est le contrat écrit que l’article 28 du RGPD exige dès qu’un responsable de traitement fait appel à un sous-traitant pour traiter des données personnelles pour son compte. Il doit lier le sous-traitant à des obligations couvrant l’objet, la durée, la nature et la finalité du traitement — ainsi que l’assistance aux droits des personnes, la notification des violations, le soutien aux AIPD, les contrôles sur les sous-traitants ultérieurs et l’accès à l’audit. Sans ATD conforme, la relation de traitement est illicite. La gestion de la confidentialité d’Acuna génère un accord article 28 prérempli à partir de l’activité de traitement couverte et suit chaque ATD tout au long de son cycle de vie sur la fiche fournisseur correspondante dans la gestion des risques tiers.

L’Analyse d’impact sur le transfert (AIT) est l’évaluation exigée par le chapitre V du RGPD avant de transférer des données personnelles vers un pays hors UE ou EEE ne bénéficiant pas d’une décision d’adéquation. Depuis l’arrêt Schrems II de la CJUE, s’appuyer sur les seules clauses contractuelles types ne suffit pas : vous devez évaluer si le droit et la pratique du pays de destination offrent une protection essentiellement équivalente et, en cas de lacune, appliquer des mesures supplémentaires ou interrompre le transfert. La gestion de la confidentialité d’Acuna construit l’AIT à partir des destinataires transfrontaliers déjà enregistrés sur une activité de traitement et part du principe d’un risque plus élevé, de sorte qu’un transfert doit mériter une notation plus faible plutôt qu’être présumé sans risque.

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.

DORA s’applique à un large éventail d’entités financières établies dans l’UE, dont les établissements de crédit, les établissements de paiement et de monnaie électronique, les entreprises d’investissement, les entreprises d’assurance et de réassurance et leurs intermédiaires, les prestataires de services sur crypto-actifs, les sociétés de gestion de fonds, les plates-formes de négociation, et d’autres encore. Il atteint également les prestataires de services TIC tiers dont ces entités dépendent, et crée un régime de supervision dédié pour les prestataires désignés comme critiques, soumis à une supervision directe par un superviseur principal. Le périmètre est volontairement large : une entité financière française devrait présumer qu’elle est concernée jusqu’à preuve du contraire. DORA est applicable depuis le 17 janvier 2025, sous la supervision de l’AMF et de l’ACPR selon le type d’entité. DORA n’est pas uniforme pour tous. Les entités plus petites et moins complexes appliquent une version simplifiée du cadre de gestion des risques TIC, calibrée à leur taille et à leur risque. Simplifié ne signifie pas exempt : l’obligation subsiste, à une profondeur proportionnée. Les entités les plus grandes et les plus systémiques portent l’intégralité des exigences, y compris les tests avancés.

NIS2 (Directive (UE) 2022/2555) s’applique aux organisations publiques et privées qui exercent leur activité dans l’un des secteurs listés dans ses annexes et qui atteignent un seuil de taille, en général les organisations de taille moyenne et supérieure. Les organisations concernées sont classées en entités essentielles ou entités importantes — distinction qui détermine l’intensité de la supervision et le niveau des sanctions, et non l’existence des obligations. Comme NIS2 est une directive, le périmètre précis est fixé par la transposition nationale de chaque État membre. En France, la directive a été transposée par la loi de programmation militaire (LPM) et la loi organique relative à la LPM (LOPMI), avec l’ANSSI comme autorité nationale de cybersécurité. NIS2 distingue deux niveaux. Les entités essentielles sont les plus grandes organisations des secteurs à criticité maximale ; les entités importantes, le reste du périmètre. Les deux niveaux doivent respecter les mêmes obligations fondamentales de gestion des risques et de signalement. La différence porte sur la supervision : les entités essentielles font l’objet d’une supervision proactive ex ante, les entités importantes d’une supervision réactive ex post, généralement après un incident ou des signes de non-conformité. NIS2 organise les secteurs couverts en deux annexes. L’annexe I liste les secteurs à haute criticité : énergie, transports, banque, infrastructures des marchés financiers, santé, eau potable et eaux usées, infrastructure numérique, gestion des services TIC, administration publique et espace. L’annexe II couvre d’autres secteurs critiques : services postaux et de courrier, gestion des déchets, produits chimiques, alimentation, fabrication de certains produits, fournisseurs numériques et recherche.

NIS2 et DORA sont deux cadres européens de cybersécurité et de résilience opérationnelle entrés en vigueur à peu près au même moment et qui se recoupent largement, mais ils ne sont pas interchangeables. NIS2 (Directive (UE) 2022/2555) est une directive transsectorielle de cybersécurité couvrant de nombreux secteurs ; DORA (Règlement (UE) 2022/2554) est un règlement spécifique au secteur financier pour la résilience opérationnelle numérique. Lorsque les deux pourraient s’appliquer à la même organisation, DORA prime généralement pour le risque TIC dans les services financiers en tant que loi plus spécifique — le principe de lex specialis. Une entité financière peut donc être dans le périmètre des deux, DORA régissant son risque TIC et NIS2 restant pertinent dans la mesure où DORA ne couvre pas. Les deux diffèrent par l’instrument, le périmètre et le niveau de précision. NIS2 est une directive transposée en droit national — en France via la LPM et la LOPMI, sous la supervision de l’ANSSI. DORA est un règlement d’application directe et uniforme dans l’UE, supervisé par l’AMF et l’ACPR pour les entités françaises. NIS2 couvre de nombreux secteurs ; DORA se limite aux entités financières et à leurs prestataires TIC. DORA est aussi plus prescriptif sur les détails TIC — registre d’informations, TLPT — que les mesures plus générales de gestion des risques de NIS2. Pour une entité financière concernée par les deux : déterminez d’abord vos obligations DORA pour le risque TIC, car elles sont les plus spécifiques et prescriptives. Puis vérifiez ce que NIS2 ajoute au-delà de la couverture DORA pour votre organisation.

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.

Un programme de conformité NIS2 se résume à quelques éléments bien exécutés : confirmer si vous êtes dans le périmètre et à quel niveau, mettre en place les mesures de gestion des risques de l’article 21, organiser la détection et le signalement par étapes des incidents, traiter la sécurité de la chaîne d’approvisionnement, et obtenir l’approbation et la supervision de l’organe de direction. La checklist ci-dessous couvre les domaines essentiels ; elle ne remplace pas les exigences transposées en droit français via la LPM et la LOPMI, qui ajoutent les spécificités nationales. Déterminer le périmètre et le niveau : confirmer si vous êtes concerné, dans quel secteur des annexes I ou II, et si vous êtes une entité essentielle ou importante. S’enregistrer auprès de l’autorité : respecter les obligations d’enregistrement et d’information fixées par la transposition française, auprès de l’ANSSI. Mettre en œuvre les mesures de l’article 21 : déployer les dix catégories de mesures de gestion des risques — analyse des risques et politique de sécurité, gestion des incidents, continuité d’activité et gestion de crise, sécurité de la chaîne d’approvisionnement, sécurité dans l’acquisition et le développement, politiques d’évaluation de l’efficacité, cyberhygiène de base et formation, cryptographie, ressources humaines et contrôle d’accès, authentification multifacteur et communications sécurisées. Organiser le signalement des incidents : construire le processus de détection, classification et signalement par étapes exigé par l’article 23, et identifier votre CSIRT ou autorité compétente. Traiter la sécurité de la chaîne d’approvisionnement : évaluer et gérer la sécurité de vos fournisseurs et prestataires directs, comme l’exige l’article 21. Obtenir l’approbation de l’organe de direction : en vertu de l’article 20, l’organe de direction approuve les mesures de gestion des risques, les supervise et peut être tenu responsable.

NIS2 est une directive, et non un règlement, ce qui signifie qu’elle ne s’applique pas directement. Chaque État membre de l’UE doit la transposer en droit national, et c’est ce droit national que vous respectez réellement. Le délai de transposition était fixé au 17 octobre 2024, mais les États membres ont transposé à des rythmes et avec des spécificités différents. En France, la transposition s’est opérée via la loi de programmation militaire (LPM) et la loi organique relative à la LPM (LOPMI), avec l’ANSSI comme autorité nationale de cybersécurité. Pour une organisation multi-pays, cette variation nationale est la caractéristique pratique déterminante de NIS2. C’est la différence de nature la plus marquante entre NIS2 et DORA. DORA, en tant que règlement, est uniforme dans toute l’UE et supervisé par l’AMF et l’ACPR pour les entités financières françaises. NIS2, en tant que directive, constitue un socle commun que chaque pays met en œuvre dans sa propre législation. Une directive fixe les objectifs que chaque État membre doit atteindre, mais laisse la forme et les modalités aux gouvernements nationaux. Deux organisations du même secteur dans des États membres différents peuvent faire face à des variations en matière d’enregistrement, de modalités de signalement et d’approche de supervision. Pour une organisation mono-pays en France : identifiez la loi de transposition nationale et l’ANSSI comme autorité compétente, et conformez-vous à ce droit. Pour une organisation multi-pays : cartographiez le socle commun NIS2 une fois, puis suivez les écarts nationaux par État membre.