ISO 27001 sans consultant ? Risques, coûts, comparaison honnête

La question revient régulièrement : "Peut-on faire ISO 27001 nous-mêmes ?" La réponse est presque toujours la même : techniquement oui, stratégiquement rarement conseillé. Un RSSI en PME qui aborde l'ISO/IEC 27001 sans expérience préalable des systèmes de management sous-estime systématiquement trois facteurs : la charge de travail, les marges d'interprétation de la norme et les coûts d'un audit échoué.

Cet article calcule honnêtement ce que coûtent les deux approches, illustre par des exemples concrets avant/après les points de rupture des projets DIY, et précise la seule condition sous laquelle l'auto-implémentation est défendable.

Ce que la norme exige réellement

L'ISO/IEC 27001:2022 définit les exigences d'un système de management de la sécurité de l'information (SMSI). La norme s'articule en dix chapitres, plus l'Annexe A avec 93 mesures.^[1] L'élément décisif : la norme ne prescrit pas comment une organisation met en oeuvre la sécurité, mais qu'elle dispose d'un processus documenté et géré de manière démontrée.

C'est précisément là que beaucoup de PME font fausse route. Elles lisent "93 mesures" et commencent à déployer des contrôles techniques. Ce qu'elles oublient : avant de mettre en oeuvre une seule mesure, la norme exige une évaluation des risques documentée, un périmètre d'application clairement défini et la fixation des objectifs de sécurité par la direction.^[1]

Le BSI décrit dans son standard 200-2 une démarche méthodologiquement analogue : d'abord l'analyse de structure, puis l'évaluation des besoins de protection, puis la sélection des mesures.^[2] Inverser cet ordre revient à construire sur du sable, et l'audit de Stade 1 ne manquera pas de le signaler.

Le mythe du coût

"Avec un consultant, ça coûte 50.000 euros. On le fait nous-mêmes." Ce calcul contient une erreur de raisonnement.

Avant : approche DIY interne (exemple : 120 collaborateurs)

Poste	Hypothèse	Coût (EUR)
RSSI chef de projet (interne)	400 heures à 100 EUR	40.000
Collaborateur IT pour la documentation	200 heures à 70 EUR	14.000
Formations externes	3 personnes, 2 sessions chacune	9.000
Audit de certification initial Stade 1 et 2	Organisme de certification	12.000
Corrections après Stade 1	80 heures et mesures correctives	11.000
Total		env. 86.000

Après : avec un consultant expérimenté (même entreprise)

Poste	Hypothèse	Coût (EUR)
Honoraires de conseil	300 heures à 150 EUR	45.000
Charge interne (réduite)	150 heures à 100 EUR	15.000
Audit de certification initial Stade 1 et 2	Organisme de certification	12.000
Total		env. 72.000

Le consultant coûte ici moins cher que le DIY. Non pas parce que son taux horaire est inférieur, mais parce qu'il prévient les erreurs qui deviennent coûteuses en interne. Un premier audit échoué repousse le go-live de trois à six mois et génère une nouvelle charge interne. C'est encore le scénario le moins défavorable. Selon IBM Security, une violation de données dans une entreprise de cette taille coûte en moyenne 4,45 millions de dollars américains.^[5]

Les trois erreurs les plus fréquentes dans l'approche DIY

1. Périmètre trop large

Qui définit un périmètre d'application trop vaste contrôle davantage que nécessaire et échoue sur l'ampleur. La norme autorise explicitement une définition stricte du périmètre.^[1] Un consultant expérimenté connaît la frontière entre "auditable" et "trop ambitieux". En interne, ce référentiel fait presque toujours défaut, faute de base de comparaison.

2. Documentation comme fin en soi

Le cadre Diataxis distingue quatre types de documentation : tutoriel, guide pratique, explication et document de référence.^[6] Dans les projets ISO 27001 conduits en interne, il se crée presque exclusivement de la documentation de référence : politiques, preuves et registres. Ce qui fait défaut : des guides pratiques opérationnels pour les collaborateurs directement impliqués.

Avant (résultat DIY typique) :

"Les mots de passe doivent comporter au moins 12 caractères et contenir des caractères spéciaux. Les mots de passe doivent être changés tous les 90 jours."

C'est une politique. Aucun auditeur ne la rejettera. Mais quand le technicien du helpdesk doit réinitialiser un mot de passe, il ne sait pas quel système ouvrir, quelle procédure appliquer ni qui informer.

Après (guide pratique opérationnel en complément) :

"Réinitialisation de mot de passe : 1. Connectez-vous au portail IT via https://it.intern. 2. Sélectionnez 'Gestion des utilisateurs'. 3. Recherchez le compte concerné. 4. Cliquez sur 'Réinitialiser le mot de passe' et choisissez 'Temporaire'. 5. Informez l'utilisateur par téléphone du mot de passe temporaire et rappelez-lui l'obligation de le modifier à la première connexion."

Cette différence n'est pas cosmétique. Sans documentation de processus opérationnelle, aucun auditeur n'acceptera le statut "mis en oeuvre" pour les contrôles opérationnels. Les politiques décrivent l'objectif, les guides pratiques décrivent le chemin pour y parvenir.

3. Évaluation des risques sans méthodologie

La norme exige une évaluation des risques documentée, mais laisse la méthode ouverte.^[1] Dans l'approche DIY, des tableaux listent fréquemment des risques sans logique d'évaluation traçable. L'ENISA recommande pour les PME une approche simplifiée mais méthodologiquement cohérente, avec des échelles de probabilité et d'impact clairement définies.^[4] Sans cohérence, l'évaluation ne peut être défendue en audit. La question "Pourquoi ce risque a-t-il un score de 12 et cet autre un score de 6 ?" doit pouvoir recevoir une réponse à tout moment.

Ce qu'un bon consultant apporte réellement

Un bon consultant n'apporte pas principalement des documents. Il apporte trois choses concrètes.

Le langage des auditeurs. Il sait quelle formulation un auditeur accepte comme suffisante et laquelle déclenche une demande de complément. Cette expérience ne se lit pas dans la norme. Elle naît d'une participation répétée aux audits des deux côtés de la table, et ne peut être remplacée par des formations.

L'expérience du périmètre. Il a conduit des implémentations comparables dans des entreprises similaires et connaît les écueils typiques d'une entreprise industrielle de 150 collaborateurs ou d'un prestataire IT de 80 personnes. Cette expérience comprime considérablement le processus d'apprentissage interne et évite que le projet échoue aux points de rupture habituels.

La discipline projet. ISO 27001 échoue rarement en PME par manque de savoir-faire technique, mais à cause de conflits de priorités dans l'activité courante. TeleTrusT cite l'absence de soutien managérial comme l'une des causes les plus fréquentes d'échec des projets de certification de PME.^[3] Un consultant externe crée une obligation externe quasi impossible à maintenir en interne quand le quotidien concurrence le projet.

Ce qu'un bon consultant ne livre pas : des documents finalisés que l'entreprise ne comprend plus une fois le projet terminé. Toute politique que l'équipe interne ne peut expliquer deviendra un problème lors de l'audit de surveillance. Le critère de qualité déterminant d'un projet de conseil est de savoir si l'équipe interne peut gérer le SMSI de façon autonome après la fin du projet.

Quand le DIY est défendable

Le DIY est défendable sous une seule condition : le RSSI ou la personne responsable dispose d'une expérience avérée sur des projets ISO 27001 dans des entreprises comparables.

Cela signifie : participation active et directe à une certification en tant que chef de projet interne, et non en tant qu'observateur. Un certificat de Lead Implementer ISO 27001 ne remplace pas cette expérience.

Conditions favorables supplémentaires : l'entreprise dispose déjà d'un système de management de la qualité établi selon ISO 9001, la direction est activement impliquée et le projet dispose d'un budget dédié pour un audit préparatoire externe par un Lead Auditeur indépendant avant l'audit de Stade 1.

Si ces conditions ne sont pas réunies, une approche hybride est souvent plus judicieuse qu'une pleine auto-implémentation. Concrètement : un consultant expérimenté prend en charge la définition du périmètre, la méthodologie d'évaluation des risques et le briefing des auditeurs ; l'équipe interne prend en charge la documentation et la mise en oeuvre opérationnelle. Cela réduit la charge de conseil à 100 à 150 heures tout en maintenant les points critiques entre des mains professionnelles.

Conclusion

L'accompagnement ISO 27001 en PME n'est pas un luxe ni le signe d'un manque de compétences. C'est une décision de gestion du risque. La voie DIY coûte en pratique plus cher que la variante avec consultant, prend plus de temps et se termine plus souvent avec des demandes de correction après audit.

Qui veut démarrer sans consultant a besoin au minimum d'un périmètre clairement délimité, d'une méthodologie d'évaluation des risques documentée et cohérente, ainsi que d'un audit préparatoire externe avant l'audit de Stade 1. Tous les autres devraient traiter l'investissement dans un conseil externe pour ce qu'il est : une prime d'assurance contre des erreurs évitables dans un projet qui jette les bases de toutes les futures attestations de sécurité.

Sources

[1] ISO/IEC 27001:2022. Information security, cybersecurity and privacy protection. Information security management systems. Requirements. International Organization for Standardization, Genève, 2022.

[2] Bundesamt für Sicherheit in der Informationstechnik (BSI). BSI-Standard 200-2 : IT-Grundschutz-Methodik. Version 1.0. BSI, Bonn, 2017. https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_2.pdf

[3] TeleTrusT -- Bundesverband IT-Sicherheit e.V. Leitfaden Informationssicherheit im Mittelstand. TeleTrusT, Berlin, 2024. https://www.teletrust.de/publikationen/leitfaeden/

[4] ENISA. Cybersecurity guide for Small and Medium-sized Enterprises. European Union Agency for Cybersecurity, Athènes, 2021. https://www.enisa.europa.eu/publications/cybersecurity-guide-for-smes

[5] IBM Security / Ponemon Institute. Cost of a Data Breach Report 2023. IBM Corporation, Armonk, NY, 2023. https://www.ibm.com/reports/data-breach

[6] Procida, Daniele. Diátaxis : A systematic framework for technical documentation. 2017 (mise à jour en continu). https://diataxis.fr