La conformité reste à jour, sans reconstruction à chaque audit.

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é.

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.

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.

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.

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 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.

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.

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.