De la liste d’exigences au framework
Au départ, il y a généralement un document : une politique de groupe, une annexe de sécurité au contrat client ou un questionnaire qu’un client envoie chaque année. Ce document devient un framework personnalisé lorsque vous reportez les différentes exigences dans des contrôles.
Il s’est avéré efficace de saisir une exigence par contrôle. Si un paragraphe contient plusieurs obligations, par exemple sur le chiffrement, la journalisation et la conservation, scindez-le. C’est la seule façon de montrer ensuite un état et une preuve propres à chaque obligation. Reprenez la numérotation de la source comme identifiant. Votre client et vous parlez ainsi de la même exigence.
Formulez chaque contrôle comme une question vérifiable. L’obligation d’assurer une sécurité appropriée devient par exemple la question de savoir si les données clients sont chiffrées lors de leur transmission. Clarifiez les exigences ambiguës avec le client avant d’y répondre.
Si la liste d’exigences existe déjà sous forme de tableau, inutile de la ressaisir. Sightadel prend en charge l’import de fichiers Excel et Word. Vérifiez ensuite un par un les points repris quant à leur découpage et leur formulation.
Réutiliser le travail existant
Le principal intérêt d’un framework personnalisé naît de l’association. De nombreuses exigences clients portent sur des choses que vous mettez déjà en œuvre pour ISO 27001, NIS2 ou le RGPD : contrôle d’accès, sauvegarde des données, formation, gestion des incidents, sous-traitance. Les justificatifs se trouvent déjà dans la bibliothèque de preuves.
Parcourez donc d’abord le framework personnalisé en regardant ce qui existe. Lorsqu’une exigence est justifiée par une preuve, associez-la. La preuve est gérée à un seul endroit, et si elle expire, vous le voyez dans tous les frameworks à la fois.
Vérifiez à cette occasion si la preuve satisfait réellement l’exigence du client. Les clients formulent souvent de manière plus stricte ou plus concrète qu’une norme. Si un contrat exige par exemple un délai précis pour informer le client d’un incident, un processus général de traitement des incidents ne suffit pas. Vous complétez alors le processus et la preuve.
Ce qui reste ouvert ensuite, ce sont les véritables écarts. Vous y répondez honnêtement dans l’évaluation et créez des plans d’action. Vous obtenez ainsi une image claire de ce que vous devez faire en plus pour ce client.
Les frameworks personnalisés face aux clients et aux auditeurs
Un framework personnalisé n’est pas une norme donnant lieu à certification. C’est un outil de travail avec lequel vous montrez aux clients, à la société mère ou à votre propre direction dans quelle mesure vous satisfaites certaines exigences.
Lorsqu’un client pose la question, vous montrez pour chacune de ses exigences l’état, la réponse et le justificatif. Pour un audit fournisseur chez le client, c’est une bonne préparation, car la structure suit sa propre liste. Vérifiez au préalable l’absence de contenus confidentiels dans les justificatifs que vous souhaitez transmettre.
Un framework personnalisé peut aussi jouer un rôle lors de l’audit de certification. ISO 27001 exige par exemple de prendre en compte les exigences des parties intéressées, dont font partie les exigences contractuelles des clients. Avec le rôle « Auditeur externe », l’auditeur voit et commente les contenus, y compris les frameworks personnalisés.
Il en va de même pour les référentiels d’audit internes, par exemple une auto-évaluation annuelle des sites. Vous créez l’évaluation avec une personne responsable et une date d’échéance, les participants répondent aux contrôles, et l’avancement est visible à un seul endroit.
Erreurs typiques lors de la création
L’erreur la plus fréquente est un framework personnalisé pour quelque chose qui existe déjà. Avant d’en créer un, consultez la liste des frameworks standard. Sightadel inclut ISO 27001, ISO 9001, ISO 42001, NIS2, RGPD, BSI C5, DORA, NIST CSF 2.0, SOC 2, HACCP, le § 390 du Code social allemand, livre V (SGB V) et l’AI Act (règlement européen sur l’IA).
Une deuxième erreur est un découpage trop grossier. Un contrôle qui regroupe cinq obligations ne peut recevoir qu’une réponse globale. Une partie est satisfaite, une autre non, et la réponse devient floue. Mieux vaut scinder.
Troisièmement, la mise à jour fait souvent défaut. Les exigences clients changent avec chaque nouveau contrat, les exigences du groupe avec chaque nouvelle version. Désignez qui tient le framework à jour et consignez sur quelle version de la source il repose.
Quatrièmement, un framework personnalisé n’a pas de sens pour chaque client. Si les exigences de plusieurs clients se ressemblent fortement, un framework commun reprenant à chaque fois les exigences les plus strictes peut être plus lisible. Le nombre de frameworks personnalisés dépend en outre de votre édition.
