P.I.L.O.T.E

15 min de lecture

Annexe A.5 – Mesures organisationnelles

Introduction

Le bloc A.5 – Mesures organisationnelles constitue la partie la plus dense de l’Annexe A.
Il comprend 37 mesures couvrant la gouvernance, la gestion documentaire, la relation avec les fournisseurs, la continuité d’activité, la conformité légale et la protection des informations.

Ces mesures structurent la colonne vertébrale du SMSI : sans elles, les mesures techniques ou humaines perdent leur efficacité.
Elles traduisent l’engagement de la direction, la formalisation des rôles, l’encadrement des tiers et la mise en conformité avec les obligations légales.

Un audit ISO/IEC 27001 consacre une large part de ses vérifications sur ce bloc.

A.5.1 Politiques de sécurité de l’information

  • Explication : L’organisation doit établir des politiques de sécurité couvrant l’ensemble du périmètre du SMSI. Elles doivent être alignées avec les objectifs stratégiques et les obligations réglementaires (RGPD, NIS2, etc.). Ces politiques fixent les principes directeurs (confidentialité, intégrité, disponibilité) et les responsabilités.
  • Exemple : Une entreprise pharmaceutique définit une politique SSI approuvée par le COMEX, qui inclut la gestion des données de recherche sensibles et l’accès aux laboratoires connectés.

Warning

Erreur fréquente : copier une politique générique sans l’adapter au secteur. Les auditeurs rejettent les documents « hors contexte ».

  • Preuves d’audit : politique validée par la direction, registre de diffusion aux collaborateurs, accusés de lecture.

A.5.2 Gouvernance de la sécurité de l’information

  • Explication : La gouvernance de la SSI doit être structurée via un comité dédié, un RSSI nommé et des relais dans les métiers. La gouvernance fixe la stratégie, suit les risques et valide les plans d’action.
  • Exemple : Une banque crée un ISO Steering Committee mensuel intégrant RSSI, DPO, direction IT, direction risques et représentants métiers.

Warning

Erreur fréquente : se limiter à un organigramme sans preuve de réunions ou de suivi des décisions.

  • Preuves d’audit : PV de comités SSI, désignation formelle du RSSI, plan d’action validé.

A.5.3 Responsabilités et rôles en matière de sécurité

  • Explication : Les responsabilités SSI doivent être formalisées dans les fiches de poste et communiquées aux employés. Cela garantit la responsabilisation et l’accountability.
  • Exemple : Un administrateur système doit avoir une fiche de poste précisant son obligation de patcher les serveurs sous 30 jours et de signaler tout incident au SOC.

Warning

Erreur fréquente : rôles théoriques jamais communiqués aux employés concernés.

  • Preuves d’audit : fiches de poste, organigrammes, contrats de travail avec clauses SSI.

A.5.4 Coordination de la sécurité de l’information

  • Explication : Les départements doivent collaborer pour assurer une sécurité cohérente (IT, RH, juridique, achats, métiers). La coordination permet de couvrir les angles morts organisationnels.
  • Exemple : Un hôpital organise un comité inter-fonctionnel où le RSSI, le DPO et la direction médicale définissent ensemble les règles d’accès aux dossiers patients.

Warning

Erreur fréquente : cloisonnement IT/RH → oubli systématique de désactiver les comptes lors des départs.

  • Preuves d’audit : procès-verbaux de réunions inter-départements, procédures transverses validées.

A.5.5 Processus de gestion documentaire

  • Explication : Le SMSI doit reposer sur une GED centralisée assurant versioning, validation et diffusion des documents (politiques, procédures, registres).
  • Exemple : Une entreprise industrielle utilise Confluence avec workflows de validation et un archivage automatique des versions obsolètes.

Warning

Erreur fréquente : documents dispersés sur des partages réseau sans gestion de version.

  • Preuves d’audit : historique des versions, workflows d’approbation, registre des documents.

A.5.6 Gestion des enregistrements

  • Explication : Les enregistrements liés à la sécurité (journaux, incidents, rapports d’audit) doivent être conservés, protégés et accessibles. Leur durée de rétention doit être définie.
  • Exemple : Une société d’énergie conserve les journaux de ses SI critiques pendant 12 mois dans un SIEM avec accès restreint.

Warning

Erreur fréquente : effacer les logs au bout de quelques jours pour économiser du stockage.

  • Preuves d’audit : politique de rétention, échantillons de journaux, registre des accès aux logs.

A.5.7 Relations avec les autorités

  • Explication : L’organisation doit maintenir des contacts formalisés avec les autorités compétentes (ANSSI, CNIL, régulateurs sectoriels). Ces relations facilitent la gestion des incidents et la conformité.
  • Exemple : Un OIV dans le transport désigne un point de contact officiel avec l’ANSSI pour la remontée des incidents majeurs.

Warning

Erreur fréquente : improviser le contact en pleine crise, sans protocole établi.

  • Preuves d’audit : procédures de communication, liste de contacts officiels.

A.5.8 Relations avec des groupes spécialisés

  • Explication : Participer à des réseaux d’échange (ISACs, CLUSIF, CERT sectoriels) permet d’anticiper les menaces et de partager des bonnes pratiques.
  • Exemple : Une banque française est membre de l’ISAC européen pour partager les menaces détectées sur les fraudes bancaires.

Warning

Erreur fréquente : rester isolé → aucune remontée de renseignement cyber.

  • Preuves d’audit : adhésions, comptes rendus de participation.

A.5.9 Contacts avec les autorités de sécurité spécialisées

  • Explication : Formaliser les liens avec police, gendarmerie, CSIRT. Ces relations facilitent les dépôts de plainte, les investigations et la coopération.
  • Exemple : Une collectivité locale établit une convention avec la gendarmerie pour signaler systématiquement les cyberattaques.

Warning

Erreur fréquente : absence de contact identifié, perte de temps en cas d’incident grave.

  • Preuves d’audit : conventions, protocoles, registres de signalements.

A.5.10 Responsabilités dans la continuité

  • Explication : La continuité des activités doit intégrer la SSI. Les rôles et responsabilités doivent être précisés dans les PCA/PRA.
  • Exemple : Dans une compagnie aérienne, le RSSI est membre du comité de crise et supervise la reprise des systèmes critiques après incident.

Warning

Erreur fréquente : PCA rédigés uniquement par l’IT, sans volet sécurité.

  • Preuves d’audit : PCA/PRA validés, PV de tests de crise incluant la SSI.

A.5.11 Responsabilités liées à la sécurité dans les contrats

  • Explication : Les contrats avec fournisseurs et partenaires doivent inclure des clauses de sécurité (confidentialité, disponibilité, conformité réglementaire).
  • Exemple : Un contrat d’infogérance inclut des clauses imposant le chiffrement des données et la notification des incidents sous 24h.

Warning

Erreur fréquente : contrats rédigés uniquement sur le plan financier, sans volet SSI.

  • Preuves d’audit : exemplaires de contrats avec clauses SSI, revue juridique.

A.5.12 Processus de gestion des changements organisationnels

  • Explication : Tout changement (fusion, acquisition, externalisation) doit intégrer une analyse de risques SSI et une validation par la direction.
  • Exemple : Une entreprise IT intègre une évaluation SSI complète lors du rachat d’une start-up Cloud.

Warning

Erreur fréquente : changement organisationnel sans revue SSI → vulnérabilités non anticipées.

  • Preuves d’audit : rapports d’analyse de risques, procès-verbaux de comité de direction.

A.5.13 Gestion des risques liés aux fournisseurs

  • Explication : Les fournisseurs doivent être évalués et surveillés pour garantir leur conformité en matière de sécurité.
  • Exemple : Un hôpital exige de ses prestataires Cloud des preuves de certification ISO 27001 et SOC 2.

Warning

Erreur fréquente : pas de suivi post-contractuel, audit initial mais pas de contrôle continu.

  • Preuves d’audit : fiches d’évaluation fournisseurs, rapports d’audit tiers.

A.5.14 Inventaire des actifs informationnels

  • Explication : Identifier et maintenir à jour l’ensemble des actifs (serveurs, bases de données, applications, documents critiques).
  • Exemple : Une société d’énergie tient un inventaire sous CMDB (Configuration Management Database).

Warning

Erreur fréquente : inventaire incomplet ou non mis à jour depuis plusieurs années.

  • Preuves d’audit : registre des actifs, captures CMDB, preuves de mise à jour.

A.5.15 Contrôle des accès aux informations

  • Explication : Restreindre l’accès aux informations selon le principe du moindre privilège. Impliquer un processus IAM (Identity and Access Management).
  • Exemple : Une banque met en œuvre RBAC, recertification trimestrielle des accès et SIEM pour corréler les logs.

Warning

Erreur fréquente : absence de révocation automatique lors des départs.

  • Preuves d’audit : registres IAM, logs d’accès, rapports de recertification.

A.5.16 Classification de l’information

  • Explication : L’information doit être classifiée selon sa sensibilité (public, interne, confidentiel, secret). Cette classification guide les contrôles appliqués.
  • Exemple : Une entreprise de défense classe ses documents techniques en « Confidentiel » et applique un stockage chiffré + accès restreint.

Warning

Erreur fréquente : classification établie mais jamais appliquée dans les pratiques.

  • Preuves d’audit : registre de classification, étiquetage de documents.

A.5.17 Manipulation des supports d’information

  • Explication : Les supports physiques (clés USB, disques durs, documents papier) doivent être protégés et éliminés de façon sécurisée.
  • Exemple : Une entreprise utilise un broyeur certifié DIN 66399 pour détruire les documents sensibles.

Warning

Erreur fréquente : stockage de données sensibles sur des clés USB non chiffrées.

  • Preuves d’audit : politique de gestion des supports, registre d’élimination.

A.5.18 Gestion des médias amovibles

  • Explication : Restreindre l’usage des médias amovibles et appliquer un chiffrement systématique.
  • Exemple : Une entreprise interdit les clés USB personnelles et fournit des clés chiffrées approuvées.

Warning

Erreur fréquente : absence de politique → prolifération de supports non maîtrisés.

  • Preuves d’audit : politique d’usage des médias, logs d’utilisation, contrôles techniques.

A.5.19 Sécurité dans les relations fournisseurs

  • Explication : La sécurité doit être intégrée dans toutes les phases de la relation fournisseur (sélection, contrat, suivi).
  • Exemple : Une compagnie aérienne audite chaque année son fournisseur de maintenance IT.

Warning

Erreur fréquente : négliger la surveillance post-contractuelle → failles exploitées via un fournisseur.

  • Preuves d’audit : audits fournisseurs, contrats SSI, rapports de conformité.

A.5.20 Suivi de la performance des fournisseurs

  • Explication : Évaluer régulièrement les fournisseurs sur leurs engagements SSI (SLA, disponibilité, incidents).
  • Exemple : Un fournisseur Cloud est noté chaque trimestre sur son taux de disponibilité, le respect des patchs et la notification d’incidents.

Warning

Erreur fréquente : aucun indicateur suivi → dépendance aveugle aux déclarations du fournisseur.

  • Preuves d’audit : SLA contractuels, rapports de suivi, revues de performance.

A.5.21 Gestion des relations TIC avec les fournisseurs

  • Explication : Lorsqu’un fournisseur accède aux systèmes d’information, les conditions de sécurité doivent être définies et surveillées.
  • Exemple : Un prestataire d’infogérance dispose d’un accès VPN avec authentification MFA et restriction horaire.

Warning

Erreur fréquente : donner un accès total et permanent aux prestataires sans contrôle.

  • Preuves d’audit : contrats SSI, logs d’accès VPN, liste des comptes fournisseurs.

A.5.22 Gestion des services externalisés

  • Explication : Les services externalisés (Cloud, SaaS, infogérance) doivent être encadrés contractuellement et surveillés régulièrement.
  • Exemple : Un hôpital impose à son fournisseur de télé-imagerie médicale un audit de sécurité annuel.

Warning

Erreur fréquente : croire que la responsabilité SSI est entièrement transférée au fournisseur.

  • Preuves d’audit : contrat avec clauses de sécurité, rapports d’audit externe, SLA.

A.5.23 Surveillance et évaluation des services externalisés

  • Explication : Les performances et incidents liés aux services externalisés doivent être mesurés et évalués périodiquement.
  • Exemple : Une banque suit le taux de disponibilité de son prestataire Cloud (SLA = 99,9 %) et déclenche des pénalités en cas de manquement.

Warning

Erreur fréquente : absence de suivi → dépendance totale aux déclarations du fournisseur.

  • Preuves d’audit : SLA, tableaux de bord de performance, rapports de conformité.

A.5.24 Traitement des informations documentées par les fournisseurs

  • Explication : Les informations partagées avec les fournisseurs doivent être protégées par des accords de confidentialité et des mesures techniques.
  • Exemple : Un constructeur automobile signe des NDA avec ses sous-traitants et exige le chiffrement TLS pour les échanges.

Warning

Erreur fréquente : absence de NDA → fuite de données lors de la sous-traitance.

  • Preuves d’audit : NDA signés, preuves de chiffrement, registres d’échanges.

A.5.25 Conformité aux obligations légales et contractuelles

  • Explication : Identifier et suivre toutes les obligations légales (RGPD, NIS2) et contractuelles applicables au SMSI.
  • Exemple : Une société d’e-commerce tient un registre de conformité RGPD et un registre des SLA avec ses partenaires.

Warning

Erreur fréquente : obligations non mises à jour après évolution réglementaire.

  • Preuves d’audit : registre des obligations, rapports de conformité.

A.5.26 Gestion des droits de propriété intellectuelle

  • Explication : Protéger les droits liés aux logiciels, bases de données et contenus produits par l’entreprise.
  • Exemple : Une SSII gère ses licences logicielles via un outil SAM (Software Asset Management).

Warning

Erreur fréquente : usage de logiciels sans licence → non-conformité légale et risque d’amende.

  • Preuves d’audit : registre de licences, contrats éditeurs, audits SAM.

A.5.27 Protection des données personnelles

  • Explication : Garantir le respect du RGPD et des lois locales. Inclure la gestion des consentements, droits d’accès et notification CNIL en cas d’incident.
  • Exemple : Une plateforme en ligne déploie un portail RGPD pour permettre aux utilisateurs d’exercer leurs droits.

Warning

Erreur fréquente : absence de procédure de notification CNIL → sanctions financières.

  • Preuves d’audit : registre RGPD, procédures de notification, preuves de formation des DPO.

A.5.28 Protection contre les logiciels malveillants

  • Explication : Déployer des solutions antivirus/EDR, mettre à jour les signatures, sensibiliser les utilisateurs.
  • Exemple : Une entreprise déploie Microsoft Defender ATP sur tout son parc, avec supervision centralisée par le SOC.

Warning

Erreur fréquente : solutions installées mais non surveillées (alertes ignorées).

  • Preuves d’audit : rapports EDR, logs d’alertes, preuves de mise à jour.

A.5.29 Gestion de la sécurité des réseaux

  • Explication : Les réseaux doivent être segmentés, supervisés et protégés (pare-feu, IDS/IPS).
  • Exemple : Une société d’énergie segmente ses réseaux OT et IT et supervise les flux via un IDS industriel.

Warning

Erreur fréquente : réseau à plat, sans segmentation → propagation rapide des attaques.

  • Preuves d’audit : schémas réseau, configurations de pare-feu, rapports IDS.

A.5.30 Planification de la continuité de la sécurité

  • Explication : La continuité doit intégrer la SSI, avec scénarios, tests et responsabilités définies.
  • Exemple : Une banque effectue un test PRA simulant une cyberattaque sur son datacenter.

Warning

Erreur fréquente : PCA/PRA rédigés mais jamais testés.

  • Preuves d’audit : PCA validé, rapports de tests PRA, procès-verbaux de comité de crise.

A.5.31 Intégration de la sécurité dans les processus métier

  • Explication : La sécurité doit être intégrée dès la conception des processus métier et non ajoutée après coup.
  • Exemple : Une plateforme e-commerce intègre la gestion des consentements RGPD directement dans le processus d’inscription client.

Warning

Erreur fréquente : sécurité traitée comme un contrôle annexe, générant des contournements.

  • Preuves d’audit : documentation des processus, preuves de revues SSI.

A.5.32 Gestion de la sécurité dans les projets

  • Explication : Tout projet IT ou organisationnel doit inclure un volet sécurité avec analyse de risques et mesures de contrôle.
  • Exemple : Un projet de déploiement ERP inclut une analyse EBIOS RM pour identifier les risques.

Warning

Erreur fréquente : projet validé sans revue SSI → failles découvertes en production.

  • Preuves d’audit : dossiers de projet avec volets SSI, PV de comité projet.

A.5.33 Exigences de sécurité dans le cycle de vie du développement

  • Explication : Les applications doivent intégrer la sécurité dès le développement (DevSecOps).
  • Exemple : Une fintech intègre des tests SAST/DAST automatisés dans sa CI/CD.

Warning

Erreur fréquente : recourir uniquement à un audit final, trop tardif.

  • Preuves d’audit : pipeline CI/CD avec étapes sécurité, rapports de tests.

A.5.34 Sécurité dans la gestion des changements

  • Explication : Chaque changement système doit être évalué en termes de sécurité avant déploiement.
  • Exemple : Une entreprise valide chaque mise à jour applicative via un CAB (Change Advisory Board) incluant le RSSI.

Warning

Erreur fréquente : changements urgents déployés sans validation SSI.

  • Preuves d’audit : CAB, tickets de changement, analyses SSI.

A.5.35 Sécurité dans la gestion des capacités

  • Explication : La planification des capacités (CPU, réseau, stockage) doit inclure des aspects de sécurité pour éviter les saturations et indisponibilités.
  • Exemple : Un hébergeur Cloud surveille la charge et déclenche une extension automatique pour éviter les dénis de service internes.

Warning

Erreur fréquente : planification purement technique, sans prise en compte de la disponibilité comme exigence SSI.

  • Preuves d’audit : tableaux de bord de charge, rapports de prévision de capacité.

A.5.36 Sécurité dans la gestion des incidents

  • Explication : L’organisation doit disposer d’un processus clair de gestion d’incidents : détection, classification, traitement, communication, retour d’expérience.
  • Exemple : Une société active un plan de réponse ransomware incluant isolement réseau, communication DPO, dépôt de plainte.

Warning

Erreur fréquente : absence de retour d’expérience après l’incident.

  • Preuves d’audit : procédures de gestion d’incident, tickets d’incidents, rapports REX.

A.5.37 Sécurité dans la gestion des projets de changement majeur

  • Explication : Les projets de transformation (migration Cloud, délocalisation, acquisition) doivent inclure une analyse de risques SSI approfondie.
  • Exemple : Une entreprise migre son ERP vers le Cloud et impose un audit de sécurité complet avant bascule.

Warning

Erreur fréquente : décisions stratégiques prises uniquement sur critères financiers, sans volet SSI.

  • Preuves d’audit : dossiers de projets de transformation incluant la SSI, rapports d’analyse de risques.

Conclusion du bloc A.5 – Mesures organisationnelles

Les 37 mesures organisationnelles de l’Annexe A représentent le socle de tout SMSI efficace.
Elles structurent la gouvernance, clarifient les responsabilités, encadrent les fournisseurs, garantissent la conformité légale et assurent l’intégration de la sécurité dans les processus métier et projets stratégiques.

Un audit ISO/IEC 27001 mettra une attention particulière à ce bloc car il traduit le niveau de maturité global de l’organisation :

  • Une gouvernance claire et active.
  • Des politiques et processus documentés et vivants.
  • Une intégration réelle de la sécurité dans les contrats, les projets et la continuité d’activité.

Les organisations qui négligent ces mesures finissent par déployer un SMSI « théorique », sans ancrage opérationnel, et sont systématiquement sanctionnées en audit.
À l’inverse, celles qui appliquent correctement ce bloc A.5 disposent d’une base solide pour que les mesures humaines, physiques et technologiques puissent être efficaces.

En résumé, le bloc organisationnel constitue la colonne vertébrale du SMSI, garantissant que la sécurité n’est pas un sujet isolé de l’IT mais bien une composante intégrée de la gouvernance d’entreprise.

Vue Graphique