Qu'est-ce qu'une Déclaration d'Applicabilité (SoA) ?
La Déclaration d'Applicabilité (SoA) est un document obligatoire ISO 27001 qui liste les 93 contrôles de l'Annexe A et explique si chaque contrôle est inclus dans…
Aperçu
La Déclaration d'Applicabilité (SoA) est un document obligatoire ISO 27001 qui liste les 93 contrôles de l'Annexe A et explique si chaque contrôle est inclus dans votre SMSI ou exclu. Pour les contrôles inclus, elle décrit comment ils sont mis en œuvre. Pour les contrôles exclus, elle fournit une justification de l'exclusion.
Ce que cela signifie en pratique
La SoA est votre plan de sélection des contrôles - elle relie les résultats de votre évaluation des risques aux mesures de sécurité spécifiques que vous avez choisies de mettre en œuvre. Les auditeurs l'utilisent comme feuille de route pour vérifier que votre SMSI traite les risques identifiés de manière appropriée.
Exemple concret : Votre évaluation des risques identifie les ransomwares comme une menace critique. Votre SoA indiquerait le contrôle A.8.7 (Protection contre les logiciels malveillants) comme "Inclus" avec des détails de mise en œuvre tels que "Logiciel de détection et de réponse sur les terminaux déployé sur tous les appareils avec gestion centralisée", tandis que le contrôle A.7.4 (Surveillance de la sécurité physique) pourrait être "Exclu - organisation entièrement cloud sans centre de données physique".
Pourquoi la SoA est importante pour l'ISO 27001
Exigence obligatoire
La clause 6.1.3(d) de l'ISO 27001 exige explicitement de maintenir "une Déclaration d'Applicabilité contenant les contrôles nécessaires et la justification des inclusions et exclusions". Vous ne pouvez pas obtenir la certification sans une SoA complète et précise.
Démontre une approche basée sur les risques
La SoA prouve que vous n'implémentez pas les contrôles de manière aléatoire ou que vous n'appliquez pas aveuglément des modèles. Elle montre comment chaque décision de contrôle remonte à votre évaluation des risques.
Feuille de route pour l'audit
Les auditeurs utilisent votre SoA pour planifier ce qu'ils vérifieront lors des audits de certification. Les contrôles inclus nécessitent des preuves de mise en œuvre et d'efficacité. Les exclusions doivent être justifiées en fonction de l'évaluation des risques ou du contexte commercial.
Gestion des changements
À mesure que les risques évoluent, votre SoA doit être mise à jour pour refléter les nouvelles exigences de contrôle ou permettre la suppression de contrôles précédemment exclus si les risques diminuent.
Constat d'audit courant : Les justifications de la SoA qui ne correspondent pas aux résultats de l'évaluation des risques. Par exemple, exclure les contrôles de sauvegarde (A.8.13) alors que votre évaluation des risques identifie la perte de données comme un risque élevé entraînera une non-conformité.
Ce que la SoA doit inclure
Liste complète des contrôles
Les 93 contrôles de l'Annexe A de l'ISO 27001:2022 doivent figurer dans votre SoA, organisés par thème :
- Contrôles organisationnels : A.5.1 à A.5.37 (37 contrôles)
- Contrôles liés aux personnes : A.6.1 à A.6.8 (8 contrôles)
- Contrôles physiques : A.7.1 à A.7.14 (14 contrôles)
- Contrôles technologiques : A.8.1 à A.8.34 (34 contrôles)
Statut d'inclusion/exclusion
Pour chaque contrôle, indiquez clairement s'il est inclus dans votre SMSI ou exclu. Évitez les statuts ambigus comme "partiellement applicable" - les contrôles sont soit inclus, soit exclus.
Description de la mise en œuvre (pour les contrôles inclus)
Décrivez brièvement comment vous mettez en œuvre chaque contrôle inclus. Incluez :
- Les politiques, procédures ou technologies spécifiques utilisées
- Qui est responsable du contrôle
- Où trouver les preuves de la mise en œuvre
- Comment le contrôle traite les risques identifiés
Justification de l'exclusion (pour les contrôles exclus)
Expliquez pourquoi les contrôles exclus ne font pas partie de votre SMSI. Justifications valides :
- Basée sur les risques : "Aucun risque dans notre évaluation ne nécessite ce contrôle"
- Basée sur le contexte : "Non applicable - nous sommes entièrement cloud sans infrastructure physique"
- Légale/réglementaire : "Interdit par les lois de résidence des données dans notre juridiction"
Qualité de la justification : Les justifications solides d'exclusion font référence à des résultats spécifiques de l'évaluation des risques ou au contexte organisationnel. Les justifications faibles comme "non pertinent" ou "pas encore mis en œuvre" seront contestées par les auditeurs.
Structure et format de la SoA
Format tabulaire (le plus courant)
Un tableau avec des colonnes pour :
- Numéro du contrôle (par exemple, A.5.1)
- Nom du contrôle (par exemple, "Politiques pour la sécurité de l'information")
- Statut (Inclus / Exclu)
- Description de la mise en œuvre ou justification de l'exclusion
- Référence au risque (lien vers le registre des risques)
- Emplacement des preuves (optionnel mais utile)
Format narratif
Certaines organisations préfèrent un document narratif décrivant la mise en œuvre des contrôles regroupés par thème. Moins courant mais acceptable si tous les 93 contrôles sont clairement abordés.
Format basé sur des outils
Les plateformes GRC et les outils SMSI génèrent souvent des SoA automatiquement en fonction de la sélection des contrôles et de leur lien avec les évaluations des risques. Celles-ci nécessitent encore une validation manuelle pour en garantir l'exactitude.
Préférence des auditeurs : La plupart des auditeurs privilégient les SoA tabulaires car elles sont faciles à parcourir et à croiser. Gardez les descriptions de mise en œuvre concises (2-3 phrases par contrôle) - les procédures détaillées appartiennent à des documents de procédure séparés, pas à la SoA.
Création de votre SoA
Étape 1 : Réaliser l'évaluation des risques
Votre SoA est un résultat direct de l'évaluation des risques. Identifiez tous les risques nécessitant un traitement avant de déterminer quels contrôles mettre en œuvre.
Étape 2 : Cartographier les contrôles par rapport aux risques
Pour chaque risque nécessitant un traitement, identifiez quels contrôles de l'Annexe A permettraient de le réduire à des niveaux acceptables. Un risque peut nécessiter plusieurs contrôles ; un contrôle peut traiter plusieurs risques.
Étape 3 : Déterminer l'inclusion/exclusion
Les contrôles traitant des risques identifiés sont inclus. Les contrôles ne traitant aucun de vos risques peuvent être exclus (avec justification).
Étape 4 : Décrire la mise en œuvre
Pour les contrôles inclus, documentez comment vous les mettez en œuvre. Soyez suffisamment spécifique pour que les auditeurs comprennent votre approche sans dupliquer des procédures entières.
Étape 5 : Justifier les exclusions
Pour les contrôles exclus, expliquez pourquoi en vous basant sur votre évaluation des risques ou le contexte organisationnel. Faites référence à des résultats spécifiques de votre registre des risques lorsque cela est possible.
Étape 6 : Réviser et approuver
La direction doit formellement réviser et approuver la SoA, en reconnaissant les décisions de sélection des contrôles et les éventuels risques résiduels.
Contrôle des versions : La SoA est un document vivant qui doit être mis à jour lorsque les risques changent, que des contrôles sont ajoutés ou modifiés, ou que des exclusions sont reconsidérées. Maintenez un historique des versions montrant quand et pourquoi les changements ont eu lieu.
Erreurs courantes dans la SoA
Exclure trop de contrôles
Les organisations excluent parfois des contrôles pour réduire l'effort de mise en œuvre. Les auditeurs examinent attentivement les exclusions - si votre évaluation des risques est approfondie, la plupart des contrôles devraient être inclus.
Descriptions de mise en œuvre génériques
Copier les descriptions des contrôles de l'ISO 27002 sans décrire votre mise en œuvre réelle. Les auditeurs ont besoin de comprendre ce que vous faites, pas ce que dit la norme.
Liens manquants avec les risques
Ne pas relier les contrôles à des risques spécifiques dans votre évaluation des risques. Cela rompt la traçabilité et suggère que les contrôles ont été sélectionnés de manière arbitraire.
Couverture incomplète
Oublier de traiter les 93 contrôles. Même si un contrôle semble manifestement non applicable, il doit figurer dans la SoA avec une justification d'exclusion.
Aucun cycle de révision
Créer la SoA une fois lors de la mise en œuvre initiale et ne jamais la mettre à jour malgré les changements organisationnels ou les nouveaux risques.
Conseil d'efficacité : Utilisez ISMS Copilot pour générer un modèle de SoA avec des descriptions de mise en œuvre courantes pour votre secteur. Personnalisez le résultat en fonction de vos résultats spécifiques d'évaluation des risques et de votre contexte.
SoA vs. autres documents ISO 27001
SoA vs. Plan de traitement des risques
Le Plan de traitement des risques détaille comment vous allez mettre en œuvre les contrôles sélectionnés (calendriers, responsabilités, ressources). La SoA déclare quels contrôles sont mis en œuvre et pourquoi. Les deux documents sont complémentaires.
SoA vs. Preuves de contrôle
La SoA décrit quels contrôles vous mettez en œuvre. Les preuves démontrent que les contrôles fonctionnent effectivement. Lors des audits, les auditeurs échantillonnent les contrôles de votre SoA et demandent les preuves correspondantes.
SoA vs. Politiques et procédures
Les politiques et procédures fournissent des instructions détaillées pour la mise en œuvre des contrôles. La SoA résume à un niveau élevé quels contrôles existent et comment ils fonctionnent.
Comment les auditeurs utilisent la SoA
Audit de phase 1 (revue de la documentation)
Les auditeurs vérifient que votre SoA est complète (tous les 93 contrôles traités), logiquement structurée et alignée avec votre évaluation des risques. Ils vérifient que les justifications des exclusions sont sensées.
Audit de phase 2 (vérification de la mise en œuvre)
Les auditeurs échantillonnent les contrôles de votre SoA et demandent des preuves qu'ils sont mis en œuvre comme décrit. Ils testeront les contrôles dans les quatre thèmes et les domaines organisationnels dans le périmètre.
Déclencheurs de non-conformité
Raisons courantes pour lesquelles les auditeurs émettent des non-conformités liées à la SoA :
- Contrôles marqués "inclus" mais non réellement mis en œuvre
- Exclusions sans justification valide
- SoA ne reflétant pas les résultats réels de l'évaluation des risques
- Contrôles manquants (moins de 93 listés)
- Descriptions de mise en œuvre trop vagues pour être vérifiées
Préparation à l'audit : Avant l'audit de certification, passez en revue chaque contrôle "inclus" dans votre SoA et rassemblez les preuves correspondantes. Si vous ne trouvez pas de preuve pour un contrôle, mettez-le en œuvre correctement ou mettez à jour la SoA pour l'exclure avec justification.
Maintenance de la SoA au fil du temps
Mises à jour annuelles de l'évaluation des risques
Lorsque vous effectuez des réévaluations des risques prévues, examinez la SoA pour déterminer si les sélections de contrôles restent appropriées. De nouveaux risques peuvent nécessiter des contrôles précédemment exclus.
Changements organisationnels
Mettez à jour la SoA lorsque :
- Une nouvelle technologie est déployée (peut nécessiter de nouveaux contrôles techniques)
- Le modèle d'entreprise change (par exemple, passage au cloud modifie les contrôles physiques)
- L'expansion géographique introduit de nouvelles exigences réglementaires
- Les fusions ou acquisitions modifient le profil de risque
Révisions déclenchées par des incidents
Après des incidents de sécurité significatifs, examinez si les contrôles existants ont été efficaces ou si des contrôles supplémentaires (précédemment exclus) doivent être mis en œuvre.
Audits de surveillance
Les auditeurs vérifieront lors des audits de surveillance annuels si la SoA a été maintenue à jour. Des preuves de révision régulière démontrent que votre SMSI est actif, et non abandonné après la certification.
SoA et personnalisation des contrôles
La norme permet l'adaptation
L'ISO 27001 permet aux organisations de mettre en œuvre les contrôles différemment en fonction de la taille, de la complexité et des risques. Votre SoA doit refléter votre mise en œuvre spécifique, et non un modèle générique.
Contrôles supplémentaires au-delà de l'Annexe A
Si votre évaluation des risques identifie des risques non adéquatement traités par les 93 contrôles standard, vous pouvez mettre en œuvre des contrôles supplémentaires. Listez-les dans votre SoA ou dans un document complémentaire.
La proportionnalité compte
La mise en œuvre du contrôle "A.6.3 Formation à la sensibilisation à la sécurité de l'information" par une startup de 10 personnes différera de celle d'une entreprise de 10 000 personnes. Les deux peuvent être conformes si elles sont appropriées au contexte et efficaces pour réduire les risques.
Exemple de mise en œuvre proportionnelle : Une petite entreprise SaaS entièrement cloud pourrait exclure A.7.1-A.7.14 (contrôles physiques) en justifiant "Aucune infrastructure physique - tous les systèmes fonctionnent dans AWS avec une sécurité gérée par les contrôles SOC 2 du fournisseur cloud". Cela est acceptable si leur évaluation des risques reflète l'architecture cloud-first.
Concepts connexes
- Annex A Controls - Les 93 contrôles de sécurité que votre SoA doit aborder
- Risk Assessment - Processus qui guide la sélection des contrôles dans votre SoA
- Risk Treatment - Mise en œuvre des contrôles identifiés dans votre SoA
- Control - Les mesures de sécurité que vous sélectionnez dans votre SoA
- Comment démarrer la mise en œuvre de l'ISO 27001 en utilisant l'IA
Obtenir de l'aide
Accélérez la création de votre SoA avec ISMS Copilot. Générez des descriptions de mise en œuvre personnalisées, validez vos justifications par rapport aux résultats de l'évaluation des risques, et assurez-vous que les 93 contrôles sont correctement traités.