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.

The Trust Services Criteria (TSC) are the standards the AICPA publishes against which an independent CPA firm evaluates a service organization's controls. There are five categories. Security (Common Criteria, CC) is mandatory and appears in every SOC 2 report. The other four — Availability (A), Processing Integrity (PI), Confidentiality (C), and Privacy (P) — are optional: organizations include them where relevant to the services they provide and to what buyers need to see. Most SaaS companies scope Security as the baseline and add Availability when uptime commitments matter to buyers, Confidentiality when enterprise data handling is a selling point, Privacy when the service processes significant personal data, and Processing Integrity for transactional or financial processing. The Common Criteria are further divided into CC1 through CC9. CC6 covers logical and physical access controls — provisioning, authentication, role-based access, and periodic access review. CC7 covers systems operations and monitoring. CC9 covers risk management and vendor risk, including CC9.2, which requires monitoring of third-party providers and the controls they operate on your behalf. CC6 maps closely to ISO 27001 A.5.15–A.5.18; CC9.2 to A.5.19–A.5.23 — organizations running both frameworks reuse this evidence rather than maintaining separate control sets.

A SOC 2 report is the written output of an attestation engagement: an independent CPA firm examines a service organization's controls against the AICPA Trust Services Criteria and issues a formal opinion. The report is a private document — unlike an ISO 27001 certificate, it is not publicly verifiable. It is distributed under NDA to enterprise customers and prospects who request it during vendor due diligence. Procurement and security teams read three things in a SOC 2 report: the auditor's opinion (whether it is unqualified or contains exceptions), the system description (which services and systems were in scope), and the exceptions table (any controls that failed or deviated during the audit period). A narrow scope or a qualified opinion raises questions a buyer will ask about. A Type II report with a clean, unqualified opinion and appropriate scope is the artifact that closes enterprise deals where a vendor security questionnaire alone would not suffice. The report is typically renewed annually — which is why the observation-period cadence is ongoing rather than one-time.

SOC 2 readiness and audit typically take six to eighteen months depending on starting state. The observation period for a Type II report is a minimum of six months — the auditor must see controls operating for at least that long, so the earliest a first-time Type II report is available is roughly six months after controls are operational. Organizations starting from scratch typically spend two to four months on readiness — scoping, control implementation, tooling, and initial evidence collection — before beginning the observation period. That makes the total timeline nine to twelve months for a first-time Type II. Type I moves faster: it is a point-in-time assessment with no observation period, and some organizations use a Type I as a milestone on the way to Type II, getting a report into customers' hands faster while the Type II evidence accumulates. The most common source of delay is not the audit itself but the observation period: controls must run without gaps, and evidence must be collected consistently. Starting continuous evidence collection early — before the formal observation window opens — is the practical way to compress the overall timeline.

SOC 2 and ISO 27001 both address information security controls, but they are architecturally different. ISO 27001 produces a certificate: issued by an accredited certification body, three-year validity, globally recognized, and publicly verifiable. SOC 2 produces an attestation report: issued by a licensed CPA firm, privately distributed, renewed annually, and standard in US enterprise markets. ISO 27001 requires a formal Information Security Management System (ISMS) with documented scope, risk assessment, and a Statement of Applicability for 93 Annex A controls. SOC 2 is organized around the AICPA Trust Services Criteria — Security (CC) is mandatory, the other four categories are optional. The control overlap is significant: CC6 (logical access controls) maps closely to ISO 27001 A.5.15–A.5.18; CC9.2 (vendor monitoring) maps to A.5.19–A.5.23; CC7 (operations) maps to ISO 27001 A.8.x controls. Organizations running both frameworks map once and reuse evidence across both rather than maintaining parallel control sets. The choice depends on where your buyers are. ISO 27001 is the expectation in EU enterprise and global markets. SOC 2 is the US market standard and is frequently required by US enterprise procurement before a contract is signed. Many organizations operating across both markets pursue both.

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.

A Record of Processing Activities (ROPA) is the internal register required by GDPR Article 30 that documents how your organisation processes personal data — purpose, data categories, recipients, transfers outside the EU or EEA, retention periods, and security measures. Controllers and processors must keep one in writing and produce it to a supervisory authority on request. It is the source of truth that a DPIA, a DSAR, a breach assessment, and a transfer assessment all read from. Acuna's data privacy management treats each processing activity as a living record tied to your asset and vendor inventory, so the people closest to the data keep the register honest.

A Data Protection Impact Assessment (DPIA) is mandatory under GDPR Article 35 whenever processing is likely to result in a high risk to the rights and freedoms of individuals. Article 35(3) names three cases that always require one: systematic and extensive profiling with legal effects, large-scale special-category data processing, and systematic monitoring of a publicly accessible area at scale. The EDPB adds nine criteria; two or more typically require a DPIA. Acuna's data privacy management carries a built-in screener against the EDPB criteria on every processing activity, so the question is answered as part of recording the activity, not as a separate project.

Under GDPR Article 33, a controller must notify the competent supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it — unless the breach is unlikely to result in a risk to individuals. Where the breach is likely to result in a high risk, the controller must also notify affected data subjects under Article 34. The clock starts at awareness, not at the conclusion of the investigation; Article 33(4) permits phased notification as facts emerge. Every breach must be documented under Article 33(5) whether or not it meets the notification threshold.

Under GDPR Article 12(3), a controller must respond to a data subject access request without undue delay and within one month of receiving it. The period can be extended by two further months for complex or numerous requests, giving a three-month maximum, provided you notify the individual within the first month and explain the reasons. The legal unit is one month, not 30 days; a month is calculated by the calendar. Acuna's data privacy management tracks each DSAR against a response deadline with a colour-coded countdown, records the one permitted extension with its rationale, and links the request to the processing activities that hold the subject's data.

A Data Processing Agreement (DPA) is the written contract GDPR Article 28 requires whenever a controller engages a processor to handle personal data on its behalf. It must bind the processor to obligations covering the subject matter, duration, nature, and purpose of the processing — plus data subject rights assistance, breach notification, DPIA support, sub-processor controls, and audit access. Without a compliant DPA the processing relationship is unlawful. Acuna's data privacy management generates an Article 28 agreement pre-filled from the processing activity it covers and tracks each agreement through its lifecycle on the matching supplier record in third-party risk management.

A Transfer Impact Assessment (TIA) is the analysis required under GDPR Chapter V before transferring personal data to a country outside the EU or EEA without an adequacy decision. Following Schrems II, relying on Standard Contractual Clauses alone is insufficient: you must assess whether the destination country's law and practice provide essentially equivalent protection and, where it falls short, apply supplementary measures or stop the transfer. Acuna's data privacy management builds the TIA from the cross-border recipients already recorded on a processing activity and defaults to a higher-risk outcome so a transfer has to earn a lower rating rather than be assumed safe.

The DORA register of information is the record, required by Article 28 of Regulation (EU) 2022/2554, of all your contractual arrangements for the use of ICT services provided by third parties. Every financial entity must keep it current, maintain it at entity and, where relevant, sub-consolidated and consolidated group level, and make it available to its competent authority on request. It is the backbone of DORA's third-party risk regime: supervisors use it to see, across the financial sector, which providers the system depends on. The register is not a one-time inventory. It is a living record that has to reflect your ICT supply chain as it actually is, including which arrangements support critical or important functions, because those carry stricter contractual and oversight requirements. That distinction, critical-or-important versus the rest, drives much of what DORA asks of the relationship. The register documents each ICT contractual arrangement: the provider, the service, whether it supports a critical or important function, and the contractual terms DORA requires. The European Supervisory Authorities set the detailed template and fields through technical standards, so the precise columns are defined centrally rather than left to each entity. The register has to be complete and consistent enough that a supervisor can read your ICT dependency map from it. A register maintained as a spreadsheet, separate from the vendor relationships it describes, is accurate the day it is built and wrong the week a contract changes and nobody updates the file. That is the failure mode DORA's "keep it current" requirement is aimed at, and it is why the register cannot be a document you refresh before an inspection.

DORA requires financial entities to detect, manage, classify, and report ICT-related incidents. Major incidents must be reported to the competent authority in stages: an initial notification, followed by an intermediate report as the situation develops, and a final report once the root cause is known. The classification of what counts as "major" is based on criteria set out in the regulation and its technical standards, covering factors such as the number of clients affected, duration, geographic spread, data losses, and economic impact. Entities may also notify significant cyber threats voluntarily. Before you report, you classify. DORA and its technical standards define the thresholds that separate a major incident from a routine one, using materiality factors. Getting classification right matters because it determines whether the reporting clock starts at all. This is where a running incident process earns its place: if you cannot quickly assemble which clients, systems, and data an incident touched, you cannot classify it, let alone report it on time. DORA structures reporting in stages: an initial notification once you determine an incident is major, an intermediate report as handling progresses, and a final report with root-cause analysis. The precise deadlines for each stage are set by the regulatory and implementing technical standards and should be verified against the current published standard before you rely on them.

Threat-led penetration testing (TLPT) is the advanced form of resilience testing that DORA requires of financial entities identified as significant. Unlike routine vulnerability scanning or standard penetration tests, TLPT simulates the tactics, techniques, and procedures of real threat actors against an entity's live production systems, covering the critical or important functions that support its business. It is performed by qualified external testers, scoped and validated with the competent authority, and carried out at least every three years. TLPT draws on the TIBER-EU framework for threat-led testing. TLPT sits at the demanding end of DORA's testing pillar. Most in-scope entities run a general resilience testing programme; significant entities additionally run TLPT, because the regulation treats their disruption as a bigger systemic risk. A standard penetration test checks whether known weaknesses can be exploited. TLPT is intelligence-led: it starts from a picture of the threats that realistically target your kind of entity, then tests whether your live systems and your people would withstand those specific adversary behaviours. It runs against production, not a test environment, which is what makes it a genuine test of operational resilience rather than of a lab setup. TLPT is a structured engagement: scoping the critical or important functions to be tested, developing threat intelligence, running the red-team test against live systems, and producing findings that feed remediation. Tester qualification, scoping, and the outcome are handled with the competent authority.

DORA applies to a broad range of financial entities established in the EU, including credit institutions, payment and electronic money institutions, investment firms, insurance and reinsurance undertakings and intermediaries, crypto-asset service providers, fund managers, trading venues, and more. It also reaches the ICT third-party service providers those entities depend on, and it creates a dedicated oversight regime for providers designated as critical, who become subject to direct supervision by a lead overseer. Scope is deliberately wide, so an EU financial entity should assume it is in scope until it confirms otherwise. DORA is not one-size-fits-all. Smaller and less complex entities apply a simplified version of the ICT risk management framework, calibrated to their scale and risk. Simplified is not exempt: the obligation still applies, at a proportionate depth. The largest and most systemically important entities carry the fullest requirements, including advanced testing. Certain ICT providers, judged critical to the EU financial system, are designated and brought under direct oversight by a lead overseer among the European Supervisory Authorities. This extends supervision to firms that are not themselves financial entities but on which the sector depends. For a financial entity, it means the concentration risk in your ICT supply chain is now a supervisory concern, not only a commercial one, which is exactly why the [third-party risk management](/supplier-shield) register matters.

NIS2 (Directive (EU) 2022/2555) applies to public and private organisations that operate in one of the sectors listed in its annexes and meet a size threshold, generally medium-sized and larger organisations. In-scope organisations are classified as either essential entities or important entities, a distinction that determines the intensity of their supervision and the penalties they face, not whether the obligations apply. Because NIS2 is a directive, the precise scope is set by each member state's national transposition, so the exact boundaries can vary by country. NIS2 splits in-scope organisations into two tiers. Essential entities are the larger organisations in the highest-criticality sectors; important entities are the rest of those in scope. Both tiers must meet the same core risk-management and reporting obligations. The difference is supervisory: essential entities face proactive, ex-ante supervision, while important entities are supervised reactively, ex-post, typically after an incident or evidence of non-compliance. Penalty ceilings also differ between the tiers. NIS2 organises covered sectors into two annexes. Annex I lists sectors of high criticality such as energy, transport, banking, financial market infrastructure, health, drinking and waste water, digital infrastructure, ICT service management, public administration, and space. Annex II lists other critical sectors such as postal and courier services, waste management, chemicals, food, manufacturing of certain products, digital providers, and research. Whether you are essential or important depends on the combination of your sector and your size. As a general rule, NIS2 applies to medium-sized and larger organisations in the covered sectors, using the EU definition of enterprise size. But there are important exceptions where the directive applies regardless of size, for certain types of entity whose disruption would have outsized effect, so the size threshold is a starting point, not a complete test. National transposition can add further specifics. Scope is not a one-time determination. An organisation grows across a threshold, enters a covered sector through an acquisition, or its member state transposes the directive with a wider net than expected. Treating scope as settled is how organisations discover, late, that they were in scope all along.

NIS2 and DORA are two EU frameworks for cybersecurity and operational resilience that came into force around the same time and overlap heavily, but they are not interchangeable. NIS2 (Directive (EU) 2022/2555) is a cross-sector cybersecurity directive covering many industries; DORA (Regulation (EU) 2022/2554) is a finance-specific regulation for digital operational resilience. Where both could apply to the same organisation, DORA generally takes precedence for ICT risk in financial services as the more specific law, the lex specialis principle. A financial entity can therefore be in scope for both, with DORA governing its ICT risk and NIS2 relevant to the extent DORA does not cover. The two differ on instrument, scope, and specificity. NIS2 is a directive, so it is transposed into each member state's national law and its details can vary by country. DORA is a regulation, so it applies directly and uniformly across the EU without transposition. NIS2 spans many sectors; DORA is confined to financial entities and their ICT providers. DORA is also more prescriptive on ICT specifics, such as the register of information and threat-led penetration testing, than NIS2's more general risk-management measures. Where a financial entity would fall under both, DORA is treated as the more specific regime for its ICT risk, and it prevails on the matters it covers. NIS2 recognises this relationship, so the two are designed to fit together rather than duplicate. In practice, a bank manages its ICT risk under DORA and does not also apply NIS2's general measures to the same ground. For a financial entity in scope for both: determine your DORA obligations for ICT risk first, since they are the more specific and prescriptive. Then confirm what, if anything, NIS2 adds beyond DORA's coverage for your organisation, which depends partly on your member state's transposition. The efficient path is to map the shared requirements once, as most of the risk-management and supply-chain substance is common, and only maintain the genuinely distinct pieces separately.

Under Article 23 of NIS2, essential and important entities must report significant incidents to their national CSIRT or competent authority in stages: an early warning shortly after becoming aware of the incident, a fuller incident notification, and a final report once the incident is handled. An incident is significant if it has caused or is capable of causing serious operational disruption or financial loss, or has affected other people through considerable material or non-material damage. Because NIS2 is a directive, the exact deadlines and mechanics are shaped by each member state's transposition, so confirm the specifics against your applicable national law. The staged structure exists so authorities get an early signal quickly, then a complete picture as the situation resolves. The reporting clock only starts once you determine an incident is significant, which is why fast, accurate classification matters as much as the reporting itself. NIS2 sets out when an incident is significant, based on the disruption or loss it causes or could cause, and the harm to others. National transposition and guidance sharpen these thresholds. Classifying correctly is the gate: misjudge it and you either over-report routine events or, worse, miss the clock on a reportable one. Reporting is a sequence, not a single filing: an early warning soon after awareness, a subsequent notification with a fuller assessment, and a final report after the incident is resolved including root cause and mitigation. The precise timeframes are set by Article 23 and national implementation, so verify the current figures for your member state before relying on them.

A NIS2 compliance programme comes down to a handful of things done properly: confirm whether you are in scope and as which tier, put in place the Article 21 risk-management measures, stand up incident detection and staged reporting, address supply chain security, and get the management body to approve and oversee it all. The checklist below covers the core areas any programme must address; it is not a substitute for your member state's transposed requirements, which add the specifics. Determine scope and tier: confirm whether you are in scope, in which Annex I or II sector, and whether you are an essential or an important entity. Register with your authority: meet the registration and information obligations your member state's transposition sets for in-scope entities. Implement the Article 21 measures: put in place the ten categories of risk-management measures, covering risk analysis and security policy, incident handling, business continuity and crisis management, supply chain security, security in acquisition and development, policies to assess effectiveness, basic cyber hygiene and training, cryptography, human resources and access control, and multi-factor authentication and secured communications. Stand up incident reporting: build the detection, classification, and staged reporting process required under Article 23, and know who your CSIRT or competent authority is. Address supply chain security: assess and manage the security of your direct suppliers and service providers, as Article 21 requires. Secure management-body approval and oversight: under Article 20, the management body approves the risk-management measures, oversees them, and can be held liable. Training for management is part of this. Maintain evidence: keep the records that show the measures are real and operating, because supervision, proactive for essential entities, will look for them.

NIS2 is a directive, not a regulation, which means it does not apply directly. Instead, each EU member state must transpose it into national law, and it is that national law you actually comply with. The transposition deadline was 17 October 2024, but member states have transposed at different speeds and with different specifics, so the precise obligations, the designated authority, and some thresholds can vary depending on where you operate. For a multi-country organisation, this is the defining practical feature of NIS2. This is the single biggest difference in character between NIS2 and DORA. DORA, a regulation, is uniform across the EU. NIS2, a directive, is a common baseline that each country implements in its own law, so complying with NIS2 really means complying with the NIS2 transposition in each country where you are in scope. A directive sets the objectives every member state must achieve but leaves the form and method to national governments. That allows NIS2 to fit each country's existing legal and regulatory structures, but it means the operative detail lives in national law. Two organisations in the same sector in different member states can face variations in registration, reporting specifics, and supervisory approach. Member states were required to adopt and publish their transposing measures by 17 October 2024. In practice, transposition has been uneven. Because the position by country changes over time, confirm the current status and the operative national law for each member state where you are in scope rather than relying on a general statement. For a single-country organisation: identify your national transposing law and your competent authority, and comply with that. For a multi-country organisation: map the common NIS2 baseline once, then track the national deltas per member state. The baseline is largely shared; the variation is in the specifics, which is a manageable overlay rather than a separate programme per country.