Déclaration d'applicabilité : contenu et justification
Construire une déclaration d'applicabilité (SoA) crédible, avec des justifications d'inclusion et d'exclusion argumentées.
À retenir
- La SoA relie chaque mesure de l'Annexe A au résultat de l'appréciation du risque.
- Toute exclusion doit être justifiée par le contexte propre de l'organisation, pas par la difficulté de mise en œuvre.
- La SoA doit inclure statut, justification, état de mise en œuvre et preuve.
- La SoA se met à jour à chaque évolution significative du périmètre ou des risques.
La SoA, document charnière du SMSI
La déclaration d'applicabilité (Statement of Applicability, SoA) liste chacune des mesures de l'Annexe A de l'ISO/IEC 27001 et précise si elle est applicable au périmètre du système de management, en s'appuyant sur les résultats de l'appréciation du risque et sur le plan de traitement. C'est le document qui relie la théorie du risque à la pratique des mesures effectivement déployées, et c'est souvent le premier document examiné par un auditeur externe après le périmètre du SMSI.
Structure attendue d'une ligne de SoA
Pour chaque mesure de l'Annexe A, une SoA sérieuse renseigne : le libellé de la mesure, son statut (applicable / non applicable), la justification de ce statut, l'état de mise en œuvre, et une référence vers la preuve documentaire.
| Mesure (Annexe A) | Applicable | Justification | État |
|---|---|---|---|
| Contrôle d'accès physique aux locaux | Oui | Site hébergeant des données clients critiques, accès sensible | Mise en œuvre (badges + biométrie) |
| Cycle de développement sécurisé | Non | L'organisation n'écrit pas de code applicatif, uniquement de l'exploitation infrastructure | Exclue |
| Journalisation des événements | Oui | Exigence contractuelle SLA et détection d'incident | Mise en œuvre partielle (rétention à étendre) |
| Sécurité du télétravail | Oui | Personnel administratif en télétravail partiel | Mise en œuvre (VPN + MFA) |
Point clé
une exclusion sans justification écrite et spécifique au contexte de l'organisation est systématiquement contestée en audit — « non applicable » n'est jamais une réponse suffisante en soi.
Justifier une exclusion correctement
Une bonne justification d'exclusion répond à la question « pourquoi ce risque n'existe pas ou est déjà couvert autrement chez nous ? », pas « pourquoi c'est compliqué à mettre en œuvre ». Par exemple, exclure la mesure liée à la gestion de code source parce que l'organisation ne développe aucun logiciel est recevable ; l'exclure parce que « ce serait trop long à documenter » ne l'est pas.
Attention
une confusion fréquente consiste à croire qu'une mesure « non applicable » dans la SoA peut simplement être ignorée. En réalité, même exclue, la mesure doit rester traçable dans le raisonnement : pourquoi le risque associé est-il nul ou déjà couvert par une autre mesure ?
Tenir la SoA à jour
La SoA doit évoluer avec le périmètre : un nouveau service, un nouveau site ou un changement de sous-traitant peut rendre applicable une mesure jusque-là exclue. Une SoA figée depuis la certification initiale est un signal d'alerte classique pour un auditeur.
Sur le terrain
un hébergeur qui ouvre un second site doit revoir sa SoA sur les mesures physiques (contrôle d'accès, protection contre les sinistres) car les conditions locales (zone sismique, fournisseur électrique) peuvent différer d'un site à l'autre.
Astuce
rédigez la SoA dans le même tableur que le registre des risques, avec une colonne de renvoi croisé — cela évite les incohérences entre risques traités et mesures déclarées applicables.