ISO 27001 pour une entreprise sans équipe sécurité : ce que cela implique vraiment

Ce qu'ISO 27001 exige réellement d'une entreprise sans RSSI ni équipe sécurité : les décisions que vous seul pouvez prendre, les documents imposés par la norme, les 93 mesures et le calendrier honnête.

Daniel Grigorovich
Daniel Grigorovich
Fondateur · 2 Sept 2026 · 9 min de lecture
ISO 27001SMEAudit
ISO 27001 pour une entreprise sans équipe sécurité

À qui s’adresse cet article : dirigeants, CTO, responsables informatiques et responsables des opérations dans des entreprises de 20 à 250 personnes à qui un client, un assureur ou un investisseur a demandé ISO 27001, et qui n’ont personne dont l’intitulé de poste contient le mot sécurité.

La plupart des explications sur ISO 27001 sont écrites pour des gens qui dirigent déjà une fonction sécurité. Elles parlent du SMSI, du plan de traitement des risques et de l’annexe A comme si ces mots allaient de soi. Si vous êtes le CTO qui gère aussi la feuille de route, l’infrastructure et la moitié du support, cela ne vous sert à rien. Voici donc ce que la norme demande réellement à une entreprise comme la vôtre, dans l’ordre, avec les parties dont personne ne vous prévient.

ISO 27001 est un système de management, pas une note de sécurité

C’est la chose la plus utile à comprendre avant de dépenser le moindre euro.

ISO 27001 ne certifie pas que votre entreprise est sécurisée. Elle certifie que vous disposez d’un système opérationnel pour décider de ce qui doit être protégé, choisir quoi faire, le faire, vérifier que cela a bien eu lieu et corriger quand ce n’est pas le cas. Un auditeur ne teste pas votre pare-feu. Il teste si la machine censée s’occuper de votre pare-feu existe et fonctionne.

Cela a deux conséquences. La bonne : une petite entreprise peut réussir, car la norme s’adapte à votre taille et à votre risque. L’inconfortable : vous pouvez réussir tout en laissant de vraies faiblesses en place, dès lors que vous avez décidé délibérément et consigné la décision. Nous y revenons à la fin, car c’est toute la raison d’être de cet article.

Les cinq décisions que personne ne peut prendre à votre place

Les cabinets et les plateformes peuvent produire des documents. Ils ne peuvent pas trancher ces points, et tout projet qui dérive est un projet où ils sont restés ouverts.

Ce qui est dans le périmètre. Quelles parties de l’entreprise, quels systèmes, quels sites et quels services le certificat couvre. Cette décision pèse sur le coût plus que toute autre. Elle détermine aussi si le certificat répond à la question que votre client pose réellement.

Ce que vous protégez et contre qui. Pas une liste générique de menaces. Ce qui ferait vraiment mal à cette entreprise : une fuite de code source, une interruption de production de quatre jours, une violation de données clients, une fraude au paiement, le départ d’une personne clé avec l’unique copie de quelque chose.

Qui possède la sécurité. Une personne nommée, avec l’autorité de dire non et le temps de faire le travail. La norme exige l’engagement de la direction, et c’est l’exigence que les entreprises simulent le plus souvent.

Quel risque vous acceptez. Toute organisation accepte du risque. ISO 27001 demande seulement que vous le fassiez explicitement, au bon niveau hiérarchique, avec une raison.

Ce que vous ne ferez pas. La moitié ingrate. Si vous n’allez pas mettre en place un cycle de développement sécurisé formel cette année, dites-le et expliquez pourquoi, plutôt que d’écrire une politique décrivant une entreprise que vous n’êtes pas.

Si vous voulez une version structurée de ces cinq points avant d’engager un budget, c’est exactement l’objet d’un audit de sécurité vCISO indépendant : il produit les décisions, les écarts hiérarchisés et la feuille de route, et il est utile que vous vous certifiiez ou non.

Ce que la norme vous oblige à construire

Une fois le jargon retiré, ISO 27001 exige une liste assez courte de choses qui doivent exister et rester vivantes.

  • Un périmètre défini. Un ou deux paragraphes, plus une frontière que vous pouvez défendre.
  • Une méthode de risque et un registre des risques. Une façon reproductible d’identifier, coter et traiter les risques, et la trace de l’avoir fait. Pas un tableur rempli une fois en mars.
  • Une déclaration d’applicabilité. Chaque mesure de l’annexe A, marquée applicable ou non, avec une justification. C’est le document que les auditeurs lisent en premier, et il mérite sa propre explication, d’où notre article sur le périmètre et la déclaration d’applicabilité sans jargon.
  • Des politiques que les gens ont réellement acceptées. Écrites, approuvées, versionnées et reconnues par le personnel. Une politique non lue est une non-conformité en attente.
  • Des preuves que les mesures fonctionnent. Revues d’accès datées, tests de restauration de sauvegarde avec résultats, dossiers d’arrivée et de départ, traces de correctifs, revues de fournisseurs.
  • Audit interne et revue de direction. Vous vous contrôlez avant l’auditeur, et la direction examine formellement les résultats.
  • Actions correctives. Quand quelque chose échoue, il existe une trace de ce que vous avez fait.

Remarquez la part de tenue de registres par rapport à la technologie. C’est la forme honnête du travail.

Les 93 mesures, et pourquoi le chiffre effraie plus qu’il ne devrait

L’édition 2022 d’ISO 27001 liste 93 mesures en annexe A, réparties en quatre thèmes : organisationnel, personnes, physique et technologique. L’édition 2013 en comptait 114, la norme s’est donc raccourcie, surtout en fusionnant des éléments redondants.

Deux choses rendent ce chiffre moins alarmant. D’abord, une part significative ne s’appliquera pas à vous, et le dire par écrit est une réponse légitime. Ensuite, beaucoup correspondent à des pratiques que vous avez déjà de façon informelle : vous intégrez déjà des collaborateurs, vous avez déjà des sauvegardes, vous limitez déjà l’accès à la production. Le travail consiste généralement à formaliser et à prouver l’existant, pas à partir de zéro.

Onze mesures étaient nouvelles en 2022, et ce sont celles qui prennent les petites structures au dépourvu car elles n’ont jamais fait partie des réflexes : renseignement sur les menaces, sécurité des services cloud, préparation des TIC pour la continuité d’activité, surveillance de la sécurité physique, gestion des configurations, suppression d’informations, masquage des données, prévention des fuites de données, activités de surveillance, filtrage web et codage sécurisé. Si vous éditez du logiciel, la gestion des configurations, le codage sécurisé et la surveillance concentreront l’effort réel.

Ce qui a changé récemment, et ce que cela signifie pour vous

Trois points qui comptent en pratique.

La période de transition depuis l’édition 2013 s’est close le 31 octobre 2025. Tous les audits se déroulent désormais selon les mesures 2022, donc tout modèle, pack de politiques ou livrable de conseil qui référence l’ancienne numérotation est périmé. Vérifiez-le avant de payer quoi que ce soit.

L’amendement 1 a ajouté les considérations climatiques aux clauses portant sur votre contexte et vos parties intéressées. En clair, vous devez examiner si les conditions environnementales sont pertinentes pour votre sécurité de l’information, et consigner la conclusion dans un sens comme dans l’autre. Pour la plupart des éditeurs de logiciels, la réponse honnête tient en un court paragraphe sur la résilience physique des installations dont vous dépendez. C’est une exigence documentaire, pas une transformation verte.

La clause 6.3 impose de planifier les changements du système de management plutôt que de le laisser dériver. Celle-là est réellement utile. C’est la clause qui empêche votre SMSI d’être exact au premier mois et fictif au quatorzième.

Le comportement des auditeurs a évolué en parallèle. L’accent est passé de l’existence d’une politique à la démonstration qu’une mesure a effectivement fonctionné, et les preuves attendues couvrent typiquement plusieurs mois d’enregistrements opérationnels plutôt qu’un instantané assemblé la semaine précédant l’audit. Prévoyez cela dès le départ, car reconstituer six mois de preuves est impossible.

Le calendrier honnête

Pour une entreprise de 20 à 250 personnes sans équipe sécurité, en travaillant régulièrement plutôt qu’héroïquement :

  • Cadrage, appréciation des risques et déclaration d’applicabilité : quatre à huit semaines.
  • Fermeture des écarts qui comptent : deux à cinq mois, et c’est la partie qui varie le plus, car elle dépend de ce que l’évaluation révèle réellement.
  • Faire tourner le système assez longtemps pour avoir des preuves : trois mois au minimum, six c’est plus confortable.
  • Audit interne et revue de direction : deux à quatre semaines.
  • Audits Étape 1 et Étape 2 : séparés de quelques semaines, plus le temps de lever les constats.

Neuf à douze mois est un délai réaliste pour une première certification quand on part d’une situation normale et non structurée. Quiconque promet trois mois vous vend soit un périmètre très étroit, soit un assemblage de preuves plutôt qu’une production de preuves. Sur le coût et sur l’endroit où va réellement l’argent, nous avons écrit séparément sur la question des 50 000 € pour ISO 27001.

Où les entreprises sans équipe sécurité bloquent réellement

Quatre schémas, dans l’ordre où nous les voyons.

Le périmètre a été tracé pour faciliter l’audit, pas pour répondre au client. Le certificat arrive, le client lit l’énoncé du périmètre et demande pourquoi son service n’y figure pas. Vous voilà à le refaire.

Personne ne le porte après le lancement. Le projet a de l’énergie pendant six semaines, puis le CTO reçoit une échéance produit. Le meilleur prédicteur d’un projet qui s’enlise est que la propriété de la sécurité n’a jamais été le vrai métier de quelqu’un.

La preuve n’est jamais devenue une habitude. Les mesures ont été conçues mais rien ne trace leur exécution, et le mois précédant l’audit se transforme en fouille archéologique.

Les fournisseurs ont été laissés pour la fin. Votre liste de fournisseurs est plus longue que vous ne le pensez, et la norme attend que vous ayez évalué et surveillé ceux qui comptent. Le même problème surgit sous d’autres régimes, ce que nous avons traité dans la sécurité de la chaîne d’approvisionnement et le risque fournisseur.

Si ISO 27001 vous tombe dessus en même temps que NIS2, faites le travail une fois plutôt que deux. Le recouvrement est large et la correspondance est bien documentée, comme nous l’exposons dans les normes de certification et ISO 27001 sous NIS2, et vous trouverez une vue plus large de ce que la réglementation demande aux petites structures dans notre article sur NIS2 pour les PME. Une vue structurée de tout le parcours ISO 27001 se trouve sur notre page solution ISO 27001.

La réalité technique : ce que le certificat laisse ouvert

Voici la partie que la plupart des guides sautent.

ISO 27001 vérifie que vos mesures ont été choisies délibérément et fonctionnent comme décrit. Elle ne vérifie pas qu’elles suffisent face à un attaquant compétent. Ce sont deux tests différents, et l’écart entre les deux est là où surviennent les compromissions chez des entreprises certifiées.

Concrètement, une entreprise peut détenir un certificat valide alors que :

  • l’authentification multifacteur est activée mais pas imposée sur le chemin hérité que tout le monde utilise réellement,
  • les sauvegardes tournent et sont testées en confirmant que la tâche a réussi, jamais en restaurant un système de bout en bout sous contrainte de temps,
  • les journaux sont collectés mais personne ne les regarde, parce que la mesure disait collecter, pas détecter,
  • une dépendance avec une vulnérabilité critique connue reste en production parce que la fenêtre de correctifs a été documentée comme trimestrielle et que c’était la décision acceptée,
  • une liste de départ est signée alors que les jetons et les identifiants partagés de la personne restent valides.

Chacun de ces cas passe un audit. Chacun de ces cas est exploitable.

Les fermer relève d’un autre travail : imposer plutôt qu’activer, restaurer plutôt que vérifier le statut de la tâche, alerter sur le journal plutôt que le stocker, et raccourcir la fenêtre de correctifs pour ce qui est réellement exposé. Ce n’est pas plus de paperasse. C’est la moitié opérationnelle que le certificat ne demande pas et que l’attaquant ne saute pas.

La bonne façon de mener un projet ISO 27001 dans une entreprise sans équipe sécurité est donc de traiter la certification comme l’échéance qui débloque le budget, et la liste des écarts en dessous comme ce que vous achetez réellement. Obtenez le certificat. Puis continuez, car le certificat est le plancher, pas le plafond.

Daniel Grigorovich

Daniel Grigorovich · Fondateur

Je pense qu'aucune entreprise ne devrait avoir à subir les « listes de contrôle de conformité » ni à se débattre avec des textes réglementaires obscurs. Bien que je reste attaché au principe selon lequel tous les logiciels doivent être fiables et sécurisés, je souhaite offrir aux entreprises un moyen de surmonter les difficultés rencontrées lors de la mise en œuvre de ces exigences.