ISO 27001 sans certification : le SMSI comme colonne vertébrale de la DSI
Lorsqu’on évoque ISO/IEC 27001, la première association est presque toujours la cybersécurité.
Analyse de risques, politiques de sécurité, contrôle des accès, gestion des incidents, audits, conformité…
C’est parfaitement logique : ISO/IEC 27001 est la norme de référence des Systèmes de Management de la Sécurité de l’Information (SMSI).
Mais pour une DSI, il existe une autre manière de regarder cette norme.
Et si le SMSI devenait la colonne vertébrale du management du système d’information ?
Non pas pour transformer toute la DSI en un gigantesque projet ISO 27001.
Non plus pour prétendre qu’ISO 27001 répond à tous les besoins d’un DSI.
Mais pour disposer d’un cadre commun permettant de relier les enjeux métier, les actifs du SI, les dépendances, les fournisseurs, les risques, les responsabilités, les contrôles, les incidents et les décisions d’amélioration.
Et cela sans nécessairement chercher à obtenir une certification ISO/IEC 27001.
ISO 27001 est d’abord un système de management
ISO/IEC 27001 ne se résume pas à une liste de mesures techniques de cybersécurité.
Elle demande à l’organisation de mettre en place un véritable système de management permettant notamment de :
comprendre son contexte et ses enjeux ;
identifier les parties prenantes et leurs attentes ;
définir un périmètre ;
identifier et évaluer les risques ;
déterminer des responsabilités ;
définir des objectifs ;
mettre en œuvre des mesures adaptées ;
surveiller leur efficacité ;
gérer les incidents et les écarts ;
mesurer les résultats ;
auditer le dispositif ;
conduire des revues de direction ;
améliorer continuellement le système.
Vue sous cet angle, une question apparaît :
combien de ces sujets concernent exclusivement la cybersécurité ?
Très peu.
Ils sont, pour une grande partie, au cœur du métier d’une DSI.
C’est ce qui rend l’approche particulièrement intéressante.
Le problème : la gouvernance du SI est souvent fragmentée
Dans beaucoup d’organisations, le pilotage du système d’information s’est construit progressivement.
On trouve alors :
une cartographie applicative quelque part ;
un inventaire du matériel ailleurs ;
des contrats fournisseurs dans un autre outil ;
un tableau des projets ;
une procédure de sauvegarde ;
quelques documents de PRA ;
des tickets d’incidents ;
une politique de sécurité ;
un registre des risques ;
des indicateurs pour la direction ;
des procédures d’arrivée et de départ des collaborateurs ;
des documents RGPD ;
des audits réalisés ponctuellement ;
et beaucoup de connaissances qui restent dans la tête de quelques personnes.
Chaque élément peut être pertinent.
Le problème vient de l’absence de système reliant l’ensemble.
La DSI dispose alors d’outils, de procédures et de documents, mais pas nécessairement d’un véritable système de management.
C’est précisément là que l’approche SMSI devient intéressante.
Partir des enjeux métier et des risques plutôt que de la technologie
Une DSI peut facilement raisonner par solutions :
Nous devons remplacer le firewall.
Nous devons migrer les serveurs.
Nous devons déployer du MFA.
Nous devons changer l’ERP.
Nous devons améliorer les sauvegardes.
Une approche inspirée d’ISO 27001 inverse le raisonnement.
Elle commence par demander :
Quels sont les processus et services essentiels à l’entreprise ?
Puis :
De quoi dépendent-ils ?
Et enfin :
Quels événements pourraient empêcher l’entreprise d’atteindre ses objectifs ?
Prenons un processus métier critique : la prise de commandes.
Son fonctionnement peut dépendre de :
Processus métier → ERP → base de données → infrastructure/cloud → réseau → identité → collaborateurs → prestataires
À partir de là, la DSI peut identifier les risques associés :
indisponibilité de l’ERP ;
compromission d’un compte administrateur ;
corruption de données ;
panne d’un fournisseur cloud ;
erreur humaine ;
absence d’une personne clé ;
dépendance excessive envers un prestataire ;
sauvegarde inexploitable ;
modification non maîtrisée ;
capacité insuffisante ;
cyberattaque.
La cybersécurité apparaît naturellement dans cette analyse.
Mais elle n’en représente qu’une partie.
On ne cherche plus uniquement à sécuriser le SI. On cherche à maîtriser les risques que le SI fait peser sur l’activité de l’entreprise.
Le SMSI comme colonne vertébrale, pas comme système unique
C’est ici qu’une distinction est essentielle.
ISO 27001 n’est pas un référentiel complet de management d’une DSI.
La norme ne dira pas au DSI :
comment arbitrer entre 30 projets ;
comment construire son budget informatique ;
s’il faut remplacer son ERP ;
comment définir son architecture cible ;
comment optimiser ses licences SaaS ;
comment organiser son support utilisateurs ;
comment mesurer précisément le coût complet d’une application ;
comment construire une stratégie d’innovation ;
comment gérer son portefeuille de projets.
D’autres méthodes, référentiels et pratiques sont plus adaptés à ces sujets.
En revanche, le SMSI peut fournir la structure commune permettant de les relier aux enjeux et aux risques de l’entreprise.
On pourrait représenter cette gouvernance ainsi :
GOUVERNANCE DE LA DSI
↓
SMSI / ISO 27001
Risques – responsabilités – contrôles – mesure – amélioration continue
↓
Services IT | Projets | Architecture | Fournisseurs | Finance IT | Continuité | Cybersécurité | Transformation
Le SMSI n’est donc pas le bâtiment entier.
Il peut en constituer l’ossature.
Jusqu’où le SMSI peut-il réellement structurer une DSI ?
Utiliser le SMSI comme colonne vertébrale ne signifie pas qu’ISO 27001 apporte une réponse complète à tous les métiers d’une DSI.
Certains domaines sont directement au cœur du système de management. D’autres bénéficient fortement de sa logique de gouvernance et de maîtrise des risques. Enfin, certaines disciplines restent largement en dehors de son périmètre et doivent être complétées par d’autres pratiques.
| Domaine de la DSI | Apport du SMSI | Ce qu’il apporte concrètement | Ce qu’il faut compléter |
|---|---|---|---|
| Cybersécurité | Très fort | Identification des risques, mesures de sécurité, contrôles, responsabilités, suivi et amélioration | Outils, expertise technique et processus opérationnels adaptés au contexte |
| Gouvernance par les risques | Très fort | Identification, évaluation, traitement, acceptation et revue des risques | Mise en perspective avec l’ensemble des risques et objectifs de l’entreprise |
| Responsabilités et traçabilité | Très fort | Responsabilités, contrôles, preuves, audits, décisions et actions correctives | Organisation opérationnelle propre à chaque entreprise |
| Dialogue avec la direction | Très fort | Présentation du SI sous l’angle risques, impacts, priorités, décisions et arbitrages | Stratégie SI, business cases et création de valeur |
| Continuité et résilience | Fort | Identification des besoins de continuité, dépendances, scénarios, mesures et tests | BIA détaillé, PCA/PRA et organisation de crise adaptés à l’entreprise |
| Gestion des fournisseurs | Fort | Identification des fournisseurs critiques, risques associés, exigences de sécurité, suivi | Achats, négociation, gestion économique des contrats, sourcing et stratégie fournisseurs |
| Gestion des actifs | Fort | Identification des actifs importants, responsabilités, classification et protection | CMDB, gestion de parc, licences, cycle de vie technique et optimisation des actifs |
| Gestion des changements | Partiel à fort | Identification et maîtrise des risques introduits par les changements | Processus opérationnel de change management, déploiement, tests et gestion des releases |
| Gestion des incidents | Partiel à fort | Détection, réponse, analyse des causes, actions correctives et amélioration | Service desk, SLA, gestion quotidienne des tickets et processus ITSM |
| Gestion opérationnelle IT | Partiel | Cadre de contrôle, responsabilités, surveillance et maîtrise de certains risques opérationnels | Catalogue de services, SLA, demandes utilisateurs, support, capacité, disponibilité et pratiques ITSM |
| Portefeuille et projets | Faible / indirect | Prise en compte des risques et exigences de sécurité dans les projets | Priorisation, allocation des ressources, gouvernance portefeuille, méthodes projet et mesure de la valeur |
| Architecture SI | Faible / indirect | Exigences de sécurité et maîtrise des risques dans les choix d’architecture | Architecture d’entreprise, urbanisation, architecture cible, standards techniques et trajectoire SI |
| Finance IT | Faible / indirect | Peut aider à justifier certains investissements par les risques qu’ils réduisent | Budget, TCO, ROI, CAPEX/OPEX, FinOps, optimisation SaaS et contrôle de gestion IT |
| Innovation et transformation | Faible / indirect | Permet d’évaluer et de maîtriser les risques introduits par les nouvelles technologies | Détection des opportunités, innovation, expérimentation, transformation métier et création de valeur |
Ce tableau fait apparaître une distinction essentielle.
Le SMSI est particulièrement puissant pour répondre à la question :
« Comment savons-nous ce qui est important, quels risques nous portons, qui en est responsable et si nos dispositifs de maîtrise fonctionnent ? »
Il est beaucoup moins adapté pour répondre à :
« Quelle doit être notre architecture cible ? Quel ERP devons-nous choisir ? Quels projets devons-nous prioriser ? Quel doit être notre budget IT ? Quelle technologie pourrait transformer notre métier ? »
C’est pourquoi il serait excessif de dire :
« ISO 27001 permet de gérer une DSI. »
En revanche, il est beaucoup plus pertinent de dire :
« Un SMSI inspiré d’ISO 27001 peut fournir la colonne vertébrale de gouvernance sur laquelle la DSI vient raccrocher ses autres disciplines de management. »
La distinction est importante.
Elle évite de transformer ISO 27001 en référentiel universel tout en exploitant ce qu’elle apporte de particulièrement puissant : une méthode structurée pour relier enjeux métier, actifs, dépendances, risques, responsabilités, contrôles, preuves, décisions et amélioration continue.
Relier les objets du SI
C’est probablement l’un des bénéfices les plus importants de cette approche.
Prenons un serveur.
Dans un inventaire classique, nous pouvons connaître :
son nom, son adresse IP, son système d’exploitation, sa version et son emplacement.
C’est utile.
Mais pour piloter le SI, nous voulons également savoir :
Quel service fournit-il ?
Quel processus métier dépend de ce service ?
Quelle serait la conséquence de son indisponibilité ?
Existe-t-il une dépendance à un fournisseur ?
Qui en est responsable ?
Quels risques lui sont associés ?
Quelles mesures permettent de réduire ces risques ?
Comment savons-nous que ces mesures fonctionnent ?
On obtient progressivement une chaîne :
Processus métier
↓
Services SI
↓
Actifs
↓
Dépendances / fournisseurs
↓
Risques
↓
Mesures de maîtrise
↓
Responsables
↓
Indicateurs et preuves
↓
Incidents / écarts
↓
Actions d’amélioration
Cette chaîne constitue une représentation beaucoup plus intéressante du SI qu’une simple juxtaposition d’inventaires.
Un langage commun entre la DSI et la direction
Cette approche transforme également la relation avec la direction générale.
Un COMEX comprend difficilement une discussion portant uniquement sur :
versions de firewall ;
architecture réseau ;
EDR ;
patch management ;
technologie de sauvegarde.
En revanche, il comprend parfaitement :
« Notre processus de facturation dépend actuellement d’un composant qui constitue un point de défaillance unique. Une panne prolongée empêcherait la facturation pendant plusieurs jours. »
Ou :
« Nous avons identifié quatre risques SI dont le niveau dépasse actuellement celui que nous considérons comme acceptable. Voici les investissements possibles pour les réduire. »
La conversation change.
La DSI ne demande plus seulement :
« Puis-je obtenir 50 000 € pour remplacer cette infrastructure ? »
Elle explique :
« Voici le risque que nous portons actuellement. Voici son impact potentiel. Voici ce que coûterait sa réduction. Quelle décision souhaitons-nous prendre ? »
La direction peut alors réellement arbitrer.
Et surtout, elle peut parfois décider d’accepter un risque.
Car une bonne gouvernance du SI ne consiste pas à éliminer tous les risques.
Elle consiste à les connaître et à prendre consciemment les décisions appropriées.
Gestion des fournisseurs
Prenons un autre exemple : les fournisseurs.
Une DSI doit connaître ses fournisseurs critiques, les services qu’ils fournissent, leurs engagements, leurs dépendances et les conséquences d’une défaillance.
Le fournisseur peut alors être intégré dans une chaîne :
Fournisseur → Service fourni → Actifs concernés → Processus métier dépendants → Risques → Contrôles → Suivi
Un renouvellement de contrat n’est plus uniquement une opération administrative.
Il devient l’occasion de se demander :
Ce fournisseur est-il toujours critique ?
Existe-t-il une dépendance excessive ?
Avons-nous une stratégie de sortie ?
Ses engagements sont-ils adaptés à la criticité du service ?
Gestion des changements
Une modification importante du SI peut provoquer :
une indisponibilité ;
une régression fonctionnelle ;
une perte de données ;
une vulnérabilité ;
un problème de performance.
La gestion du changement devient donc également un mécanisme de maîtrise du risque.
La question n’est plus seulement :
« Le changement a-t-il été réalisé ? »
mais :
« Avons-nous correctement maîtrisé les risques introduits par ce changement ? »
Continuité d’activité et reprise informatique
Le PRA cesse également d’être un document isolé que l’on ressort une fois par an.
Il découle directement de l’analyse :
Processus critique → dépendances → scénario d’interruption → impact → objectif de reprise → dispositifs de continuité → tests
Cela permet notamment d’éviter un travers fréquent :
investir beaucoup pour protéger des systèmes peu critiques et insuffisamment sur ceux dont l’entreprise dépend réellement.
Les incidents deviennent une source d’amélioration
Dans une organisation peu structurée :
Incident → réparation → fermeture du ticket.
Dans un système de management :
Incident → cause → risque concerné → contrôle défaillant → action corrective → vérification de l’efficacité.
Cette différence est fondamentale.
L’incident n’est plus uniquement quelque chose qu’il faut résoudre.
Il devient une information permettant d’améliorer le système.
Mais tout n’est pas un risque
C’est également l’une des limites qu’il faut accepter.
Prenons un CRM dont l’ergonomie fait perdre plusieurs minutes par jour aux commerciaux.
On peut toujours transformer le problème en :
« risque de perte de productivité lié à l’ergonomie du CRM ».
Mais cela devient artificiel.
La DSI doit également savoir gérer :
la performance des services ;
la satisfaction utilisateur ;
les opportunités ;
l’innovation ;
la transformation numérique ;
la dette technique ;
les projets ;
les coûts.
Une gouvernance exclusivement orientée risques pourrait produire une DSI excellente pour protéger l’entreprise, mais insuffisamment orientée vers sa transformation.
Le SMSI doit donc rester une colonne vertébrale.
Pas une grille dans laquelle on cherche à faire entrer artificiellement chaque décision informatique.
Attention à l’usine documentaire
C’est probablement le principal danger de l’approche.
Mettre en place un SMSI ne doit pas consister à produire des dizaines de procédures simplement pour pouvoir démontrer qu’elles existent.
La bonne règle pourrait être :
Ne documenter que ce qui aide à décider, exécuter, contrôler ou prouver.
Un registre de risques doit servir à décider.
Une cartographie doit permettre de comprendre les dépendances.
Un indicateur doit permettre de détecter une dérive.
Une procédure doit permettre de reproduire correctement une opération.
Une preuve doit démontrer qu’un contrôle fonctionne réellement.
Et lorsque cela est possible :
automatiser la preuve plutôt que documenter l’activité.
Si l’outil IAM démontre automatiquement que 100 % des comptes concernés disposent du MFA et conserve l’historique des contrôles, produire parallèlement un document Word uniquement pour « faire ISO » apporte peu de valeur.
L’objectif n’est surtout pas de construire un SMSI à côté de la DSI.
Le fonctionnement normal de la DSI doit progressivement alimenter naturellement le système de management.
Et sans certification ?
C’est un autre point important.
Utiliser ISO/IEC 27001 ne signifie pas nécessairement vouloir être certifié ISO/IEC 27001.
La certification peut être particulièrement pertinente lorsqu’elle répond à un besoin :
exigence d’un client ;
réponse à des appels d’offres ;
environnement réglementé ;
besoin de démontrer son niveau de maîtrise ;
développement international ;
avantage concurrentiel.
Mais une PME ou une ETI peut parfaitement décider :
« Nous allons utiliser les principes d’ISO 27001 pour structurer notre gouvernance du SI, sans chercher pour l’instant à obtenir le certificat. »
Cela permet notamment d’adapter le niveau de formalisme à la réalité de l’entreprise.
Sans certification ne signifie pas sans audit
Il existe néanmoins un risque.
Lorsqu’une organisation construit elle-même son système, l’évalue elle-même et conclut elle-même qu’il fonctionne correctement, elle peut développer une vision trop optimiste de sa maturité.
L’absence de certification ne devrait donc pas signifier :
absence de regard extérieur.
Un audit indépendant périodique peut être extrêmement utile, même sans aucun objectif de certification.
Son rôle n’est alors pas d’obtenir un certificat.
Il est de challenger le dispositif :
Les risques sont-ils réellement identifiés ?
Les contrôles fonctionnent-ils ?
Les preuves existent-elles ?
Les responsabilités sont-elles réellement assumées ?
Les plans d’action progressent-ils ?
Le système améliore-t-il réellement la maîtrise du SI ?
On conserve ainsi une grande partie de la valeur de l’audit tout en restant libre du niveau de formalisme recherché.
Un modèle pragmatique pour une PME ou une ETI
Le premier niveau peut finalement rester relativement simple.
1. Comprendre l’entreprise
Quels sont ses objectifs, contraintes, obligations et priorités ?
2. Identifier les processus critiques
Qu’est-ce qui doit absolument fonctionner ?
3. Cartographier les services, actifs et dépendances SI
De quoi ces processus dépendent-ils ?
4. Identifier et évaluer les risques
Que peut-il se passer et quelles seraient les conséquences ?
5. Définir les mesures de maîtrise
Que faisons-nous pour réduire ces risques ?
6. Affecter les responsabilités
Qui décide ? Qui exécute ? Qui contrôle ?
7. Mesurer
Comment savons-nous que les dispositifs fonctionnent réellement ?
8. Gérer les incidents et les écarts
Qu’avons-nous appris ?
9. Maintenir un plan d’amélioration
Que devons-nous corriger, renforcer ou transformer ?
10. Organiser une revue régulière avec la direction
Quels risques restent acceptables ? Lesquels nécessitent une décision ou un investissement ?
Puis autour de cette colonne vertébrale peuvent venir se greffer les dispositifs nécessaires à l’entreprise :
gestion des services, portefeuille projets, architecture, gestion fournisseurs, pilotage financier, innovation et transformation.
De la DSI technique à la gouvernance du SI
C’est finalement là que réside le principal intérêt de cette approche.
L’objectif n’est plus seulement :
« Comment sécuriser notre système d’information ? »
La question devient :
« Comment maîtriser notre système d’information pour qu’il contribue durablement aux objectifs de l’entreprise ? »
La sécurité en constitue une composante essentielle.
Mais elle côtoie la continuité, les fournisseurs, les compétences, les accès, les changements, l’obsolescence, les dépendances technologiques, les coûts, la qualité des services et les capacités de transformation.
ISO/IEC 27001 ne fournit pas toutes les réponses à ces questions.
Et elle n’a pas vocation à le faire.
En revanche, elle apporte quelque chose de particulièrement précieux : une logique structurée fondée sur les enjeux, les risques, les responsabilités, la mesure et l’amélioration continue.
C’est pourquoi un SMSI peut devenir la colonne vertébrale du système de management d’une DSI, sans prétendre en être la totalité.
La certification pourra venir plus tard si elle présente un intérêt commercial, réglementaire ou stratégique.
Mais elle n’est pas nécessaire pour commencer.
Le véritable objectif n’est pas d’avoir un certificat au mur.
C’est d’avoir un système d’information dont les dépendances sont comprises, les risques connus, les décisions assumées, les responsabilités établies et l’amélioration continue organisée — tout en conservant la capacité d’innover et de transformer l’entreprise.