Après mes derniers audits ISO 27001, je vois la même erreur.
Des entreprise qui déclarent applicables des contrôles qui n’ont aucun rapport avec leur réalité. Ils se compliquent la vie, perdent du temps, et dépensent de l’argent inutilement.
Le pire cas, une firme de services financiers avec aucun développeur et aucune ligne de code qui s’est imposé tous les contrôles de la norme. Leur consultant les avait convaincus que “c’était plus sûr comme ça”.
Si votre entreprise ne développe pas de logiciels, certains contrôles de l’ISO 27001:2022 ne s’appliquent pas à vous.
Dans mes audits, je constate que 70% des entreprises sans développement déclarent quand même applicables des contrôles qu’elles n’ont pas d’affaire à implémenter. Pour trois raisons:
Première raison : Leur consultant a peur. Il préfère dire “applicable” que de justifier pourquoi ce ne l’est pas. Plus facile de facturer des heures supplémentaires que d’expliquer la logique derrière une déclaration de non-applicabilité.
Deuxième raison : La direction pense qu’être “plus strict” c’est mieux. Non. C’est juste plus cher et plus compliqué pour rien.
Troisième raison : Personne n’a pris le temps de bien comprendre ce que fait réellement l’entreprise. On applique un “template” générique au lieu d’analyser le contexte spécifique.
Voici les contrôles non applicables
Quand votre entreprise ne fait aucun développement logiciel, ces cinq contrôles ne s’appliquent pas :
A8.4 — Accès au code source, clairement si nous n’avons pas de développement, il n’y a pas de code source à gérer!
A.8.25 — Cycle de vie de développement sécurisé Si vous n’avez pas d’équipe de développement, vous n’avez pas de cycle de développement.
A.8.26 — Exigences de sécurité applicatives Ce contrôle concerne les spécifications de sécurité pour vos propres applications. Pas celles que vous achetez ou louez. Si vous ne développez rien, ce contrôle ne vous concerne pas.
A.8.27 — Architecture sécurisée et principes d’ingénierie Porte sur la conception sécurisée des systèmes que vous développez. Encore une fois, sans développement, pas d’architecture à concevoir.
A.8.28 — Codage sécurisé Le plus évident. Pas de code, pas de codage sécurisé. Certaines entreprises pensent que configurer un logiciel c’est du “codage”. Non, c’est de la configuration.
A.8.29 — Tests de sécurité dans le développement Tests de sécurité sur le code en développement. Sans développement, ce contrôle tombe à l’eau.
Les zones grises qui créent la confusion
Trois contrôles créent souvent de la confusion :
A.8.30 — Développement externalisé Celui-là, c’est plus subtil. Si vous engagez des programmeurs externes pour développer quelque chose spécifiquement pour vous, ce contrôle s’applique. Mais si vous achetez un logiciel sur une étagère, même personnalisé, ça ne compte pas comme du développement externalisé.
A.8.31 — Séparation des environnements Pas besoin d’environnement de développement si vous ne développez pas. Par contre, si vous avez un environnement de test pour vos logiciels achetés, ce contrôle pourrait s’appliquer partiellement.
A.8.33 — Informations de test Si vous ne testez jamais rien, ce contrôle ne s’applique pas. Mais attention : la plupart des entreprises font au moins des tests d’acceptation sur leurs nouveaux logiciels.
Ce qui reste applicable
Le contrôle 8.32 — Gestion des changements reste presque toujours applicable, même sans développement. Parce que vous changez des configurations, mettez à jour des logiciels, modifiez des paramètres. Ça, c’est de la gestion des changements.
Pour les autres contrôles, tel que sécurité réseau, de gestion des accès, de sauvegarde, de formation ? Ils restent applicables puisqu’avec ou sans développement, ces mesures protègent votre environnement informatique, peu importe d’où viennent vos logiciels.
Comment bien évaluer l’applicabilité
Posez-vous ces questions simples :
- Est-ce que quelqu’un dans mon entreprise écrit du code ?
- Est-ce que nous avons des programmeurs à l’interne ?
- Est-ce que nous engageons des firmes pour développer des applications spécifiquement pour nous ?
- Est-ce que nous modifions le code source de nos logiciels ?
Si toutes les réponses sont “non”, alors les contrôles A8.4, 8.25 à 8.29 ne s’appliquent pas à vous.
La justification, c’est obligatoire
Quand vous déclarez un contrôle non applicable, vous devez le justifier par écrit dans votre Déclaration d’Applicabilité. Ce n’est pas optionnel, c’est une exigence de la norme.
Une bonne justification ressemble à ça :
“L’entreprise ne développe aucun logiciel à l’interne et ne fait appel à aucun fournisseur qui fait du développement. Tous les logiciels utilisés sont des solutions commerciales acquises sur le marché.”
Attention aux changements
Votre déclaration d’applicabilité n’est pas gravée dans le béton. Si votre entreprise évolue et commence à faire du développement, vous devrez réviser cette déclaration.
J’ai vu des entreprises qui ont commencé par acheter des logiciels, puis qui ont engagé des programmeurs pour les personnaliser. Du jour au lendemain, certains contrôles sont redevenus applicables.
Je vous invite à cliquer sur “Follow” pour continuer d’en apprendre plus sur les sujets liés à la sécurité de l’information et à la vie privée.
