Rédiger une déclaration d'applicabilité qui résiste à l'audit

La clause 6.1.3(d) de l'ISO/IEC 27001 demande une déclaration d'applicabilité (SoA) : un document qui liste les contrôles dont vous avez besoin, pourquoi vous les avez retenus, s'ils sont mis en œuvre et pourquoi vous avez exclu certains des 93 contrôles de l'annexe A. Cela paraît administratif. En pratique, c'est le lien entre votre appréciation des risques et vos contrôles, et les auditeurs de certification la lisent de près, car une SoA faible révèle généralement un processus de gestion des risques faible en amont.

Ce qu'elle doit contenir

Pour chaque contrôle de l'annexe A, ainsi que pour tout contrôle propre à votre organisation :

1. Applicable ou non.
2. La justification de l'inclusion : généralement les risques qu'il traite, une exigence légale ou contractuelle, ou une décision métier.
3. État de mise en œuvre : mis en œuvre, partiellement mis en œuvre ou planifié.
4. La justification de l'exclusion, le cas échéant.

La plupart des SoA ajoutent une courte description de la manière dont chaque contrôle est mis en œuvre, ainsi qu'une référence à la politique ou à la procédure concernée. Ce n'est pas strictement exigé, mais cela accélère nettement les audits.

Justifier l'inclusion

Rattachez chaque contrôle à un élément concret : un risque de votre registre, une obligation légale (RGPD (GDPR), article 32, NIS2, réglementation sectorielle), un contrat ou une exigence client. « Bonne pratique » est une justification faible ; « traite les risques R-12 et R-17 et répond à nos obligations NIS2 » en est une solide. Relier les contrôles aux exigences légales est également utile lorsque vous répondez à plusieurs référentiels : nos pages d'exigences indiquent à quels autres référentiels correspond chaque contrôle de l'annexe A, par exemple A.8.24 utilisation de la cryptographie.

Justifier l'exclusion

Les exclusions sont autorisées, mais chacune doit reposer sur une raison que les auditeurs peuvent vérifier. Bonnes raisons :

• L'activité n'a pas lieu dans le périmètre. Pas de développement externalisé : A.8.30 exclu.
• Le risque n'existe pas dans le périmètre. Une organisation entièrement en télétravail, sans bureaux, peut exclure certains contrôles physiques de la section A.7, sans toutefois exclure ceux qui couvrent les équipements et les supports, où qu'ils se trouvent.

Raisons faibles : « non pertinent », « géré par l'IT », « le fournisseur cloud s'en charge ». Si un fournisseur met en œuvre le contrôle, celui-ci reste applicable ; vous le gérez au moyen de contrôles fournisseurs.

Constats d'audit fréquents

• La SoA ne correspond pas au plan de traitement des risques. Les contrôles retenus dans le traitement des risques doivent figurer dans la SoA, et inversement.
• Contrôles déclarés mis en œuvre sans preuve. Marquer un contrôle comme mis en œuvre entraîne une demande de justificatif.
• Formulations de modèle. Descriptions copiées d'un modèle qui ne correspondent pas à ce que vous faites réellement.
• Versions obsolètes. Une SoA qui reprend encore la numérotation de l'annexe A de 2013, ou qui n'a pas été mise à jour après un changement significatif.

Une structure pratique

Une ligne par contrôle : identifiant et intitulé, applicable (oui/non), justification (risques, exigences légales et contractuelles), statut, description en une ligne de la manière dont il est mis en œuvre, responsable et référence des preuves. Conservez-la dans un tableur ou dans votre outil GRC, sous gestion documentaire, et revoyez-la à chaque appréciation des risques.

Garder la SoA vivante

Une SoA rédigée pour la première certification puis jamais retouchée devient un constat lors de l'audit suivant. Maintenez-la à jour en la modifiant dès que :

• l'appréciation des risques modifie les contrôles retenus ;
• le périmètre évolue (nouveau produit, bureau ou fournisseur cloud) ;
• le statut de mise en œuvre d'un contrôle change ;
• une nouvelle exigence légale ou contractuelle s'applique (par exemple NIS2 ou le contrat d'un client).

Consignez à chaque fois la version, la date et l'approbateur.

Points clés

• Chaque contrôle de l'annexe A requiert une décision et une justification, y compris les exclusions.
• Reliez les inclusions à des risques précis et à des exigences légales ou contractuelles.
• Gardez la SoA cohérente avec le plan de traitement des risques, et à jour.

Gérer plusieurs référentiels à la fois

Si vous répondez aussi à SOC 2, NIS2 ou PCI DSS, ajoutez une colonne pour les exigences correspondantes de chacun. La SoA devient alors l'épine dorsale d'un socle de contrôles commun ; notre article sur un socle de contrôles commun pour SOC 2 et ISO 27001 présente la démarche, et l'analyse d'écarts répertorie chaque contrôle de l'annexe A par rapport à tout autre référentiel. Le guide ISO 27001 couvre le reste de la certification.

Questions

Peut-on exclure des contrôles de l'annexe A dans ISO 27001 ?

Oui, si l'exclusion est justifiée, généralement parce que le risque n'existe pas dans votre périmètre (par exemple le développement externalisé lorsque vous n'externalisez pas le développement). Les exclusions doivent être justifiées dans la déclaration d'applicabilité.

Que doit contenir une déclaration d'applicabilité ?

La clause 6.1.3(d) de l'ISO 27001 exige les contrôles nécessaires, la justification de leur inclusion, leur état de mise en œuvre et la justification de l'exclusion de tout contrôle de l'annexe A.

La déclaration d'applicabilité est-elle partagée avec les clients ?

Pas en général dans son intégralité : c'est un document interne examiné par l'organisme de certification. Certaines organisations partagent un résumé avec leurs clients sous accord de confidentialité (NDA) pour indiquer quels contrôles s'appliquent.