Déclaration d'Applicabilité (SoA) ISO 27001 : Guide complet

Points clés

Point	Résumé
Ce que c'est	Document listant les 93 contrôles de l'Annexe A avec leur statut d'applicabilité et justification
Exigée par	Clause 6.1.3 d), documentation SMSI obligatoire
Contenu clé	Référence du contrôle, applicable (Oui/Non), justification, statut d'implémentation
Exclusions courantes	Rarement exclus : contrôle d'accès, chiffrement, réponse aux incidents. Souvent exclus : sécurité physique (pour cloud-native)
Focus auditeur	Document de référence principal pour les audits de certification

Réponse rapide : La Déclaration d'Applicabilité (SoA) liste les 93 contrôles de l'Annexe A et documente lesquels s'appliquent à votre organisation et pourquoi. Chaque contrôle doit avoir une justification pour son inclusion ou exclusion. C'est la référence principale de l'auditeur lors de la certification.

Qu'est-ce qu'une Déclaration d'Applicabilité ?

Définition

La Déclaration d'Applicabilité (SoA) est une liste documentée de tous les contrôles de l'Annexe A avec :

• Si chaque contrôle est applicable ou non
• La justification pour l'inclusion ou l'exclusion
• Le statut d'implémentation

Exigence ISO 27001

La clause 6.1.3 d) exige de produire une Déclaration d'Applicabilité contenant :

• Les contrôles nécessaires (issus du traitement des risques)
• La justification des inclusions
• Si les contrôles sont implémentés ou non
• La justification des exclusions de tout contrôle de l'Annexe A

Pourquoi c'est important

Partie prenante	Valeur de la SoA
Auditeurs	Référence principale pour la vérification des contrôles
Management	Vue d'ensemble des contrôles de sécurité
Clients	Compréhension de vos mesures de sécurité
Opérations	Référence pour l'implémentation des contrôles

Structure de la SoA

Composants essentiels

Structure de la Déclaration d'Applicabilité :

Informations d'en-tête :

• Nom de l'organisation
• Référence du périmètre SMSI
• Version et date
• Signatures d'approbation

Informations sur les contrôles (pour chacun des 93 contrôles de l'Annexe A) :

• Référence du contrôle (ex : 5.1)
• Titre du contrôle
• Applicable ? (Oui/Non)
• Justification (inclusion ou exclusion)
• Statut d'implémentation
• Description de l'implémentation (optionnel)
• Emplacement des preuves (optionnel)

Résumé :

• Total des contrôles applicables
• Total des contrôles exclus
• Statistiques d'implémentation

Template de SoA

Contrôle	Titre	Applicable	Justification	Statut	Description
5.1	Politiques de sécurité de l'information	Oui	Requis pour la gouvernance SMSI	Implémenté	Politique de sécurité approuvée par le CEO
5.2	Rôles de sécurité de l'information	Oui	Requis pour la responsabilité	Implémenté	Rôles définis dans la documentation SMSI
...	...	...	...	...	...
8.4	Accès au code source	Non	Pas de développement logiciel dans le périmètre	N/A	Développement exclu du périmètre SMSI

Créer votre SoA

Étape 1 : Partir du traitement des risques

Votre SoA doit refléter vos décisions de traitement des risques :

Traitement des risques vers Sélection des contrôles vers SoA :

Risque : Accès non autorisé aux données clients

Traitement : Modifier (implémenter des contrôles)

Contrôles sélectionnés :

• 5.15 Contrôle d'accès
• 5.16 Gestion des identités
• 8.2 Droits d'accès privilégiés
• 8.5 Authentification sécurisée

SoA : Marquer ces contrôles comme applicables avec justification basée sur le risque

Étape 2 : Revoir tous les contrôles de l'Annexe A

Même s'ils ne sont pas sélectionnés via le traitement des risques, considérez les 93 contrôles :

Statut du contrôle	Action requise
Sélectionné via traitement des risques	Marquer applicable, documenter la référence au risque
Requis par réglementation	Marquer applicable, documenter l'exigence
Bonne pratique	Considérer l'inclusion, documenter la raison
Non applicable	Justifier l'exclusion

Étape 3 : Documenter les justifications

Pour les contrôles applicables :

Type de justification	Exemple
Basée sur le risque	"Requis pour mitiger le risque R001 (accès non autorisé)"
Réglementaire	"Requis pour la conformité à l'Article 32 du RGPD"
Contractuelle	"Requis par les exigences de sécurité des clients"
Bonne pratique	"Standard de l'industrie pour les fournisseurs SaaS"

Pour les contrôles exclus :

Type de justification	Exemple
Exclusion du périmètre	"Data centers physiques exclus du périmètre SMSI ; cloud uniquement"
Non applicable	"Pas de développement de code source ; utilisation de logiciels tiers uniquement"
Basée sur le risque	"Risque évalué comme acceptable sans ce contrôle"

Étape 4 : Documenter le statut d'implémentation

Statut	Description
Implémenté	Contrôle pleinement opérationnel
Partiellement implémenté	Certains aspects implémentés
Planifié	Implémentation programmée
Non implémenté	Applicable mais pas encore implémenté
N/A	Contrôle exclu

Exemples de SoA par thème de contrôle

Thème 5 : Contrôles organisationnels

Contrôle	Applicabilité courante	Justification typique
5.1 Politiques	Oui (toujours)	Exigence fondamentale du SMSI
5.7 Threat intelligence	Souvent oui	Décision de sécurité basée sur le risque
5.23 Services cloud	Oui (si utilisation cloud)	Gouvernance de sécurité cloud

Exemple d'entrée :
Contrôle : 5.23 Sécurité de l'information pour l'utilisation des services cloud

Applicable : Oui

Justification : L'organisation utilise AWS, GCP et plusieurs applications SaaS nécessitant une gouvernance de sécurité cloud

Statut : Implémenté

Description : Politique de sécurité cloud établie ; tous les services cloud inventoriés et évalués ; certifications des fournisseurs revues

Thème 6 : Contrôles liés aux personnes

Contrôle	Applicabilité courante	Justification typique
6.1 Screening	Oui (généralement)	Requis pour la sécurité à l'embauche
6.3 Sensibilisation	Oui (toujours)	Exigence fondamentale de sécurité
6.7 Travail à distance	Oui (si télétravail)	Pertinence croissante

Exemple d'entrée :
Contrôle : 6.1 Screening

Applicable : Oui

Justification : Tous les employés ayant accès aux systèmes et données nécessitent une vérification des antécédents pour mitiger le risque de menace interne

Statut : Implémenté

Description : Vérifications des antécédents effectuées pour tous les employés via un fournisseur tiers vérifié avant la date d'entrée

Thème 7 : Contrôles physiques

Contrôle	Applicabilité courante	Justification typique
7.1 Périmètres physiques	Dépend du périmètre	Peut être responsabilité du fournisseur cloud
7.4 Surveillance physique	Dépend du périmètre	Sécurité bureau vs data center
7.7 Bureau propre	Généralement oui	Indépendamment de l'infrastructure physique

Exemple d'entrée d'exclusion :
Contrôle : 7.1 Périmètres de sécurité physique

Applicable : Non

Justification : L'organisation est entièrement basée sur le cloud sans data centers physiques. Toute l'infrastructure est hébergée chez AWS qui maintient une certification ISO 27001 couvrant la sécurité physique (référence rapport SOC 2 : Section X.X)

Statut : N/A

Thème 8 : Contrôles technologiques

Contrôle	Applicabilité courante	Justification typique
8.1 Endpoints utilisateurs	Oui (presque toujours)	Sécurité des endpoints essentielle
8.4 Accès au code source	Seulement si développement	Peut exclure si pas de développement
8.28 Secure coding	Seulement si développement	Exclure si utilisation de tiers uniquement

Exemple d'entrée :
Contrôle : 8.24 Utilisation de la cryptographie

Applicable : Oui

Justification : Requis pour protéger la confidentialité et l'intégrité des données clients (mitigue les risques R003, R007)

Statut : Implémenté

Description :

• Données au repos : Chiffrement AES-256 pour toutes les bases de données et stockage
• Données en transit : TLS 1.2+ pour toutes les connexions
• Gestion des clés : AWS KMS avec rotation des clés définie

Erreurs courantes de SoA

Erreur 1 : Exclure sans justification

Problème : "N/A" sans explication

Solution : Chaque exclusion nécessite une justification documentée

Mauvais :

Contrôle 8.4 Accès au code source : N/A

Bien :

Contrôle 8.4 Accès au code source : Non

Justification : L'organisation ne développe pas de logiciel en interne. Toutes les applications sont des solutions SaaS acquises. Les activités de développement sont explicitement exclues du périmètre SMSI (voir Document de périmètre v2.1).

Erreur 2 : Justifications génériques

Problème : "Requis pour la sécurité" n'explique pas pourquoi

Solution : Lier à des risques ou exigences spécifiques

Mauvais :

Contrôle 8.5 : Oui - Requis pour la sécurité

Bien :

Contrôle 8.5 : Oui - Requis pour mitiger le risque de compromission d'identifiants (R001, R004) et satisfaire les exigences contractuelles clients (Template contrat Section 7.3)

Erreur 3 : Statut obsolète

Problème : La SoA dit "Planifié" pour des contrôles implémentés

Solution : Revues et mises à jour régulières de la SoA

Erreur 4 : Lien manquant avec les risques

Problème : Contrôles sélectionnés sans base de risque claire

Solution : Référencer les entrées du registre des risques

Maintenance de la SoA

Quand mettre à jour

Déclencheur	Action
Mise à jour de l'évaluation des risques	Revoir la sélection des contrôles
Changement de périmètre	Ajouter/supprimer des contrôles
Nouvelle exigence réglementaire	Ajouter des contrôles
Constat d'audit	Mettre à jour statut/description
Revue annuelle	Vérifier l'exactitude

Contrôle de version

Version	Date	Changements	Approuvé par
1.0	2024-01-15	Version initiale	RSSI
1.1	2024-04-01	Mise à jour statut pour 8.9, 8.12	RSSI
1.2	2024-07-15	Ajout détails 5.23 pour nouveaux services cloud	RSSI

SoA pour les auditeurs

Ce que les auditeurs vérifient

Focus audit	Preuve nécessaire
Tous les contrôles traités	93 contrôles documentés
Justifications présentes	Raisons d'inclusion et d'exclusion
Alignement risques	Lien avec le traitement des risques
Exactitude du statut	L'implémentation correspond à la réalité
Revue régulière	Preuve de mises à jour

Constats d'audit courants

Constat	Prévention
Contrôles manquants	Utiliser la checklist complète Annexe A
Justifications faibles	Lier aux risques/exigences spécifiques
Écart de statut	Vérification régulière de l'exactitude
Pas de contrôle de version	Implémenter le contrôle documentaire
Non signée	Assurer l'approbation formelle

Statistiques récapitulatives de la SoA

Votre SoA devrait inclure des informations de synthèse :

Résumé de la Déclaration d'Applicabilité :

Total des contrôles Annexe A : 93

Contrôles applicables : 85 (91%)

• Implémentés : 78 (92% des applicables)
• Partiellement implémentés : 5 (6%)
• Planifiés : 2 (2%)

Contrôles exclus : 8 (9%)

Par thème :

• Thème 5 (Organisationnels) : 35/37 applicables (95%)
• Thème 6 (Personnel) : 8/8 applicables (100%)
• Thème 7 (Physiques) : 8/14 applicables (57%)
• Thème 8 (Technologiques) : 34/34 applicables (100%)

L'approche Bastion

Création de SoA simplifiée

Bastion simplifie le développement de la SoA :

Défi	Solution Bastion
93 contrôles à évaluer	Templates pré-évalués par industrie
Rédaction des justifications	Rédaction assistée par IA
Lien avec les risques	Mapping risque-contrôle automatique
Maintien de l'exactitude	Surveillance continue du statut
Contrôle de version	Gestion documentaire intégrée

Revue experte

Votre vCISO assure :

• Sélection appropriée des contrôles
• Justifications défendables
• Statut d'implémentation exact
• Documentation prête pour l'audit

---

Besoin d'aide pour créer votre Déclaration d'Applicabilité ? Parlez à notre équipe →