Declaration d'Applicabilite (SoA) ISO 27001 : Comment la creer

La Declaration d’Applicabilite est le document le plus important de votre ISMS ISO 27001. Ce n’est pas une hyperbole. C’est le document qui relie votre evaluation des risques a vos mesures, justifie pourquoi vous avez mis en oeuvre ce que vous avez mis en oeuvre (et exclu ce que vous avez exclu), et sert de point de reference principal pour les auditeurs de certification. Une SoA inadequate est le chemin le plus rapide vers des non-conformites d’audit, et une SoA bien elaboree demontre que votre ISMS est un systeme coherent et pilote par les risques plutot qu’une collection de mesures choisies au hasard.

La clause 6.1.3 d) d’ISO 27001 exige que les organisations produisent une Declaration d’Applicabilite contenant les mesures necessaires, la justification de leur inclusion, si elles sont mises en oeuvre ou non, et la justification de l’exclusion de toute mesure de l’Annex A. Chacune des 93 mesures de l’Annex A doit etre traitee — vous ne pouvez pas simplement omettre des mesures sans explication.

Ce guide vous accompagne a travers ce qu’est la SoA, ce qu’elle doit contenir, comment en creer une etape par etape a partir de votre plan de traitement des risques, et les erreurs courantes qui menent a des constatations d’audit.

Qu’est-ce que la Declaration d’Applicabilite ?

La Declaration d’Applicabilite est un enregistrement documente de toutes les mesures considerees pour le ISMS, avec la justification de leur inclusion ou exclusion. Elle fait le lien entre deux processus essentiels :

1. Resultats de l’evaluation des risques — les risques que vous avez identifies, analyses et evalues
2. Mise en oeuvre des mesures — les actions specifiques que vous avez deployees pour traiter ces risques

Sans la SoA, il n’existe aucun lien formel entre « nous avons identifie ces risques » et « nous avons mis en oeuvre ces mesures. » L’evaluation des risques vous indique ce qui pourrait mal tourner. La SoA vous indique ce que vous avez fait a ce sujet — et, tout aussi important, ce que vous avez decide de ne pas faire et pourquoi.

Ou se situe la SoA dans le ISMS

La SoA est produite apres l’evaluation des risques et le plan de traitement des risques, et avant (ou en meme temps que) la mise en oeuvre des mesures. La sequence est :

1. Evaluation des risques (clause 6.1.2) — identifier et evaluer les risques
2. Plan de traitement des risques (clause 6.1.3) — decider comment traiter chaque risque
3. Declaration d’Applicabilite (clause 6.1.3 d) — documenter quelles mesures traitent quels risques
4. Mise en oeuvre des mesures — deployer les mesures documentees dans la SoA
5. Audit interne (clause 9.2) — verifier que les mesures sont mises en oeuvre et efficaces
6. Audit de certification — l’auditeur externe examine la SoA et verifie la mise en oeuvre

En pratique, les etapes 3 et 4 sont souvent iteratives — vous pouvez affiner la SoA au fur et a mesure que vous mettez en oeuvre les mesures et decouvrez que certaines mesures doivent etre ajustees ou que des mesures supplementaires sont necessaires.

Ce que la clause 6.1.3 exige reellement

La clause 6.1.3 d) stipule que l’organisation doit produire une Declaration d’Applicabilite contenant :

• Les mesures necessaires — en tenant compte des resultats de l’evaluation des risques et du processus de traitement des risques, et independamment du fait qu’elles proviennent de l’Annex A ou d’une autre source
• La justification de leur inclusion — pourquoi chaque mesure est dans le perimetre
• Si les mesures necessaires sont mises en oeuvre ou non — le statut actuel de mise en oeuvre
• La justification de l’exclusion de toute mesure de l’Annex A — pourquoi les mesures exclues ne s’appliquent pas

La phrase « independamment du fait qu’elles proviennent de l’Annex A ou d’une autre source » est importante. Votre SoA doit inclure les 93 mesures de l’Annex A comme base de reference, mais vous pouvez egalement inclure des mesures provenant d’autres sources (NIST, CIS, cadres specifiques a l’industrie ou mesures personnalisees developpees par votre organisation). L’Annex A est l’ensemble minimal a considerer, pas le maximum.

Composants requis de la SoA

Une SoA complete inclut les informations suivantes pour chaque mesure :

Reference et titre de la mesure

Le numero de la mesure de l’Annex A et son nom. Pour la version 2022, il s’agit de A.5.1 a A.8.34. Si vous avez des mesures supplementaires provenant d’autres sources, incluez-les avec un schema de reference coherent (par exemple, CUSTOM-001, NIST-AC-2).

Decision d’inclusion ou d’exclusion

Une declaration claire indiquant si la mesure est incluse (applicable) ou exclue (non applicable) pour votre ISMS. C’est une decision binaire — il n’y a pas de « partiellement applicable. » Si un aspect quelconque d’une mesure s’applique, elle est incluse.

Justification de l’inclusion

Pour chaque mesure incluse, indiquez pourquoi elle est necessaire. La justification doit remonter a un ou plusieurs des elements suivants :

• Traitement des risques — la mesure attenuer un risque specifique identifie dans l’evaluation des risques (reference de l’identifiant du risque)
• Exigence legale ou reglementaire — la mesure est requise par la loi ou la reglementation applicable (par exemple, RGPD, reglementation sectorielle)
• Obligation contractuelle — la mesure est requise par les contrats clients ou les accords commerciaux
• Bonne pratique — la mesure est mise en oeuvre comme bonne pratique meme si aucun risque specifique, exigence legale ou obligation contractuelle ne l’impose (ceci est acceptable mais devrait etre l’exception, pas la regle)

Exemple de justification d’inclusion : « Incluse. A.8.5 (Authentification securisee) traite RISK-2026-003 (Acces non autorise aux donnees clients par compromission d’identifiants) et RISK-2026-015 (Prise de controle de compte via phishing). Le MFA est egalement une exigence contractuelle dans nos accords clients entreprise. »

Justification de l’exclusion

Pour chaque mesure exclue, indiquez pourquoi elle n’est pas applicable a votre ISMS. La justification doit demontrer que l’exclusion de la mesure ne compromet pas la securite de l’information. Les declarations generiques comme « non applicable » sont insuffisantes.

Exemple de justification d’exclusion : « Exclue. A.7.12 (Securite du cablage) n’est pas applicable car l’organisation ne dispose d’aucun centre de donnees ou salle de serveurs sur site. Toute l’infrastructure de production est hebergee sur AWS, ou la securite du cablage physique est geree par AWS dans le cadre de leur modele de responsabilite partagee. Le reseau de bureau utilise des equipements commerciaux standard sans traitement de donnees sensibles localement. L’exclusion de cette mesure ne cree pas de risque de securite non traite. »

Statut de mise en oeuvre

Pour chaque mesure incluse, indiquez si elle est :

• Mise en oeuvre — la mesure est entierement deployee et operationnelle
• Partiellement mise en oeuvre — certains aspects sont en place mais d’autres sont en attente (decrivez ce qui est fait et ce qui reste)
• Planifiee — la mesure n’est pas encore mise en oeuvre mais est programmee (incluez la date cible)
• Non encore commencee — la mesure est incluse mais la mise en oeuvre n’a pas debute (incluez la date cible)

Le statut de mise en oeuvre est particulierement important lors de la certification initiale. Il est acceptable d’avoir des mesures « planifiees » ou « partiellement mises en oeuvre » au moment ou vous produisez la SoA — mais elles doivent etre entierement mises en oeuvre avant l’audit de certification de Stage 2. Les auditeurs verifieront la mise en oeuvre par rapport a ce que la SoA declare.

Proprietaire de la mesure

Designez un individu responsable de la mise en oeuvre et du fonctionnement continu de chaque mesure. Ce n’est pas toujours requis par les auditeurs, mais c’est fortement recommande car cela etablit la responsabilite et garantit que les mesures ne deviennent pas orphelines.

Etape par etape : Creer la SoA a partir de votre plan de traitement des risques

Etape 1 : Commencer avec la liste complete des mesures de l’Annex A

Creez un document (tableur, base de donnees ou outil de gestion de la conformite) qui liste les 93 mesures de l’Annex A. Chaque ligne represente une mesure avec des colonnes pour : reference de la mesure, titre de la mesure, inclusion/exclusion, justification, statut de mise en oeuvre, reference(s) de risque(s) et proprietaire.

Ne sautez pas de mesures. Chacune des 93 doit avoir une ligne et une decision. Les auditeurs verifieront l’exhaustivite.

Etape 2 : Relier votre plan de traitement des risques aux mesures de l’Annex A

Prenez votre plan de traitement des risques — qui liste chaque risque et les actions de traitement que vous avez decidees — et associez chaque action de traitement a une ou plusieurs mesures de l’Annex A.

Exemple de correspondance :

Risque	Action de traitement	Mesure Annex A
RISK-001 : Acces non autorise a la base de donnees de production	Mettre en oeuvre le MFA pour tous les acces de production	A.8.5 (Authentification securisee)
RISK-001 : Acces non autorise a la base de donnees de production	Appliquer le controle d’acces base sur les roles avec le moindre privilege	A.5.15 (Controle d’acces), A.8.3 (Restriction d’acces a l’information)
RISK-001 : Acces non autorise a la base de donnees de production	Mener des revues d’acces trimestrielles	A.5.18 (Droits d’acces)
RISK-002 : Violation de donnees via vulnerabilite logicielle	Mettre en oeuvre l’analyse de vulnerabilites dans le CI/CD	A.8.8 (Gestion des vulnerabilites techniques), A.8.29 (Tests de securite)
RISK-002 : Violation de donnees via vulnerabilite logicielle	Imposer la revue de code pour tous les changements	A.8.25 (Cycle de vie de developpement securise)
RISK-003 : Violation d’un fournisseur exposant les donnees clients	Mener des evaluations de securite des fournisseurs	A.5.19 (Relations avec les fournisseurs)
RISK-003 : Violation d’un fournisseur exposant les donnees clients	Inclure des exigences de securite dans les contrats fournisseurs	A.5.20 (Accords avec les fournisseurs)

Cette correspondance identifie quelles mesures de l’Annex A sont « necessaires » — elles sont incluses parce qu’elles traitent directement des risques identifies.

Etape 3 : Identifier les mesures requises par la loi, la reglementation ou le contrat

Certaines mesures de l’Annex A sont necessaires non pas a cause d’un risque specifique dans votre registre mais a cause d’obligations legales, reglementaires ou contractuelles.

Exemples :

• A.5.34 (Vie privee et protection des DCP) — requise si vous traitez des donnees personnelles soumises au RGPD ou a d’autres reglementations sur la vie privee
• A.5.31 (Exigences legales, statutaires et reglementaires) — requise pour toutes les organisations afin d’identifier les exigences legales applicables
• A.5.28 (Collecte de preuves) — peut etre requise par des reglementations sectorielles imposant la preparation a la forensique
• A.8.24 (Utilisation de la cryptographie) — les exigences de chiffrement peuvent etre des obligations contractuelles dans les accords clients entreprise

Marquez ces mesures comme incluses avec la justification appropriee (exigence legale, obligation contractuelle).

Etape 4 : Examiner les mesures restantes pour leur applicabilite

Apres avoir associe les actions de traitement des risques et les exigences legales/contractuelles, certaines mesures de l’Annex A peuvent ne pas encore etre traitees. Pour chaque mesure restante, determinez si elle est applicable a votre organisation :

• La mesure traite-t-elle un risque qui existe dans votre environnement ? Si oui, vous avez peut-etre une lacune dans votre evaluation des risques — envisagez si le risque devrait etre ajoute a votre registre, ou si les mesures existantes le traitent deja sous une reference differente de l’Annex A.
• La mesure est-elle pertinente pour vos operations, votre technologie ou votre modele commercial ? Les entreprises SaaS cloud-natives peuvent trouver certaines mesures physiques veritablement inapplicables. Mais soyez prudent avec les exclusions — les auditeurs les scrutent.
• L’exclusion de la mesure creerait-elle une lacune de securite ? Si exclure une mesure signifie qu’aucune action ne traite une menace pertinente, l’exclusion est inappropriee.

Etape 5 : Documenter les justifications

Pour chaque mesure — incluse et exclue — redigez une justification claire et specifique. C’est l’etape la plus chronophage mais aussi la plus importante pour la preparation a l’audit.

Spectre de qualite des justifications :

Faible (declenchera des questions d’audit) :

• « Incluse — requise pour la securite »
• « Exclue — non applicable »
• « Incluse — bonne pratique »

Acceptable (satisfait les exigences minimales) :

• « Incluse — traite le risque d’acces non autorise aux systemes de production (RISK-2026-003) »
• « Exclue — l’organisation n’a pas de centre de donnees physique ; toute l’infrastructure est hebergee dans le cloud »

Forte (demontre un ISMS mature et pilote par les risques) :

• « Incluse — traite RISK-2026-003 (acces non autorise aux systemes de production via compromission d’identifiants, note Eleve). Mise en oeuvre via l’application du MFA Okta pour tous les acces de production, l’integration SSO avec AWS IAM Identity Center et les politiques de gestion de session exigeant une reauthentification apres 12 heures d’inactivite. Derniere verification lors de la revue d’acces du T3 2026. »
• « Exclue — l’organisation n’exploite aucun centre de donnees physique ni salle de serveurs. Toute l’infrastructure de production est hebergee sur AWS dans les regions eu-west-1 et eu-central-1, ou la securite du cablage physique est geree par AWS sous certification SOC 2 Type II (rapport examine annuellement dans le cadre de A.5.22). Le reseau de bureau se compose d’equipements commerciaux standard ne traitant aucune donnee sensible. Risque residuel de cette exclusion : negligeable. »

Etape 6 : Enregistrer le statut de mise en oeuvre

Pour chaque mesure incluse, evaluez et documentez le statut actuel de mise en oeuvre. Soyez honnete — declarer un statut de mise en oeuvre inexact et se faire prendre pendant l’audit est bien pire que de reconnaitre qu’une mesure est encore en cours de mise en oeuvre.

Exemples de statut de mise en oeuvre :

• A.8.5 (Authentification securisee) — Mise en oeuvre. MFA applique via Okta pour tous les systemes internes. SSO configure pour AWS, GitHub, Datadog et Jira. Cles de securite materielles delivrees a tous les ingenieurs avec acces de production. Derniere revue de configuration : janvier 2026.

• A.8.12 (Prevention des fuites de donnees) — Partiellement mise en oeuvre. DLP endpoint deploye sur tous les ordinateurs portables geres par l’entreprise (CrowdStrike Falcon). Regles DLP email actives dans Google Workspace. Surveillance DLP au niveau API planifiee pour le T2 2026 (date cible d’achevement : mai 2026).

• A.8.11 (Masquage des donnees) — Planifiee. Evaluation de l’outil de masquage des donnees terminee. Solution selectionnee : Tonic.ai. Mise en oeuvre programmee pour le T2 2026, en commencant par le pipeline de rafraichissement des donnees de l’environnement de staging. Date cible d’achevement : juin 2026.

Etape 7 : Assigner les proprietaires

Assignez un individu nomme (pas une equipe ou un role) comme proprietaire de chaque mesure. Le proprietaire est responsable de :

• S’assurer que la mesure est mise en oeuvre comme documente
• Maintenir les preuves du fonctionnement de la mesure
• Rendre compte de l’efficacite de la mesure lors des revues de direction
• Mettre a jour la mesure lorsque les risques, les exigences ou l’environnement changent

Pour les entreprises SaaS, la propriete des mesures suit generalement ce schema :

Theme des mesures	Proprietaire typique
A.5 Organisationnelles (gouvernance, politiques)	RSSI / Responsable securite
A.5 Organisationnelles (gestion des fournisseurs)	Responsable gestion fournisseurs / Achats
A.6 Personnel	Responsable RH / Operations RH
A.7 Physiques	Responsable de bureau / Installations
A.8 Technologiques (infrastructure)	Responsable ingenierie plateforme / infrastructure
A.8 Technologiques (application)	Responsable ingenierie / CTO
A.8 Technologiques (terminaux)	Responsable operations informatiques

Etape 8 : Examiner et approuver

La SoA terminee doit etre examinee et approuvee par la direction — generalement le proprietaire du ISMS (RSSI), le representant de la direction ou le comite des risques. L’approbation demontre que la direction a examine et accepte la selection des mesures, les decisions d’exclusion et le statut actuel de mise en oeuvre.

Documentez l’approbation avec :

• Nom et role de l’approbateur
• Date d’approbation
• Numero de version — la SoA est un document versionne qui evolue dans le temps
• Date de prochaine revue — quand la SoA sera formellement revue (au minimum, annuellement)

La SoA comme document vivant

La Declaration d’Applicabilite n’est pas un livrable ponctuel que vous creez pour la certification et rangez. C’est un document vivant qui doit etre mis a jour chaque fois que votre ISMS change.

Declencheurs de mise a jour de la SoA

Changements de l’evaluation des risques. Lorsque de nouveaux risques sont identifies, que des risques existants sont reevalues ou que les plans de traitement des risques changent, la SoA doit etre mise a jour pour refleter tout changement dans la selection des mesures ou les justifications. Si votre evaluation annuelle des risques identifie de nouvelles menaces necessitant des mesures supplementaires, ces mesures sont ajoutees a la SoA.

Progression de la mise en oeuvre des mesures. A mesure que les mesures passent de « planifiee » a « partiellement mise en oeuvre » a « mise en oeuvre », mettez a jour la SoA pour refleter le statut actuel. C’est particulierement important dans la periode entre la creation initiale de la SoA et l’audit de certification de Stage 2.

Changements organisationnels. De nouveaux produits, services, marches ou modeles commerciaux peuvent introduire de nouveaux risques ou rendre pertinentes des mesures precedemment exclues. Si votre entreprise SaaS lance un produit qui traite des donnees de sante, les mesures liees a la conformite reglementaire (A.5.31, A.5.34) peuvent necessiter une justification mise a jour.

Changements reglementaires. De nouvelles lois ou reglementations mises a jour peuvent necessiter des mesures supplementaires ou modifier la justification des mesures existantes.

Constatations d’audit. Si votre audit interne ou un audit de surveillance identifie des lacunes, la SoA peut necessiter des mises a jour pour ajouter des mesures, renforcer les justifications ou corriger les declarations de statut de mise en oeuvre.

Changements technologiques. Migrer de fournisseur cloud, adopter de nouveaux outils de developpement ou modifier votre architecture peut affecter quelles mesures sont applicables et comment elles sont mises en oeuvre.

Controle de version

Maintenez un historique des versions de la SoA :

Version	Date	Auteur	Changements	Approuve par
1.0	2026-01-15	Jane Smith, RSSI	SoA initiale pour la certification	John Doe, CTO
1.1	2026-04-20	Jane Smith, RSSI	Statut A.8.12 mis a jour a Mise en oeuvre ; ajout de la correspondance RISK-2026-042 a A.5.23	John Doe, CTO
1.2	2026-07-10	Jane Smith, RSSI	Revue annuelle ; justifications mises a jour pour A.7.1-A.7.6 suite au demenagement des bureaux	John Doe, CTO

Cadence de revue

• Minimum : Revue annuelle alignee sur le cycle de revue de direction
• Recommande : Revue trimestrielle alignee sur les revues du registre des risques
• Declenchee : Mise a jour dans les 30 jours suivant des changements significatifs (nouveaux risques, constatations d’audit, changements organisationnels)

SoA vs. Plan de traitement des risques : comprendre la difference

La SoA et le plan de traitement des risques sont etroitement lies mais servent des objectifs differents. Les confondre — ou les traiter comme interchangeables — est une erreur courante.

Plan de traitement des risques

Objectif : Documente comment chaque risque identifie sera traite (attenuer, transferer, eviter, accepter) et les actions specifiques planifiees.

Contenu :

• Chaque risque necessitant un traitement
• Option de traitement selectionnee
• Actions de traitement specifiques
• Proprietaire et dates cibles
• Risque residuel attendu apres traitement

Focus : Centre sur les risques. Organise autour des risques, pas des mesures.

Public : Proprietaires de risques, direction, auditeurs (pour verifier les decisions de traitement).

Declaration d’Applicabilite

Objectif : Documente quelles mesures sont dans le perimetre du ISMS, avec justification d’inclusion et d’exclusion.

Contenu :

• Chaque mesure de l’Annex A (les 93)
• Decision d’inclusion/exclusion avec justification
• Statut de mise en oeuvre
• References de risques (tracant les mesures vers les risques)
• Proprietaires des mesures

Focus : Centre sur les mesures. Organise autour de la structure des mesures de l’Annex A.

Public : Auditeurs (reference principale pendant la certification), direction, equipes de mise en oeuvre.

Comment ils se connectent

Le plan de traitement des risques est une entree de la SoA. Quand votre plan de traitement des risques dit « attenuer RISK-001 en mettant en oeuvre le MFA », la SoA enregistre que A.8.5 (Authentification securisee) est incluse parce qu’elle traite RISK-001, et note son statut de mise en oeuvre.

La relation est de type plusieurs-a-plusieurs :

• Un risque peut necessiter plusieurs mesures (RISK-001 correspond a A.5.15, A.5.18, A.8.3, A.8.5)
• Une mesure peut traiter plusieurs risques (A.8.15 Journalisation traite les risques lies a l’acces non autorise, la detection d’incidents, la preparation forensique et la conformite)

Les deux documents doivent etre coherents. Si le plan de traitement des risques dit qu’un risque est attenuer par des mesures specifiques, la SoA doit montrer ces mesures comme incluses. Si la SoA exclut une mesure, aucun risque dans le plan de traitement ne devrait dependre de cette mesure pour l’attenuation.

Non-conformites courantes de la SoA lors des audits

Comprendre ce que les auditeurs recherchent vous aide a eviter les constatations les plus courantes.

Non-conformite 1 : Justifications manquantes ou incompletes

La constatation : Les mesures sont marquees comme incluses ou exclues sans justification adequate. La SoA dit « Incluse » ou « Exclue » mais n’explique pas pourquoi.

Pourquoi c’est important : Sans justification, l’auditeur ne peut pas verifier que votre selection de mesures est pilotee par les risques. Cela donne l’impression que les mesures ont ete selectionnees arbitrairement ou copiees d’un modele.

Comment l’eviter : Redigez des justifications specifiques qui referent aux identifiants de risques, aux exigences legales ou aux obligations contractuelles. Pour les exclusions, expliquez pourquoi le risque que la mesure traite n’est pas applicable a votre organisation.

Non-conformite 2 : Mesures exclues sans justification valable

La constatation : Des mesures sont exclues avec des justifications qui ne resistent pas a l’examen. Par exemple, exclure A.8.8 (Gestion des vulnerabilites techniques) avec la justification « gere par le fournisseur cloud » alors que l’organisation execute du code applicatif personnalise qui est clairement dans le perimetre de la gestion des vulnerabilites.

Pourquoi c’est important : Des exclusions invalides suggerent soit un manque de comprehension des mesures, soit une tentative de reduire la charge de mise en oeuvre en excluant des mesures applicables.

Comment l’eviter : Avant d’exclure toute mesure, demandez-vous : « Y a-t-il un scenario dans le perimetre de notre ISMS ou le risque que cette mesure traite pourrait se materialiser ? » Si oui, la mesure devrait probablement etre incluse. Le modele de responsabilite partagee avec les fournisseurs cloud est une source courante de confusion — votre fournisseur cloud gere la securite physique, mais vous gerez la securite applicative, le controle d’acces, la configuration et la plupart des autres mesures.

Non-conformite 3 : Statut de mise en oeuvre declare inexact

La constatation : La SoA declare qu’une mesure est « Mise en oeuvre » mais l’auditeur ne trouve aucune preuve de mise en oeuvre, ou la mise en oeuvre ne repond pas a l’intention de la mesure.

Pourquoi c’est important : Declarer un statut de mise en oeuvre inexact sape la credibilite de l’ensemble de la SoA et peut resulter en une non-conformite majeure.

Comment l’eviter : Soyez honnete sur le statut de mise en oeuvre. « Partiellement mise en oeuvre » ou « Planifiee avec date cible » est bien mieux que de pretendre une mise en oeuvre complete qui ne peut pas etre demontree. Les auditeurs respectent la transparence et travaillent avec les organisations pour combler les lacunes — ils ne respectent pas les declarations inexactes.

Non-conformite 4 : SoA non mise a jour apres des changements

La constatation : La SoA reflete l’etat du ISMS a un moment qui ne correspond plus a la realite. De nouveaux risques ont ete identifies, des mesures ont ete mises en oeuvre ou supprimees, mais la SoA n’a pas ete mise a jour.

Pourquoi c’est important : Une SoA obsolete indique que le document est traite comme un artefact de certification ponctuel plutot que comme une partie vivante du ISMS. Cela signifie egalement que l’auditeur ne peut pas se fier a la SoA comme representation fidele de l’environnement de mesures.

Comment l’eviter : Etablissez une cadence de revue (trimestrielle recommandee) et des declencheurs pour les mises a jour ponctuelles. Incluez la maintenance de la SoA comme point de l’ordre du jour des revues de direction.

Non-conformite 5 : Pas de tracabilite entre l’evaluation des risques et la SoA

La constatation : Le registre des risques identifie certains risques, mais la SoA n’inclut pas de mesures qui traitent ces risques. Ou la SoA inclut des mesures sans reference aux risques qu’elles traitent.

Pourquoi c’est important : La tracabilite est le principe fondamental d’ISO 27001. La norme exige une approche de selection des mesures pilotee par les risques. Sans tracabilite, il n’y a aucune preuve que l’approche est pilotee par les risques.

Comment l’eviter : Incluez les identifiants de reference des risques dans la colonne de justification de la SoA. Lors de la revue de la SoA, verifiez par recoupement avec le registre des risques que chaque risque au-dessus du seuil d’acceptation a des mesures correspondantes, et que chaque mesure incluse a une raison documentee d’inclusion.

Non-conformite 6 : Mesures de l’Annex A non completement traitees

La constatation : La SoA ne liste pas les 93 mesures de l’Annex A. Certaines mesures sont simplement absentes du document.

Pourquoi c’est important : La clause 6.1.3 d) exige que l’organisation determine « toutes les mesures necessaires » et les compare avec l’Annex A pour verifier que rien n’a ete neglige. Si des mesures manquent dans la SoA, il n’y a aucune preuve qu’elles ont ete considerees.

Comment l’eviter : Commencez avec une liste complete des 93 mesures et traitez chacune. Utilisez un modele ou un outil de conformite qui impose l’exhaustivite.

Non-conformite 7 : La SoA et les mesures reelles ne correspondent pas

La constatation : La SoA documente certaines mesures, mais la mise en oeuvre reelle differe. Par exemple, la SoA dit que le MFA est mis en oeuvre pour tous les utilisateurs, mais l’auditeur constate que les comptes de service contournent le MFA.

Pourquoi c’est important : La SoA est censee representer fidelement l’environnement de mesures. Les ecarts indiquent soit que la SoA est aspirationnelle plutot que factuelle, soit que les mesures ont derive depuis la derniere mise a jour de la SoA.

Comment l’eviter : Validez la SoA par rapport a la mise en oeuvre reelle avant les audits. Menez une revue interne ou quelqu’un (pas le proprietaire de la mesure) verifie que chaque mesure « Mise en oeuvre » fonctionne reellement comme decrit.

Construire une SoA pratique : format et structure

Format tableur

Le format le plus courant est un tableur avec les colonnes suivantes :

Colonne	Contenu
Reference de la mesure	A.5.1 a A.8.34
Titre de la mesure	Nom complet de la mesure de l’Annex A
Applicable ?	Oui / Non
Justification	Raison de l’inclusion ou de l’exclusion
Reference(s) de risque(s)	Identifiants de risques du registre des risques
Statut de mise en oeuvre	Mise en oeuvre / Partielle / Planifiee / Non commencee
Details de mise en oeuvre	Comment la mesure est mise en oeuvre (bref)
Reference de preuve	Ou trouver les preuves de mise en oeuvre
Proprietaire	Individu nomme responsable
Derniere revue	Date de la derniere revue
Notes	Contexte supplementaire pour les auditeurs

Organisation par theme

Organisez la SoA en suivant la structure de l’Annex A : A.5 Organisationnelles, A.6 Personnel, A.7 Physiques, A.8 Technologiques. Au sein de chaque theme, listez les mesures par ordre numerique. Cela facilite la navigation pour les auditeurs et le recoupement avec la norme.

Niveau de detail

Trouvez un equilibre entre exhaustivite et maintenabilite. La justification doit etre suffisamment specifique pour demontrer une prise de decision pilotee par les risques mais suffisamment concise pour que le document reste utilisable. Une justification d’une ligne par mesure est generalement trop breve. Un paragraphe complet par mesure est generalement suffisant. Une page par mesure est excessif et rendra le document impossible a maintenir.

Exemples d’entrees SoA

Mesure incluse avec justification par le risque :

Champ	Contenu
Reference	A.8.5
Titre	Authentification securisee
Applicable	Oui
Justification	Traite RISK-2026-003 (compromission d’identifiants menant a un acces non autorise) et RISK-2026-015 (prise de controle de compte basee sur le phishing). Egalement une exigence contractuelle dans les DPA clients entreprise.
Ref. risque	RISK-2026-003, RISK-2026-015
Statut	Mise en oeuvre
Mise en oeuvre	MFA via Okta pour tous les systemes internes. Integration SSO avec AWS, GitHub, Datadog. Cles de securite materielles pour l’acces de production. Expiration de session : 12 heures.
Preuve	Rapport d’inscription MFA Okta, captures d’ecran de configuration SSO, inventaire des cles materielles
Proprietaire	Sarah Chen, Responsable informatique
Revue	2026-02-15

Mesure exclue avec justification :

Champ	Contenu
Reference	A.7.12
Titre	Securite du cablage
Applicable	Non
Justification	L’organisation n’exploite aucun centre de donnees physique, salle de serveurs ou infrastructure reseau au-dela de l’equipement de bureau standard. Toute l’infrastructure de production est hebergee sur AWS (eu-west-1, eu-central-1), ou la securite du cablage physique est geree par AWS sous leur certification SOC 2 Type II. Le reseau de bureau utilise la connectivite sans fil pour les appareils des employes sans traitement de donnees sensibles sur site.
Ref. risque	N/A
Statut	N/A
Mise en oeuvre	N/A
Preuve	N/A
Proprietaire	N/A
Revue	2026-02-15

SoA pour les entreprises SaaS : considerations pratiques

Modele de responsabilite partagee du cloud

De nombreuses entreprises SaaS ont du mal a gerer les mesures relevant du modele de responsabilite partagee du fournisseur cloud. Le principe cle : vous ne pouvez pas exclure une mesure simplement parce que votre fournisseur cloud en gere une partie. Vous pouvez referer aux mesures du fournisseur cloud dans votre mise en oeuvre, mais la mesure est toujours applicable a votre organisation.

Exemple : A.7.5 (Protection contre les menaces physiques et environnementales) est principalement geree par AWS pour l’infrastructure de production. Mais la mesure n’est pas exclue — elle est incluse avec la justification : « Pour l’infrastructure de production, la protection physique et environnementale est fournie par AWS, verifiee par la revue annuelle du rapport SOC 2 Type II d’AWS (A.5.22). Pour les locaux de bureau, les systemes de detection et de suppression d’incendie sont maintenus par le proprietaire du batiment, verifies par la revue annuelle du bail. »

Alignement multi-referentiel

Si votre entreprise SaaS vise egalement le SOC 2, aligner votre SoA avec les criteres des services de confiance SOC 2 peut reduire la duplication. De nombreuses mesures de l’Annex A correspondent directement aux criteres communs SOC 2. Votre SoA peut noter ces correspondances pour demontrer un cadre de mesures unifie.

Evolution de la SoA avec la croissance

A mesure que votre entreprise SaaS grandit, votre SoA evoluera :

• Phase initiale (< 50 employes) : Plus de mesures peuvent etre « Planifiees » ou « Partiellement mises en oeuvre ». Concentrez-vous sur la bonne structure et construisez vers une mise en oeuvre complete.
• Phase de croissance (50-200 employes) : La plupart des mesures devraient etre mises en oeuvre. Commencez a formaliser les processus qui etaient precedemment geres de maniere informelle. Ajoutez des mesures de gestion des fournisseurs a mesure que votre ecosysteme de fournisseurs grandit.
• Phase d’envergure (200+ employes) : Mise en oeuvre complete attendue. Concentrez-vous sur la collecte de preuves, la surveillance continue et la mesure de l’efficacite des mesures. Envisagez d’ajouter des mesures au-dela de l’Annex A pour les menaces avancees.

SoA et audit interne

Votre programme d’audit interne utilise la SoA comme base de planification de l’audit. L’auditeur interne verifie que :

• Chaque mesure incluse est mise en oeuvre comme decrit
• Les justifications d’exclusion restent valables
• Le statut de mise en oeuvre est exact
• Les preuves soutiennent les declarations de la SoA
• La SoA reflete les risques et mesures actuels

Les constatations d’audit interne devraient alimenter les mises a jour de la SoA, creant une boucle d’amelioration continue.

Comment GRCTrail peut vous aider

GRCTrail fournit aux equipes SaaS une approche structuree et prete pour l’audit pour creer et maintenir la Declaration d’Applicabilite.

• Generation automatisee de la SoA qui fait correspondre les resultats de votre evaluation des risques aux 93 mesures de l’Annex A, pre-remplissant les justifications basees sur vos risques identifies et decisions de traitement afin que vous partiez d’un document pilote par les risques plutot que d’un tableur vierge
• Suivi de la mise en oeuvre des mesures avec liaison aux preuves, de sorte que chaque entree de la SoA soit connectee aux details de mise en oeuvre, aux proprietaires assignes et aux preuves justificatives — donnant aux auditeurs la tracabilite qu’ils recherchent sans recoupement manuel
• Gestion de document vivant avec controle de version, suivi des changements et rappels de revue automatises qui maintiennent votre SoA a jour entre les audits plutot que de la laisser devenir un artefact de certification obsolete

Demarrer avec GRCTrail →

Guides connexes

• Qu’est-ce qu’ISO 27001 ? Un guide pour les entreprises SaaS
• Evaluation des risques ISO 27001 : processus, methodologie et exemples
• Mesures de l’Annex A ISO 27001 : guide complet des 93 mesures
• Checklist de certification ISO 27001
• Guide d’audit interne ISO 27001
• Exigences ISO 27001 : comprendre les clauses 4 a 10