SoA Déclaration d'applicabilité.

Pourquoi ISO 27001 rend le SoA obligatoire

La déclaration d'applicabilité est le pont entre votre travail sur les risques et les mesures qu'un auditeur inspectera réellement. ISO/IEC 27001 laisse délibérément le corps de la norme ouvert sur les mesures que vous devez mettre en œuvre, car la bonne réponse dépend de votre contexte et de vos risques. Le SoA est l'endroit où vous comblez cet écart : pour chaque mesure de référence de l'Annexe A, vous consignez si elle s'applique, la justification de son inclusion ou de son exclusion, si elle est déjà mise en œuvre et où se trouvent les preuves associées. C'est l'un des rares documents que la norme désigne explicitement comme un livrable requis, raison pour laquelle aucun audit de certification ne se déroule sans lui.

Une manière utile d'y penser est que le SoA transforme un catalogue de mesures générique en une déclaration portant spécifiquement sur votre organisation. L'ensemble de référence de l'Annexe A est le même pour tout le monde. Votre SoA, lui, ne l'est pas. Deux entreprises certifiées de taille comparable peuvent légitimement exclure des mesures différentes, parce que leurs appréciations des risques et leur contexte d'exploitation diffèrent. Le document existe pour rendre ces choix visibles et défendables plutôt qu'implicites.

Comment le SoA s'articule avec l'appréciation des risques et le traitement des risques

Le SoA n'existe pas isolément. Il est le produit en aval de l'appréciation des risques et du plan de traitement des risques, et les trois doivent concorder. L'appréciation des risques identifie ce qui pourrait mal tourner. Le plan de traitement des risques décide de ce qu'il faut faire pour chaque risque, y compris quelles mesures appliquer. Le SoA déclare ensuite, mesure par mesure, ce que cette décision signifie au regard de l'ensemble de référence de l'Annexe A. Lorsqu'un auditeur lit le SoA, il vérifie en réalité que la chaîne allant d'un risque documenté à une décision de traitement, puis à une mesure appliquée, puis à des preuves concrètes, tient de bout en bout.

Les exclusions méritent une attention particulière. Marquer une mesure comme non applicable est légitime, mais uniquement avec un motif énoncé et lié à votre contexte. « Nous ne développons pas de logiciels en interne » est une base défendable pour restreindre certaines mesures de développement. « Nous n'avons pas eu le temps de nous en occuper » n'est pas une exclusion, c'est une lacune. Les auditeurs sondent précisément les exclusions parce que c'est là que les organisations dissimulent parfois un travail inachevé.

Ce que les praticiens maintiennent réellement

Traiter le SoA comme un registre vivant plutôt que comme un tableur ponctuel est ce qui distingue un audit de surveillance fluide d'une course de dernière minute. En pratique, bien le maintenir ressemble à ceci :

1. Conservez une ligne par mesure de l'Annexe A, avec l'applicabilité, la justification, le statut de mise en œuvre et un renvoi vers la preuve qu'un auditeur peut suivre sans vous dans la pièce.
2. Recalculez le SoA chaque fois que l'appréciation des risques ou le plan de traitement change, afin que les trois documents ne divergent jamais en silence.
3. Reliez chaque renvoi de preuve à quelque chose de réel et d'actuel : une politique, une configuration, un ticket, un journal, et non une promesse de le produire plus tard.
4. Révisez le document à une cadence fixe et lors de la revue de direction, et pas seulement dans les semaines précédant un audit.
5. Lors d'une transition entre versions de la norme, réalignez le SoA sur l'ensemble de mesures révisé et confirmez que rien n'est passé à travers les mailles avec les mesures fusionnées ou nouvellement introduites.

Mené de cette façon, le SoA cesse d'être de la paperasse d'audit et devient l'index de tout votre système de management de la sécurité de l'information. C'est le premier document qu'un auditeur expérimenté demande, parce qu'il lui indique où se trouve tout le reste.