La norme ISO 27001 constitue la référence internationale en matière de gestion de la sécurité de l’information. Au cœur de son système de management, la déclaration d’applicabilité occupe une place centrale. C’est le premier document que l’auditeur consulte au moment de la certification et le point où se rejoint tout ce que l’organisation a décidé de mettre en place pour protéger ses informations.
Dans cet article, vous découvrirez ce qu’est la déclaration d’applicabilité, à quoi elle sert, ce qu’elle doit contenir et comment la rédiger étape par étape, avec un exemple de tableau pour visualiser le résultat.
Qu’est-ce que la déclaration d’applicabilité (SoA) de l’ISO 27001 ?
La déclaration d’applicabilité, souvent désignée par son sigle anglais SoA (Statement of Applicability), est le document qui recense l’ensemble des mesures de sécurité de l’Annexe A de la norme ISO 27001. Pour chacune d’elles, elle précise si l’organisation la retient ou non, avec la justification correspondante et son état de mise en œuvre.
Autrement dit, elle offre une vue d’ensemble des mesures que votre organisation a choisi de déployer, de celles qu’elle a écartées et des raisons de ces choix. Dans la version en vigueur de la norme, l’ISO 27001 de 2022, l’Annexe A regroupe 93 mesures de sécurité réparties en 4 thématiques. La déclaration d’applicabilité passe donc en revue ces 93 mesures une à une.
Il ne faut pas confondre la déclaration d’applicabilité avec l’appréciation des risques. Cette dernière identifie les menaces auxquelles l’organisation est exposée, tandis que la déclaration d’applicabilité formalise le choix des mesures retenues pour traiter ces risques. Ce sont deux documents distincts qui fonctionnent ensemble, et vous verrez plus loin comment ils s’articulent.
À quoi sert-elle et pourquoi est-elle obligatoire ?
La déclaration d’applicabilité remplit plusieurs fonctions au sein du SMSI. Trois d’entre elles expliquent son importance.
- Un document obligatoire pour la certification : la norme l’exige explicitement. L’exigence 6.1.3 d) de l’ISO 27001 de 2022 impose de rédiger une déclaration d’applicabilité qui recense les mesures nécessaires, la justification de leur intégration, leur état de mise en œuvre et le motif d’exclusion de toute mesure écartée. Sans déclaration d’applicabilité, aucune certification n’est envisageable.
- Le lien entre l’appréciation des risques et les mesures : la déclaration d’applicabilité fait le pont entre les risques que vous avez identifiés et les dispositifs mis en place pour les traiter. Elle rend visible la traçabilité entre ce que demande la norme et ce que l’organisation réalise concrètement.
- Le fil conducteur de l’auditeur : lors de l’audit, l’auditeur ouvre la déclaration d’applicabilité avant tout autre document, car elle lui donne une cartographie complète du SMSI. À partir de là, il vérifie que les mesures que vous déclarez appliquer sont réellement en place et que les exclusions sont cohérentes. Une déclaration d’applicabilité bâclée, sans justifications ou avec des exclusions non fondées, mène rapidement à une non-conformité.
Que doit contenir la déclaration d’applicabilité ?
La norme n’impose aucun format précis. Vous pouvez donc retenir celui qui vous convient le mieux, à condition qu’il rassemble les informations nécessaires. Pour chaque mesure de l’Annexe A, la déclaration d’applicabilité doit faire apparaître quatre éléments.
- La mesure et sa description : la référence et l’intitulé de la mesure tels qu’ils figurent dans l’Annexe A, par exemple A.5.1 Politiques de sécurité de l’information.
- Son applicabilité : la décision d’intégrer ou d’exclure cette mesure de votre SMSI.
- La justification : le motif de cette décision, que la mesure soit retenue ou écartée. Ce point est déterminant, car la justification des exclusions fait partie de ce que l’auditeur examine le plus attentivement.
- L’état de mise en œuvre et les preuves : indiquez si la mesure est en place, en cours de déploiement ou à traiter, en renvoyant à la politique, à la procédure ou à la preuve qui l’appuie.
De nombreuses organisations ajoutent des colonnes supplémentaires, comme le responsable de la mesure ou le risque qu’elle traite, afin de renforcer la traçabilité. Ce n’est pas obligatoire, mais cela aide à garder le document sous contrôle.
Exemple de tableau d’une déclaration d’applicabilité
Voici à quoi ressemble généralement une déclaration d’applicabilité sous forme de tableau. Il s’agit d’un exemple simplifié, avec quelques mesures, pour en illustrer la structure.
| Mesure | Description | Applicable ? | Justification | État | Preuve |
|---|---|---|---|---|---|
| A.5.1 | Politiques de sécurité de l’information | Oui | Risque identifié lors de l’appréciation des risques | En place | Politique de SI v1.2 |
| A.5.7 | Renseignements sur les menaces | Oui | Besoin d’anticiper les menaces externes | En cours de déploiement | Procédure de renseignement sur les menaces |
| A.6.7 | Travail à distance | Oui | Une partie des collaborateurs travaille hors des locaux | En place | Politique de télétravail v2.0 |
| A.7.4 | Surveillance de la sécurité physique | Non | L’organisation ne dispose pas de locaux en propre | Non applicable | Justification documentée |
| A.8.23 | Filtrage web | Oui | Risque d’accès à des sites malveillants | En place | Configuration du proxy de l’entreprise |
Comment rédiger une déclaration d’applicabilité étape par étape ?
Rédiger la déclaration d’applicabilité n’est pas une démarche isolée. Elle découle naturellement du travail de gestion des risques réalisé en amont. Voici les étapes habituelles pour la construire.
1. Commencez par l’appréciation et le traitement des risques
La déclaration d’applicabilité n’est pas le point de départ de la démarche. Elle résulte du travail mené en amont sur les risques. Avant de vous y attaquer, vous devez avoir identifié vos actifs informationnels, évalué les risques auxquels ils sont exposés et arrêté les options de traitement pour chacun. C’est à ce moment que l’on voit clairement quelles mesures sont nécessaires pour réduire chaque risque.
Si vous tentez de remplir la déclaration d’applicabilité sans ce travail préalable, vous cocherez des mesures à l’aveugle et l’auditeur s’en apercevra aussitôt, faute de traçabilité entre les risques identifiés et les mesures retenues.
2. Sélectionnez les mesures applicables de l’Annexe A
Une fois les risques posés, vous parcourez les 93 mesures de l’Annexe A de la version 2022 et vous décidez lesquelles s’appliquent à votre organisation. La norme n’oblige pas à toutes les déployer, uniquement celles que votre niveau de risque justifie. Une mesure peut donc être écartée si elle n’a pas de sens dans votre contexte.
Gardez aussi à l’esprit que vous pouvez ajouter des mesures ne figurant pas dans l’Annexe A si votre appréciation des risques l’exige, car cette annexe est une référence et non une liste figée.
3. Documentez la justification, l’état et les preuves
Pour chaque mesure, vous notez son applicabilité et le motif de la décision. Pour celles qui sont retenues, vous ajoutez leur état de mise en œuvre, en place, en cours de déploiement ou à traiter, ainsi que le renvoi à la politique, à la procédure ou à la preuve qui l’appuie.
Ne négligez pas la justification des exclusions, car c’est précisément ce que l’auditeur examine le plus. Exclure une mesure est tout à fait recevable dès lors que vous expliquez pourquoi elle ne s’applique pas à votre organisation. Un motif bien formulé a plus de valeur qu’une série de mesures cochées sans explication.
4. Relisez et approuvez le document
Pour finir, la déclaration d’applicabilité doit être relue et approuvée par la plus haute autorité de sécurité de l’organisation avant d’être validée. Cette approbation formelle transforme le brouillon en document de référence du SMSI.
Elle est alors prête pour l’audit. Il faut toutefois garder en tête qu’il ne s’agit pas d’une version définitive et immuable. C’est la première d’une longue série, car la déclaration d’applicabilité évoluera au fil du temps.
Comment Factorial IT vous aide-t-il avec la déclaration d’applicabilité ?
Chaque ligne de la SoA demande une décision et une preuve. Pour les mesures organisationnelles, cette preuve est généralement une politique ou une procédure. Pour les mesures technologiques, elle dépend de l’état réel des postes, des comptes et des applications, et c’est là que le document se périme le plus vite.
Factorial IT gère cette partie depuis une plateforme unique connectée au SIRH, et alimente plusieurs colonnes de la SoA.
- Des justifications fondées sur des données : l’inventaire indique combien d’ordinateurs portables et de smartphones compte l’entreprise, sous quels systèmes d’exploitation, et qui travaille en dehors du bureau. Avec ces informations, décider si des mesures comme le travail à distance (6.7) ou les terminaux des utilisateurs (8.1) s’appliquent ne relève plus de l’intuition, et la justification s’appuie sur des chiffres.
- Des mesures qui passent de « en cours » à « mise en œuvre » : les activités de surveillance (8.16) restent souvent inachevées dans les entreprises qui n’ont pas leur propre centre opérationnel de sécurité. Factorial IT propose des services MDR, avec des analystes qui surveillent les postes 24 h/24 et répondent aux menaces, pour couvrir cette mesure sans monter d’équipe en interne.
- Des correctifs au-delà du système d’exploitation (8.8) : la gestion des vulnérabilités impose de corriger aussi les applications tierces, celles que l’on oublie le plus souvent. Avec le module de gestion des correctifs de l’EDR, les mises à jour des logiciels installés sont appliquées de façon centralisée sur l’ensemble du parc.
- Des preuves datées : dans la colonne des preuves, renvoyer à un rapport exporté sur l’état du parc à une date précise a bien plus de poids que le simple nom d’un document. L’auditeur peut le comparer sur-le-champ avec la situation actuelle.
De plus, lorsque le parc évolue, la plateforme le reflète immédiatement. Un nouveau type d’appareil ou un changement dans la façon de travailler des équipes apparaît dans les données avant d’apparaître dans le document, et c’est le signal qu’il est temps de revoir la SoA.
