Politiques ISO 27001 : quelles politiques sont necessaires et comment les rediger

Les politiques sont la colonne vertebrale de tout Systeme de Management de la Securite de l’Information (ISMS) ISO 27001. Elles traduisent les intentions de la direction en matiere de securite en engagements documentes qui guident le comportement des employes, definissent les objectifs des mesures et donnent aux auditeurs quelque chose de concret a evaluer. Sans politiques bien structurees et applicables, votre ISMS n’existe qu’en theorie.

De nombreuses entreprises SaaS abordent les politiques ISO 27001 de la mauvaise maniere. Elles telechargeent des modeles generiques, remplacent le nom de l’entreprise et supposent que c’est termine. Cela cree deux problemes. Premierement, les politiques ne refletent pas le fonctionnement reel de l’organisation, ce qui signifie que les employes les ignorent. Deuxiemement, les auditeurs de certification repereent immediatement le decalage — ils ont vu les memes modeles des centaines de fois et savent quand une politique n’a pas ete redigee pour l’organisation qui la presente.

Ce guide couvre les exigences en matiere d’informations documentees dans ISO 27001, chaque politique obligatoire et recommandee, comment structurer et rediger des politiques qui fonctionnent pour les entreprises SaaS, et comment gerer le cycle de vie d’approbation, de communication et de revue que la norme exige.

Ce que dit ISO 27001 sur les informations documentees

ISO 27001 utilise le terme « informations documentees » plutot que « documents » ou « enregistrements ». C’est delibere — la norme ne prescrit pas de formats de documents, de conventions de nommage ou de structures specifiques. Elle exige que certaines informations soient documentees, maintenues et controlees, mais la facon dont vous organisez ces informations depend de vous.

La clause 7.5 etablit les exigences generales pour les informations documentees. Elle stipule que votre ISMS doit inclure les informations documentees requises par la norme elle-meme, plus toute information documentee supplementaire que votre organisation determine comme necessaire a l’efficacite du ISMS.

Ce que la norme exige explicitement

Les informations documentees suivantes sont directement exigees par les clauses d’ISO 27001:2022 :

• Perimetre du ISMS (clause 4.3) — Les limites et l’applicabilite de votre ISMS
• Politique de securite de l’information (clause 5.2) — La politique de haut niveau exprimant l’orientation de la direction
• Processus d’evaluation des risques (clause 6.1.2) — Comment vous identifiez, analysez et evaluez les risques de securite de l’information
• Processus de traitement des risques (clause 6.1.3) — Comment vous selectionnez et mettez en oeuvre des mesures pour traiter les risques identifies
• Objectifs de securite de l’information (clause 6.2) — Objectifs mesurables pour votre programme de securite
• Preuves de competence (clause 7.2) — Preuve que les personnes effectuant un travail lie a la securite sont competentes
• Planification et controle operationnels (clause 8.1) — Documentation des processus necessaires pour satisfaire les exigences de securite
• Resultats de l’evaluation des risques (clause 8.2) — Resultats des evaluations de risques terminees
• Resultats du traitement des risques (clause 8.3) — Resultats des activites de traitement des risques
• Resultats de surveillance et de mesure (clause 9.1) — Preuves d’evaluation de la performance
• Programme et resultats d’audit interne (clause 9.2) — Plans, criteres, perimetre et constatations d’audit
• Resultats de revue de direction (clause 9.3) — Resultats des reunions de revue de direction
• Non-conformites et actions correctives (clause 10.1) — Enregistrements des problemes trouves et comment ils ont ete traites
• Declaration d’Applicabilite (clause 6.1.3 d) — Liste de toutes les mesures de l’Annex A avec justification d’inclusion ou d’exclusion

C’est l’ensemble minimal. La plupart des organisations ont besoin de significativement plus d’informations documentees pour demontrer que leur ISMS fonctionne efficacement.

La Declaration d’Applicabilite comme carte des politiques

La Declaration d’Applicabilite (SoA) merite une attention particuliere car elle fonctionne comme le pont entre vos decisions de traitement des risques et les politiques qui les mettent en oeuvre. Pour chaque mesure de l’Annex A que vous declarez applicable, vous avez besoin d’informations documentees decrivant comment cette mesure est mise en oeuvre. En pratique, cela signifie que votre SoA determine votre liste de politiques — chaque mesure applicable devrait etre tracable vers une politique, une procedure ou une norme qui la gouverne.

Politiques obligatoires

ISO 27001 ne fournit pas de liste numerotee de documents de politique requis. Au lieu de cela, certaines clauses et mesures de l’Annex A exigent implicitement ou explicitement une documentation au niveau politique. Les politiques suivantes sont considerees comme obligatoires pour la certification.

1. Politique de securite de l’information

Reference de clause : 5.2, A.5.1

C’est le document fondateur de votre ISMS. Il etablit l’engagement de l’organisation envers la securite de l’information, definit l’orientation de toutes les politiques subordonnees et est signe par la direction.

Ce qu’elle doit contenir :

• La finalite et le perimetre du ISMS
• Un engagement a satisfaire les exigences de securite applicables
• Un engagement a l’amelioration continue du ISMS
• Un cadre pour la definition des objectifs de securite de l’information
• L’attribution de la responsabilite globale de la securite de l’information

Ce qu’elle ne devrait pas contenir : Des procedures operationnelles detaillees, des configurations techniques specifiques ou des mises en oeuvre de mesures. La politique de securite de l’information est un document strategique. Gardez-la suffisamment haut niveau pour qu’elle n’ait pas besoin de changer chaque fois que vous modifiez une mesure technique.

Exemple SaaS : Votre politique de securite de l’information declare que l’organisation s’engage a proteger les donnees clients traitees via sa plateforme cloud, que les objectifs de securite sont revus trimestriellement par l’equipe dirigeante, et que le CTO est responsable du programme de securite de l’information. Elle reference l’ensemble complet des politiques subordonnees (controle d’acces, reponse aux incidents, etc.) sans dupliquer leur contenu.

Constatation d’audit courante : La politique existe mais n’a jamais ete revue ou mise a jour depuis sa creation initiale. Les auditeurs verifient les dates de revue. Si votre politique a trois ans et que votre entreprise a significativement change, ils la signaleront.

2. Methodologie d’evaluation et de traitement des risques

Reference de clause : 6.1.2, 6.1.3

Cette methodologie documentee definit comment votre organisation identifie, analyse, evalue et traite les risques de securite de l’information. Ce n’est pas le registre des risques lui-meme — c’est la description du processus qui garantit que les evaluations des risques sont coherentes et reproductibles.

Ce qu’elle doit contenir :

• Criteres d’identification des risques (ce qui constitue un risque, approche basee sur les actifs vs basee sur les scenarios)
• Methode d’analyse des risques (qualitative, quantitative ou semi-quantitative)
• Echelles de vraisemblance et d’impact avec des definitions claires pour chaque niveau
• Criteres d’evaluation des risques (comment vous determinez quels risques sont acceptables et lesquels necessitent un traitement)
• Criteres d’acceptation des risques et qui a l’autorite d’accepter le risque residuel
• Options de traitement des risques (attenuer, transferer, accepter, eviter) et criteres de selection

Pour un guide detaille du processus d’evaluation des risques, consultez notre guide d’evaluation des risques ISO 27001.

Exemple SaaS : Vous utilisez une matrice de risque qualitative 5x5. La vraisemblance est notee de Rare (1) a Quasi certaine (5) sur la base de donnees historiques et de renseignements sur les menaces. L’impact est note de Negligeable (1) a Critique (5) sur la base des consequences financieres, operationnelles, reputationnelles et reglementaires. Les risques avec un score de 15 ou plus necessitent un traitement. Les risques avec un score de 9-14 necessitent une justification documentee s’ils sont acceptes. Le CTO a l’autorite d’accepter les risques avec un score de 14 ou moins ; les risques avec un score de 15 ou plus necessitent l’approbation du PDG.

3. Declaration d’Applicabilite

Reference de clause : 6.1.3 d

La Declaration d’Applicabilite liste les 93 mesures de l’Annex A d’ISO 27001:2022 avec une determination de l’applicabilite de chacune, la justification d’inclusion ou d’exclusion, et une reference a la facon dont chaque mesure applicable est mise en oeuvre.

La SoA est l’un des documents les plus importants de votre ISMS. Les auditeurs l’utilisent comme feuille de route — ils selectionnent des mesures dans la SoA et testent si ces mesures sont mises en oeuvre et fonctionnent comme decrit.

Constatation d’audit courante : La SoA dit qu’une mesure est mise en oeuvre, mais la politique ou la procedure referencee n’existe pas, ou elle existe mais n’est pas suivie. Chaque affirmation de votre SoA doit etre verifiable.

4. Plan de traitement des risques

Reference de clause : 6.1.3, 8.3

Le plan de traitement des risques documente les actions specifiques que vous prendrez pour traiter les risques qui depassent vos criteres d’acceptation. Pour chaque risque necessitant un traitement, le plan identifie les mesures a mettre en oeuvre, la personne responsable, le calendrier et les ressources necessaires.

Ce qu’il doit contenir :

• Les risques identifies necessitant un traitement (lies au registre des risques)
• L’option de traitement selectionnee pour chaque risque
• Les mesures a appliquer (referencant l’Annex A ou d’autres sources)
• Le proprietaire de la mise en oeuvre et le calendrier
• Le risque residuel attendu apres traitement
• Le suivi du statut

Politiques recommandees pour les entreprises SaaS

Au-dela des informations documentees obligatoires, les entreprises SaaS poursuivant la certification ISO 27001 ont besoin de politiques supplementaires pour satisfaire les mesures de l’Annex A et demontrer un ISMS mature. L’ensemble exact depend de votre SoA, mais les politiques suivantes sont attendues par pratiquement tous les auditeurs de certification.

5. Politique de controle d’acces

Reference Annex A : A.5.15 (Controle d’acces), A.5.16 (Gestion des identites), A.5.17 (Informations d’authentification), A.5.18 (Droits d’acces), A.8.2 (Droits d’acces privilegie), A.8.3 (Restriction d’acces a l’information), A.8.5 (Authentification securisee)

Le controle d’acces est l’un des domaines les plus testes lors de tout audit ISO 27001. Votre politique de controle d’acces definit comment l’organisation gere les identites des utilisateurs, l’authentification, l’autorisation et le cycle de vie complet des droits d’acces. Pour une analyse approfondie de la mise en oeuvre, consultez notre guide de controle d’acces ISO 27001.

Ce qu’elle couvre :

• Processus d’inscription et de desinscription des utilisateurs
• Modele de controle d’acces base sur les roles (RBAC) ou base sur les attributs (ABAC)
• Principe du moindre privilege
• Exigences d’authentification multi-facteurs (MFA)
• Gestion des acces privilegies (PAM)
• Gouvernance des comptes de service et des cles API
• Frequence et processus de revue periodique des acces
• Delai de desapprovisionnement lors d’un changement de role ou d’un depart

Exemple SaaS : Tous les acces a l’environnement de production necessitent le MFA. Les comptes de service sont provisionnes via Terraform avec des identifiants a duree limitee. Les revues d’acces sont menees trimestriellement a l’aide d’exports automatises de votre fournisseur d’identite. Le desapprovisionnement doit avoir lieu dans les 24 heures suivant la notification de depart.

6. Politique de gestion des actifs

Reference Annex A : A.5.9 (Inventaire des informations et autres actifs associes), A.5.10 (Utilisation acceptable), A.5.11 (Restitution des actifs), A.5.12 (Classification de l’information), A.5.13 (Etiquetage de l’information)

Cette politique gouverne l’identification, la classification, l’etiquetage et l’utilisation acceptable des actifs informationnels. Pour les entreprises SaaS, les « actifs » incluent l’infrastructure cloud, les depots de code, les bases de donnees, les outils SaaS et la propriete intellectuelle.

Ce qu’elle couvre :

• Exigences d’inventaire des actifs et frequence de maintenance
• Schema de classification de l’information (par exemple, Public, Interne, Confidentiel, Restreint)
• Regles d’etiquetage pour chaque niveau de classification
• Regles d’utilisation acceptable des actifs organisationnels (y compris BYOD)
• Procedures de restitution des actifs lors du depart d’un employe

Exemple SaaS : Vous classifiez les donnees en quatre niveaux. Les donnees de production des clients sont Restreintes. Les documents commerciaux internes sont Confidentiels. Les articles de blog de l’entreprise sont Publics. Chaque niveau de classification correspond a des exigences de traitement specifiques — les donnees Restreintes doivent etre chiffrees au repos et en transit, l’acces necessite l’approbation du proprietaire des donnees et elles ne peuvent pas etre stockees en dehors des environnements de production approuves.

7. Politique de securite des ressources humaines

Reference Annex A : A.6.1 (Verification des antecedents), A.6.2 (Termes et conditions d’emploi), A.6.3 (Sensibilisation a la securite de l’information), A.6.4 (Processus disciplinaire), A.6.5 (Responsabilites apres la fin ou le changement d’emploi)

Cette politique couvre les aspects de securite de l’ensemble du cycle de vie des employes — de la verification pre-emploi a l’integration, l’emploi en cours et le depart.

Ce qu’elle couvre :

• Exigences de verification des antecedents (perimetre et frequence)
• Obligations de confidentialite et de securite dans les contrats de travail
• Exigences de formation de sensibilisation a la securite (initiale et recurrente)
• Attentes de conduite acceptable et processus disciplinaire pour les violations
• Procedures de depart et de sortie (revocation des acces, restitution des actifs, transfert de connaissances)

Exemple SaaS : Tous les employes font l’objet d’une verification des antecedents avant leur date de debut. La formation de sensibilisation a la securite est completee dans la premiere semaine d’emploi et annuellement par la suite. Tous les employes signent un accord de confidentialite couvrant les donnees clients. En cas de depart, l’informatique est notifiee dans les 4 heures et tous les acces sont revoques avant la fin du dernier jour de travail de l’employe.

8. Politique de gestion des incidents

Reference Annex A : A.5.24 (Planification et preparation de la gestion des incidents de securite de l’information), A.5.25 (Evaluation et decision sur les evenements de securite de l’information), A.5.26 (Reponse aux incidents de securite de l’information), A.5.27 (Apprentissage des incidents de securite de l’information), A.5.28 (Collecte de preuves), A.6.8 (Signalement des evenements de securite de l’information)

Cette politique definit comment votre organisation detecte, signale, evalue, repond et tire les lecons des incidents de securite de l’information.

Ce qu’elle couvre :

• Definitions des evenements et incidents de securite (et la distinction entre eux)
• Schema de classification de gravite (par exemple, P1-P4)
• Canaux de signalement et responsabilites (qui signale quoi, a qui et avec quelle rapidite)
• Procedures d’escalade basees sur la gravite
• Etapes de confinement, d’eradication et de reprise
• Exigences de preservation des preuves
• Processus de revue post-incident
• Obligations de notification externe (regulateurs, clients, forces de l’ordre)

Exemple SaaS : Tout employe qui suspecte un evenement de securite le signale immediatement via le canal Slack #incidents-securite. L’ingenieur de securite de garde effectue le triage dans les 30 minutes. Les incidents P1 (violation de donnees confirmee, intrusion active) declenchent une salle de crise et necessitent la notification des clients dans les 72 heures. Chaque incident P1 et P2 fait l’objet d’un bilan ecrit dans les cinq jours ouvrables.

9. Politique de continuite d’activite

Reference Annex A : A.5.29 (Securite de l’information pendant une perturbation), A.5.30 (Preparation des TIC pour la continuite d’activite), A.8.13 (Sauvegarde de l’information), A.8.14 (Redondance des installations de traitement de l’information)

Cette politique etablit comment l’organisation maintient la securite de l’information pendant les evenements perturbateurs et garantit la disponibilite des services critiques.

Ce qu’elle couvre :

• Exigences d’analyse d’impact sur l’activite (BIA)
• Objectifs de temps de reprise (RTO) et objectifs de point de reprise (RPO) pour les services critiques
• Politique de sauvegarde (perimetre, frequence, retention, tests)
• Procedures de reprise apres sinistre
• Calendrier de tests et d’exercices
• Plan de communication pendant les perturbations

Exemple SaaS : Les bases de donnees de production sont sauvegardees toutes les heures avec un RPO de 1 heure et un RTO de 4 heures. Les sauvegardes sont stockees dans une region AWS separee et testees mensuellement par une restauration complete vers un environnement de staging. Des exercices de table ronde de reprise apres sinistre sont menes trimestriellement. La page de statut est mise a jour dans les 15 minutes suivant toute perturbation de service.

10. Politique fournisseurs et tiers

Reference Annex A : A.5.19 (Securite de l’information dans les relations avec les fournisseurs), A.5.20 (Traitement de la securite de l’information dans les accords avec les fournisseurs), A.5.21 (Gestion de la securite de l’information dans la chaine d’approvisionnement des TIC), A.5.22 (Surveillance, revue et gestion des changements des services fournisseurs), A.5.23 (Securite de l’information pour l’utilisation des services cloud)

Cette politique gouverne comment votre organisation evalue, integre, surveille et desinscrit les fournisseurs tiers qui accedent, traitent ou stockent vos donnees ou celles de vos clients.

Ce qu’elle couvre :

• Methodologie et frequence d’evaluation des risques fournisseurs
• Exigences de securite pour les accords fournisseurs (protection des donnees, notification des incidents, droits d’audit)
• Processus de diligence raisonnable pour les nouveaux fournisseurs (questionnaires de securite, revue des rapports SOC 2/ISO 27001)
• Cadence de surveillance continue (revue annuelle, surveillance continue pour les fournisseurs critiques)
• Gestion des sous-traitants
• Exigences de securite pour les fournisseurs de services cloud

Exemple SaaS : Tous les fournisseurs qui traitent des donnees clients font l’objet d’une evaluation de securite avant l’integration. Les fournisseurs critiques (infrastructure, identite, traitement des paiements) sont revus annuellement et doivent fournir un certificat SOC 2 Type II ou ISO 27001 en cours de validite. Les accords fournisseurs incluent des clauses de traitement des donnees, une notification de violation dans les 48 heures et le droit d’audit.

11. Politique de cryptographie

Reference Annex A : A.8.24 (Utilisation de la cryptographie)

Cette politique definit l’approche de l’organisation en matiere d’utilisation de mesures cryptographiques pour proteger la confidentialite, l’integrite et l’authenticite de l’information.

Ce qu’elle couvre :

• Exigences de chiffrement par niveau de classification des donnees
• Algorithmes cryptographiques approuves et longueurs de cles minimales
• Procedures de gestion des cles (generation, distribution, stockage, rotation, revocation, destruction)
• Exigences TLS/SSL pour les donnees en transit
• Exigences de chiffrement au repos
• Gestion des certificats

Exemple SaaS : Toutes les donnees en transit utilisent TLS 1.2 ou superieur. Les donnees clients au repos sont chiffrees avec AES-256. Les cles de chiffrement de base de donnees sont gerees via AWS KMS avec rotation annuelle automatique. Les cles SSH necessitent ED25519 ou RSA-4096. Les certificats sont geres via ACM avec renouvellement automatise.

12. Politique de securite physique

Reference Annex A : A.7.1 a A.7.14

Pour les entreprises SaaS operant entierement dans le cloud, la politique de securite physique est souvent limitee aux installations de bureau et aux terminaux des employes. La securite physique de l’infrastructure cloud est generalement couverte par les propres certifications du fournisseur cloud.

Ce qu’elle couvre :

• Controle d’acces aux bureaux (acces par badge, gestion des visiteurs)
• Zones securisees (salles de serveurs le cas echeant, zones de bureau restreintes)
• Securite des equipements (chiffrement des ordinateurs portables, verrouillage d’ecran, elimination securisee)
• Exigences de securite pour le travail a distance
• Politique de bureau net et d’ecran net

Exemple SaaS : Votre politique de securite physique reconnait que l’infrastructure de production fonctionne sur AWS (securite physique regie par les propres certifications ISO 27001 et SOC 2 d’AWS). La politique se concentre sur l’acces aux bureaux (entree par badge requise, les visiteurs doivent etre accompagnes et enregistres), la securite des terminaux (chiffrement FileVault/BitLocker obligatoire, verrouillage d’ecran apres 5 minutes), et le travail a distance (VPN requis pour l’acces aux outils internes, le travail ne doit pas etre effectue sur des ordinateurs publics).

13. Politique de securite operationnelle

Reference Annex A : A.8.6 (Gestion de la capacite), A.8.7 (Protection contre les logiciels malveillants), A.8.8 (Gestion des vulnerabilites techniques), A.8.9 (Gestion de la configuration), A.8.15 (Journalisation), A.8.16 (Activites de surveillance)

Cette politique couvre les mesures de securite operationnelle quotidiennes qui maintiennent vos systemes securises et observables.

Ce qu’elle couvre :

• Processus de gestion des changements et de deploiement
• Planification de la capacite
• Separation des environnements de developpement, de test et de production
• Protection contre les logiciels malveillants pour les terminaux
• Gestion des vulnerabilites (frequence d’analyse, SLA de correction par gravite)
• Exigences de journalisation et de surveillance
• Gestion de la configuration et bases de durcissement

Exemple SaaS : Les vulnerabilites critiques (CVSS 9.0+) doivent etre corrigees dans les 72 heures. Les vulnerabilites elevees (CVSS 7.0-8.9) dans les 30 jours. Tous les systemes de production envoient les journaux a un SIEM centralise avec une retention de 90 jours. Les environnements de developpement, de staging et de production sont isoles avec des comptes AWS separes. Un logiciel de detection et reponse aux terminaux (EDR) fonctionne sur tous les ordinateurs portables des employes.

14. Politique de securite des communications et de transfert de donnees

Reference Annex A : A.5.14 (Transfert d’information), A.8.20 (Securite des reseaux), A.8.21 (Securite des services reseau), A.8.22 (Segregation des reseaux), A.8.23 (Filtrage web)

Cette politique gouverne comment l’information est transferee au sein et en dehors de l’organisation, et comment la securite du reseau est maintenue.

Ce qu’elle couvre :

• Canaux approuves pour le transfert d’information par niveau de classification
• Exigences de securite des e-mails
• Regles de segmentation du reseau
• Securite du reseau sans fil
• Exigences d’acces a distance (VPN, zero trust)
• Accords de transfert de donnees avec des parties externes

Comment structurer une politique ISO 27001

Une structure de politique coherente n’est pas une exigence formelle, mais elle ameliore considerablement l’utilisabilite et demontre la maturite. Quand chaque politique suit le meme modele, les employes savent ou trouver les informations et les auditeurs peuvent naviguer dans votre documentation efficacement.

Sections de politique recommandees

1. Bloc de controle documentaire

Chaque politique devrait commencer par des metadonnees :

• Titre de la politique et identifiant unique (par exemple, POL-ISP-001)
• Numero de version
• Proprietaire de la politique (nom et role)
• Approbateur (nom et role)
• Date d’effet
• Date de prochaine revue
• Niveau de classification (generalement Interne ou Confidentiel)

2. Objet

Un a deux paragraphes expliquant pourquoi cette politique existe et quel probleme elle traite. Cela devrait repondre a : « Pourquoi devrais-je me soucier de cette politique ? »

Exemple : « Cette politique de controle d’acces etablit les exigences pour la gestion de l’acces des utilisateurs aux systemes d’information et aux donnees tout au long du cycle de vie des acces. Elle existe pour prevenir les acces non autorises, maintenir le principe du moindre privilege et garantir que les droits d’acces restent appropries lorsque les employes rejoignent, evoluent au sein ou quittent l’organisation. »

3. Perimetre

Definissez exactement a qui et a quoi la politique s’applique. Soyez precis sur les inclusions et les exclusions.

Exemple : « Cette politique s’applique a tous les employes, sous-traitants et utilisateurs tiers qui accedent aux systemes d’information de [Entreprise]. Elle couvre tous les systemes de production, les applications d’entreprise et les services cloud dans le perimetre du ISMS tel que defini dans la Declaration de perimetre du ISMS (DOC-ISMS-001). Elle ne couvre pas l’acces physique aux installations de bureau, qui est regi par la politique de securite physique (POL-PHY-001). »

4. Declarations de politique

Le coeur du document. Chaque declaration de politique devrait etre :

• Claire et non ambigue — Pas de place pour l’interpretation
• Mesurable — Vous pouvez determiner objectivement la conformite
• Realiste — Realisable avec les ressources et la technologie actuelles
• Attribuable — Quelqu’un est responsable de la conformite

Redigez les declarations de politique comme des exigences, pas des suggestions. Utilisez « doit » pour les exigences obligatoires, « devrait » pour les recommandations et « peut » pour les permissions.

5. Roles et responsabilites

Definissez qui est responsable de quoi. Utilisez des titres de role, pas des noms individuels, pour que la politique survive aux changements de personnel.

Exemple :

• Responsable de la securite de l’information : Maintient cette politique, mene les revues annuelles et rapporte le statut de conformite a la direction
• Equipe des operations informatiques : Met en oeuvre les mesures techniques definies dans cette politique
• Operations RH : Notifie l’informatique des departs d’employes dans les 4 heures
• Tous les employes : Respectent cette politique et signalent les violations suspectees

6. Documents connexes

Listez les normes, procedures et autres politiques qui soutiennent ou se connectent a cette politique. Cela cree la tracabilite au sein de votre cadre documentaire.

7. Definitions et abbreviations

Definissez tout terme qui pourrait etre ambigu. C’est particulierement important quand des publics techniques et non techniques lisent la politique.

8. Historique de revue et de revision

Un tableau montrant chaque revision : date, version, auteur et une breve description des changements.

Rediger des politiques pour les entreprises SaaS

Les entreprises SaaS ont des caracteristiques distinctes qui devraient fagonner la facon dont les politiques sont redigees. Ignorer ces caracteristiques produit des politiques qui sont techniquement conformes mais operationnellement inutiles.

Redigez pour votre flux de travail reel. Si votre equipe d’ingenierie deploie en production 20 fois par jour a l’aide d’un pipeline CI/CD, votre politique de gestion des changements devrait decrire ce processus — pas un comite consultatif traditionnel sur les changements qui se reunit chaque semaine. Les auditeurs ne penalisent pas les pratiques modernes. Ils penalisent les ecarts entre ce que vous documentez et ce que vous faites.

Soyez precis sur les services cloud. Les references generiques aux « serveurs » et « centres de donnees » signalent qu’une politique a ete redigee pour un autre type d’entreprise. Nommez vos fournisseurs cloud. Referencez des services specifiques (AWS RDS, Azure AD, GCP Cloud Run). Cette specificite aide les employes a comprendre ce que la politique signifie en pratique et aide les auditeurs a verifier la conformite.

Gardez les politiques concises. Une politique de controle d’acces de 50 pages signale la bureaucratie, pas la maturite. Les auditeurs et les employes preferent des documents qui sont complets mais pas verbeux. Si une section depasse une page, envisagez si le detail appartient a une procedure ou une norme de support plutot qu’a la politique elle-meme.

Utilisez le langage que votre equipe comprend. Si votre equipe utilise « deployer » au lieu de « livrer », utilisez « deployer ». Si elle dit « repo » au lieu de « depot », utilisez « repo ». Les politiques qui utilisent un langage inconnu sont ignorees.

Fixez des engagements realisables. Chaque declaration de politique devient une obligation testable. Si votre politique dit que les mots de passe doivent etre changes tous les 30 jours, vous devez prouver qu’ils le sont. Si votre politique dit que les revues d’acces ont lieu trimestriellement, vous avez besoin de quatre revues completees par an. La constatation d’audit la plus courante dans toutes les certifications ISO 27001 est que les organisations ne respectent pas leurs propres exigences declarees. Fixez des normes que vous pouvez respecter de maniere coherente, puis relevez-les au fil du temps grace a l’amelioration continue.

Approbation et communication

Approbation des politiques

La clause 5.2 exige que la politique de securite de l’information soit approuvee par la direction. En pratique, les auditeurs s’attendent a ce que toutes les politiques du ISMS passent par un processus d’approbation formel.

Qui approuve : L’approbateur doit etre quelqu’un avec une autorite suffisante pour engager l’organisation envers les exigences de la politique. Pour la politique de securite de l’information de haut niveau, c’est generalement le PDG, le CTO ou un membre de l’equipe dirigeante. Pour les politiques subordonnees, le responsable de la securite de l’information ou le CTO est generalement approprie.

Comment documenter l’approbation : Gardez les choses simples. Les options incluent :

• Signature numerique sur le document de politique
• Approbation enregistree dans votre systeme de gestion documentaire (avec horodatage et identite de l’approbateur)
• Confirmation par e-mail ou Slack capturee et stockee comme preuve
• Approbation via une plateforme GRC avec piste d’audit

Ce qui compte, c’est que vous puissiez demontrer qui a approuve la politique, quand il l’a approuvee et quelle version il a approuvee.

Communication des politiques

La clause 7.4 exige que vous communiquiez les informations pertinentes sur le ISMS aux parties internes et, le cas echeant, externes. Pour les politiques, cela signifie :

• Tous les employes doivent etre informes de l’existence des politiques
• Les employes doivent avoir acces aux politiques pertinentes pour leurs roles
• Les nouveaux employes doivent recevoir les informations sur les politiques lors de l’integration
• Les changements significatifs de politique doivent etre communiques lorsqu’ils surviennent

Approches pratiques pour les equipes SaaS :

• Stockez les politiques dans un emplacement centralise et accessible (Confluence, Notion, SharePoint ou une plateforme GRC)
• Envoyez une notification lorsque des politiques sont creees ou significativement mises a jour
• Incluez la revue des politiques dans la checklist d’integration
• Exigez une reconnaissance annuelle des politiques de tous les employes (documentee avec horodatages)

Constatation d’audit courante : Les politiques existent dans un systeme de gestion documentaire, mais les employes ne savaient pas qu’elles existaient ou ne pouvaient pas les trouver. Les auditeurs peuvent interroger des employes et demander ou ils trouveraient la politique de controle d’acces. Si l’employe ne peut pas repondre, c’est une lacune de communication.

Reconnaissance des politiques

Bien qu’ISO 27001 n’exige pas explicitement de reconnaissances signees, elles constituent une forme forte de preuve que la communication a eu lieu. La plupart des auditeurs de certification s’attendent a voir une forme de reconnaissance, en particulier pour les politiques critiques.

Mettez en place un systeme ou les employes reconnaissent electroniquement qu’ils ont lu et compris chaque politique. Suivez les dates de completion et relancez les employes qui n’ont pas complete leurs reconnaissances. Cette preuve est directement utile lors des audits.

Cadence de revue et cycle de vie

Frequence de revue obligatoire

ISO 27001 exige que les informations documentees soient revues et mises a jour selon les besoins (clause 7.5.2). Bien que la norme ne specifie pas de frequence minimale de revue, l’attente universelle est une revue annuelle au minimum.

Cadence recommandee :

• Revue annuelle : Chaque politique devrait etre revue au moins une fois par an, meme si aucun changement n’est necessaire. Documentez que la revue a eu lieu et que la politique a ete confirmee comme actuelle.
• Revue declenchee : Revoyez et mettez a jour les politiques lorsque des changements significatifs surviennent — restructuration organisationnelle, changements technologiques majeurs, nouvelles exigences reglementaires ou lecons tirees d’incidents de securite.
• Revue post-incident : Apres des incidents de securite significatifs, revoyez les politiques pertinentes pour determiner si des changements sont necessaires.

Le processus de revue

Une revue de politique ne consiste pas simplement a relire le document et a le signer. Une revue efficace comprend :

1. Verification de la pertinence : La politique traite-t-elle toujours les risques et le contexte commercial actuels ?
2. Verification de l’exactitude : Les declarations de politique correspondent-elles aux pratiques reelles ? Si les pratiques ont derive de la politique, mettez a jour soit la politique, soit corrigez les pratiques.
3. Verification de l’exhaustivite : De nouveaux risques, technologies ou reglementations sont-ils apparus que la politique devrait traiter ?
4. Contribution des parties prenantes : Consultez les equipes responsables de la mise en oeuvre de la politique. Elles savent ou sont les lacunes.
5. Approbation : Les politiques mises a jour passent par le meme processus d’approbation que les nouvelles politiques.
6. Communication : Si des changements ont ete apportes, notifiez les employes concernes et demandez des reconnaissances mises a jour.

Controle de version

Maintenez un historique de version clair pour chaque politique. Vous devez pouvoir montrer aux auditeurs quelle version etait en vigueur pendant une periode donnee. C’est particulierement important pendant la transition lorsque les politiques sont mises a jour — l’auditeur doit verifier que la version en vigueur pendant la periode d’audit etait celle qui etait suivie.

Utilisez un schema de versionnement coherent (par exemple, 1.0, 1.1, 2.0) et stockez les versions precedentes plutot que de les ecraser. Une plateforme GRC ou un systeme de gestion documentaire avec controle de version integre elimine le risque de perdre les versions historiques.

Correspondance des politiques aux mesures de l’Annex A

L’une des choses les plus utiles que vous puissiez faire lors de la construction de votre cadre de politiques est de creer une correspondance explicite entre vos politiques et les mesures de l’Annex A qu’elles traitent. Cette correspondance sert trois objectifs :

1. Assurance d’exhaustivite : Vous pouvez verifier que chaque mesure applicable de l’Annex A est traitee par au moins une politique
2. Efficacite d’audit : Les auditeurs peuvent rapidement trouver la politique pertinente pour toute mesure qu’ils veulent tester
3. Identification des lacunes : Vous pouvez identifier les mesures declarees applicables dans votre SoA mais depourvues de documentation de support

Exemple de correspondance

Mesure Annex A	Titre de la mesure	Politique principale	Procedure de support
A.5.1	Politiques pour la securite de l’information	Politique de securite de l’information	Procedure de gestion des politiques
A.5.9	Inventaire des informations et autres actifs associes	Politique de gestion des actifs	Procedure d’inventaire des actifs
A.5.15	Controle d’acces	Politique de controle d’acces	Procedure de provisionnement des utilisateurs
A.5.24	Planification de la gestion des incidents de securite de l’information	Politique de gestion des incidents	Procedure de reponse aux incidents
A.5.29	Securite de l’information pendant une perturbation	Politique de continuite d’activite	Procedure de reprise apres sinistre
A.8.24	Utilisation de la cryptographie	Politique de cryptographie	Procedure de gestion des cles

Maintenez cette correspondance comme un document vivant. Lorsque vous ajoutez ou modifiez l’applicabilite d’une mesure de l’Annex A dans votre SoA, mettez a jour simultanement la correspondance des politiques. Lorsque vous mettez a jour une politique, verifiez que la correspondance reflete toujours fidelement le contenu de la politique.

Politiques vs. procedures vs. normes

Comprenez la hierarchie et gardez les couches distinctes :

• Politiques declarent ce que l’organisation fera et pourquoi. Elles sont approuvees par la direction et definissent l’orientation. Elles changent rarement.
• Normes definissent des exigences specifiques et mesurables. Elles traduisent l’intention de la politique en reperes concrets. Exemple : « AES-256 pour les donnees au repos. »
• Procedures decrivent etape par etape comment effectuer une tache. Elles sont operationnelles et peuvent changer a mesure que les outils ou les processus evoluent.

Les auditeurs s’attendent a voir cette hierarchie refletee dans votre documentation. Quand une politique reference une procedure, la procedure devrait exister. Quand une procedure reference une norme, la norme devrait etre documentee. Les references cassees — des politiques qui pointent vers des procedures qui n’existent pas — sont une constatation courante.

Erreurs courantes en matiere de politiques et comment les eviter

Copier des modeles sans personnalisation

L’erreur la plus repandue. Les modeles generiques contiennent des references a des salles de serveurs physiques, des rotations de sauvegardes sur bande et des registres de visiteurs qui n’ont rien a voir avec une entreprise SaaS cloud-native. Chaque declaration de politique devrait decrire quelque chose que votre organisation fait reellement ou fera.

Correction : Utilisez les modeles comme cadre de depart, puis reecrivez chaque section pour correspondre a votre environnement, vos outils et vos flux de travail reels. Si une section ne s’applique pas, supprimez-la plutot que de la laisser comme texte aspirationnel.

Sur-engagement

Les organisations redigent des politiques qui decrivent un etat ideal plutot que leur capacite reelle. Une politique qui exige des revues de securite de chaque ligne de code, des tests de penetration hebdomadaires et une chasse aux menaces en temps reel semble impressionnante mais cree des obligations presque impossibles a maintenir.

Correction : Redigez des politiques qui refletent votre capacite actuelle, avec un plan clair pour relever la barre grace a l’amelioration continue. Il vaut bien mieux avoir des politiques realisables que vous respectez systematiquement que des politiques ambitieuses que vous violez systematiquement.

Sous-documentation

L’extreme oppose — des politiques si vagues qu’elles ne fournissent aucun conseil actionnable. « L’entreprise protegera ses donnees » est une declaration de vision, pas une politique.

Correction : Chaque declaration de politique devrait etre suffisamment specifique pour etre testee. Demandez-vous : « Un auditeur pourrait-il determiner si nous sommes conformes a cette declaration ? » Si la reponse est non, la declaration a besoin de plus de specificite.

Ignorer le cycle de revue

Les politiques sont redigees pendant la mise en oeuvre initiale du ISMS et jamais revisitees. Deux ans plus tard, l’entreprise a migre d’AWS a GCP, double de taille et lance trois nouveaux produits, mais les politiques decrivent toujours l’environnement d’origine.

Correction : Programmez des rappels de calendrier pour les revues annuelles. Assignez un proprietaire de politique pour chaque document qui est responsable de le maintenir a jour. Integrez la revue des politiques dans le perimetre de votre audit interne.

Ne pas relier les politiques aux preuves

Une politique existe, mais il n’y a pas de mecanisme pour prouver la conformite. La politique de controle d’acces exige des revues d’acces trimestrielles, mais personne ne mene les revues et il n’y a pas de registres.

Correction : Pour chaque declaration de politique, definissez quelles preuves demontreront la conformite et assurez-vous qu’un processus existe pour generer et conserver ces preuves. Lors de la construction de votre checklist de certification, tracez chaque exigence de politique vers sa source de preuves.

Isoler les politiques des operations

Les politiques vivent dans un espace Confluence que personne ne visite. L’equipe d’ingenierie n’a jamais lu la politique de gestion des changements parce qu’elle a ete redigee par l’equipe de conformite sans leur contribution.

Correction : Impliquez les equipes operationnelles dans la creation des politiques. Redigez les politiques dans le langage qu’elles utilisent. Stockez les politiques la ou elles travaillent deja. Si votre equipe vit dans Notion, mettez les politiques dans Notion. Si elle utilise GitHub, envisagez de gerer les politiques en Markdown dans un depot avec des flux de revue bases sur les pull requests.

Questions frequentes

Combien de politiques ISO 27001 exige-t-il ?

ISO 27001 ne specifie pas de nombre. La norme exige certaines informations documentees, et la facon dont vous organisez ces informations en politiques est votre decision. Une petite entreprise SaaS pourrait avoir 10-15 politiques couvrant toutes les mesures de l’Annex A. Une organisation plus grande pourrait en avoir 30 ou plus. Ce qui compte, c’est que chaque mesure applicable de l’Annex A soit tracable vers une couverture de politique documentee, pas le nombre de documents.

Puis-je combiner plusieurs politiques dans un seul document ?

Oui. Certaines organisations maintiennent un seul « Manuel de securite de l’information » qui contient toutes les politiques dans un seul document. D’autres separent chaque sujet en un document distinct. Les deux approches sont acceptables. L’approche document unique est plus simple a gerer pour les petites equipes. L’approche multi-documents evolue mieux a mesure que l’organisation grandit et que differentes equipes possedent differents domaines de politique.

Les politiques doivent-elles etre dans un format specifique ?

Non. ISO 27001 ne prescrit pas de formats de documents. Les politiques peuvent etre dans des documents Word, des fichiers PDF, des pages wiki, des fichiers Markdown ou gerees via une plateforme GRC. Ce qui compte, c’est qu’elles soient controlees (versionnees, approuvees, accessibles) et revues.

Qui devrait rediger les politiques ?

La personne qui comprend a la fois le sujet et les pratiques reelles de l’organisation. Dans la plupart des entreprises SaaS, cela signifie une collaboration entre l’equipe securite/conformite et l’equipe operationnelle pertinente. L’equipe de securite fournit le cadre et les objectifs des mesures. L’equipe operationnelle fournit la realite de la mise en oeuvre. Un consultant en conformite peut aider a faire le pont entre les deux.

Quelle longueur devrait avoir une politique ?

Aussi longue que necessaire et pas plus. Une politique bien redigee typique fait 3 a 8 pages. Si une politique depasse 10 pages, envisagez si une partie du contenu appartient a une procedure ou une norme de support. La brievete ameliore la lisibilite et l’adoption. Cependant, ne sacrifiez pas la clarte pour la concision — si une declaration de politique a besoin d’un paragraphe de contexte pour etre comprise, incluez le contexte.

Quelle est la difference entre les politiques ISO 27001 et les politiques SOC 2 ?

Les mesures sous-jacentes se chevauchent significativement, mais le cadre documentaire differe. Les politiques ISO 27001 soutiennent un ISMS et sont organisees autour des mesures de l’Annex A. Les politiques SOC 2 soutiennent une description du systeme et sont organisees autour des criteres des services de confiance. De nombreuses entreprises SaaS poursuivant les deux referentiels maintiennent un ensemble unique de politiques qui satisfait les deux normes, avec un document de correspondance montrant comment chaque politique traite a la fois les mesures ISO 27001 et les criteres SOC 2.

Comment GRCTrail peut vous aider

GRCTrail fournit aux equipes SaaS une solution complete de gestion des politiques conçue pour la certification ISO 27001 :

• Modeles de politiques alignes ISO 27001 rediges specifiquement pour les entreprises SaaS, couvrant chaque mesure de l’Annex A avec un langage refletant les operations cloud-natives — sans references aux sauvegardes sur bande ou aux salles de serveurs physiques
• Correspondance automatisee politique-mesure qui trace chaque mesure de l’Annex A dans votre Declaration d’Applicabilite vers la politique qui la gouverne, identifiant les lacunes avant votre auditeur
• Gestion integree du cycle de vie des politiques avec controle de version, flux d’approbation numerique, suivi de la reconnaissance des employes et rappels de revue automatises qui garantissent que vos politiques ne deviennent jamais obsoletes

Demarrer avec GRCTrail

Guides connexes

• Qu’est-ce qu’ISO 27001 ? Un guide pratique pour les entreprises SaaS
• Exigences ISO 27001 : comprendre les clauses 4 a 10
• Mesures de l’Annex A ISO 27001 : le guide complet
• Checklist de certification ISO 27001
• Controle d’acces ISO 27001 : exigences, mesures et mise en oeuvre SaaS
• Politiques et procedures SOC 2 : ce que vous devez documenter