ISO 27001

ISO 27001 : Norme internationale de management de la sécurité de l’information, dont la certification rassure les grands comptes au moment de l’achat.

Cette entrée du glossaire relève de la famille « Sécurité ». Elle donne la définition, sa traduction en exigences, et les erreurs vues le plus souvent sur des projets réels.

À quoi sert ISO 27001

Sur un projet d’application, ISO 27001 se traite pendant la conception. Ajouter la sécurité à la fin revient à réécrire des parties déjà recettées, donc à les recetter de nouveau.

Le sujet se présente rarement seul. Il arrive au milieu d’une décision plus large, et c’est à ce moment qu’il faut savoir de quoi on parle.

De la définition à la ligne de cahier des charges

Le cahier des charges doit prévoir qui teste « ISO 27001 » et à quel moment. Une revue de sécurité programmée après la mise en ligne arrive trop tard pour changer quoi que ce soit.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les modalités d’authentification, second facteur compris s’il est requis.
• Le stockage des secrets, côté application comme côté serveur.
• La gestion des accès de production, et leur revue périodique.
• Le test de restauration des sauvegardes, réellement exécuté au moins une fois.

Reste à désigner qui écrit cette ligne et qui la valide. Sans nom en face, la rubrique se remplit la veille de la signature, avec les mots du prestataire.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Comment le vérifier à la recette

ISO 27001 se recette avant la mise en ligne, puis se revérifie après les corrections. Un correctif non retesté n’est pas un correctif.

• Contrôler qu’aucun secret ne traîne dans le code livré.
• Passer en revue la liste des personnes ayant accès à la production.
• Réclamer la preuve d’un test de restauration de sauvegarde.

Ce qui n’est pas vérifié à la recette ne sera pas vérifié du tout : le jour de la mise en ligne, plus personne n’a le temps.

Les pièges à éviter

Les mêmes causes reviennent d’un projet à l’autre, quel que soit le prestataire et quelle que soit la taille du budget.

• Traiter la sécurité en fin de projet, quand tout est déjà recetté.
• Stocker un secret dans le code de l’application, où il est lisible par qui veut le lire.
• Commander un audit sans budgéter les corrections qu’il va produire.
• Laisser les accès de production ouverts à d’anciens intervenants.
• Reprendre la formulation d’un autre projet sans vérifier qu’elle décrit bien celui-ci.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Hypothèse de test
• Conformité continue
• EBIOS Risk Manager
• Gestionnaire de mots de passe
• Tableau de bord sécurité

Questions fréquentes

ISO 27001 : de quoi parle-t-on exactement ?

Norme internationale de management de la sécurité de l’information, dont la certification rassure les grands comptes au moment de l’achat. La définition tient en une phrase, son application dépend du projet. C’est pour cette raison qu’elle doit figurer dans le cahier des charges plutôt que dans un échange de courriels.

À quel moment traiter le sujet ?

Dès la conception, puis en contrôle avant la mise en ligne. Une faille corrigée sur plan coûte une discussion ; la même faille corrigée après le lancement coûte un correctif, une republication et parfois une notification.

Est-ce que ça se retrouve dans le devis ?

Un devis lisible sépare conception, design, développement, tests, publication et suivi. La grille de lecture des devis détaille poste par poste ce qui doit y apparaître.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.