Cinq référentiels, cinq fois le même travail

Le scénario est presque toujours le même

Vous n'avez pas cinq référentiels. Vous avez cinq fois le même travail.

La plupart des équipes GRC ne manquent pas d'outils. Elles refont, norme après norme, un travail qu'elles ont déjà fait. Et elles le refont sans le voir, parce que rien dans leur organisation ne leur montre qu'il s'agit du même travail.

Vous avez commencé par ISO 27001. Un projet cadré, un responsable, un calendrier, un audit à la clé. Il a pris du temps, il a bien fonctionné.

Puis NIS2 est arrivé. Nouveau périmètre, nouveau vocabulaire, nouveau chantier. On a ouvert un autre fichier.

Entre-temps, un grand client a envoyé son questionnaire sécurité, plusieurs dizaines de questions, à rendre sous trois semaines. Quelqu'un l'a traité dans son coin.

Et la conformité RGPD, elle, vit depuis longtemps de son côté, avec le juridique.

Quatre chantiers. Quatre responsables. Quatre calendriers. Quatre collectes de preuves. Et, entre eux, rien.

Le moment où cela devient visible est presque toujours le même : quelqu'un redemande à l'équipe infrastructure la preuve de la revue des droits d'accès. Pour la troisième fois en six mois. Elle existe déjà. Elle a été fournie deux fois. Personne ne sait où elle a été rangée la dernière fois.

Les mêmes exigences reviennent, sous d'autres mots

Ouvrez deux référentiels côte à côte et regardez ce qu'ils demandent réellement, pas la façon dont ils le formulent. Six familles d'exigences reviennent à peu près partout :

• La gouvernance et l'implication de la direction
• La gestion des identités et des accès
• La journalisation et la supervision
• La continuité d'activité et la reprise
• La sécurité de la chaîne d'approvisionnement
• La gestion des incidents

Prenez une seule d'entre elles, la revue des droits d'accès. ISO 27001 attend une revue périodique des droits. NIS2 range les politiques de contrôle d'accès parmi les mesures de gestion des risques attendues des entités concernées. Le questionnaire de votre client demande qui dispose de droits d'administration et à quelle fréquence la liste est vérifiée. Et votre propre analyse de risque a probablement identifié les comptes à privilèges comme une exposition majeure.

Une seule activité. Quatre demandes. Et, dans la pratique, quatre collectes séparées de la même preuve.

La duplication n'est pas un problème d'outil

C'est le point que l'on manque le plus souvent. On croit régler la duplication en remplaçant les fichiers Excel par une plateforme. Mais si cette plateforme range chaque référentiel dans son propre espace, avec ses propres exigences et ses propres preuves, elle reproduit exactement le même problème avec une meilleure interface.

Ce qui change les choses, c'est le modèle sous-jacent. Il faut que l'exigence, le contrôle, la preuve et le responsable soient des objets distincts, et qu'un même contrôle puisse être rattaché à plusieurs exigences venant de plusieurs référentiels. Sans ce lien, aucune réutilisation n'est possible, quel que soit l'outil. Avec lui, la réutilisation devient l'état par défaut plutôt qu'un effort supplémentaire.

C'est aussi la différence entre un tableau de correspondance figé, utile une fois, périmé six mois plus tard, et un rattachement vivant, qui suit l'état réel du contrôle et de sa preuve.

Le coût réel n'est pas la rédaction, c'est la re-collecte

Rédiger une politique prend du temps, mais on ne la rédige qu'une fois. Ce qui coûte vraiment, c'est de retourner voir l'administrateur système, la DRH, l'hébergeur et le prestataire de sauvegarde chaque fois qu'un nouveau référentiel réclame la même preuve.

Ce coût se paie en heures. Il se paie surtout en crédibilité. Une équipe GRC qui redemande trois fois la même chose en six mois obtient des réponses de plus en plus lentes. Les relances s'allongent, les preuves arrivent en retard, et la préparation d'audit se transforme en négociation interne.

Le problème a commencé bien avant l'audit. Il a commencé le jour où la première preuve n'a été rattachée à rien d'autre qu'à un dossier partagé.

Ce que ça change concrètement

• Une exigence est traitée une fois, puis rattachée à tous les référentiels qu'elle sert
• Une preuve a un propriétaire, une fréquence et une échéance : ce n'est plus un fichier qu'on retrouve, c'est un élément qu'on suit
• Un nouveau référentiel n'est plus un projet qui démarre de zéro : c'est un écart à mesurer par rapport à ce qui existe déjà
• Un écart identifié se referme une fois, et il se referme partout où il apparaissait

Un mot d'honnêteté : tout ne se mutualise pas. Les obligations de notification, les modalités de supervision par les autorités et certaines exigences sectorielles ne se recouvrent pas. Ce sont précisément celles-là qui déterminent votre plan d'action, et il vaut mieux les repérer tôt.

Mais entre « tout est spécifique » et « tout se recouvre », il y a une réalité plus utile : l'essentiel du travail de fond est commun, et c'est cet essentiel que la plupart des organisations refont plusieurs fois.

Dans une prochaine édition

Le Cyber Resilience Act et ses délais de notification : vingt-quatre heures pour signaler une vulnérabilité activement exploitée. Nous regarderons où se trouvent réellement les preuves quand le chronomètre démarre.

Abonnez-vous pour recevoir chaque édition dès sa parution. Et si vous gérez déjà plusieurs référentiels, demandez une démonstration du mapping inter-référentiels d'Incyia : nous partons de votre périmètre réel, pas d'un exemple générique.