ISO/IEC 20000-1 : exigences et portée réelle de la certification

ISO/IEC 20000-1:2018 est la norme certifiable qui spécifie les exigences d’un système de management des services informatiques : comment une organisation planifie, fournit, mesure et améliore les services qu’elle rend à ses clients. Elle ne décrit pas une organisation idéale de l’exploitation. Elle exige une boucle de pilotage auditable, et la certification atteste que cette boucle tourne sur un périmètre déclaré, rien de plus.

→ Lire l’explication complète de la marmotte

ISO/IEC 20000-1:2018, la norme certifiable de la famille ISO/IEC 20000

La famille ISO/IEC 20000 est publiée conjointement par l’ISO (Organisation internationale de normalisation) et l’IEC (Commission électrotechnique internationale). Seule la partie 1 contient des exigences, c’est-à-dire des « doit » contre lesquels un auditeur peut lever un écart. Les autres parties sont des guides : la partie 2 explique l’application de la partie 1, la partie 3 traite la définition du périmètre, la partie 10 pose le vocabulaire. La partie 6 s’adresse aux organismes de certification eux-mêmes et complète ISO/IEC 17021-1 pour les audits de systèmes de management des services.

L’édition en vigueur est la troisième, publiée en septembre 2018 et reconduite sans modification en 2023. Elle adopte la structure de haut niveau commune aux normes ISO de management : clauses 4 à 10 (contexte, leadership, planification, support, fonctionnement, évaluation des performances, amélioration). Ce choix a une conséquence pratique majeure : une organisation déjà certifiée ISO/IEC 27001 partage avec ISO/IEC 20000-1 toute la mécanique de gouvernance (politique, objectifs, risques, audit interne, revue de direction, actions correctives). Seule la clause 8 diffère vraiment.

Le système exigé s’appelle SMS (système de management des services). L’acronyme entre en collision avec le SMSI (système de management de la sécurité de l’information) d’ISO/IEC 27001, et vingt ans de comités de pilotage apprennent qu’une réunion sur deux commence par cinq minutes pour savoir duquel on parle.

ITIL (Information Technology Infrastructure Library) n’est pas une alternative à ISO/IEC 20000-1. C’est un cadre de bonnes pratiques : il dit comment s’y prendre, il ne contient aucune exigence opposable, et aucune organisation ne peut être « certifiée ITIL ». Les certifications ITIL concernent des personnes. La relation se résume ainsi : ISO/IEC 20000-1 fixe le quoi, ITIL est une source parmi d’autres pour le comment. La page ITIL et la gestion des services numériques détaille le cadre lui-même.

Clause 8 : les processus de service que la certification audite

La clause 8 (fonctionnement du SMS) concentre les exigences propres au domaine. Elle est organisée en familles de processus, et chacune produit des preuves que l’auditeur vient chercher.

Famille (clause)	Processus exigés
Portefeuille de services (8.2)	fourniture des services, planification, maîtrise des parties intervenant dans le cycle de vie, catalogue de services, gestion des actifs, gestion des configurations
Relation et accords (8.3)	relation métier, gestion des niveaux de service, gestion des fournisseurs
Offre et demande (8.4)	budget et comptabilité des services, gestion de la demande, gestion de la capacité
Conception, construction et transition (8.5)	gestion des changements, conception et transition des services, gestion des mises en production et des déploiements
Résolution et exécution (8.6)	gestion des incidents, des demandes de service, des problèmes
Assurance du service (8.7)	disponibilité, continuité de service, sécurité de l’information

Trois exigences structurent le reste et méritent l’attention d’un architecte.

La maîtrise des autres parties (8.2.3). Une organisation peut confier l’exploitation d’un processus à un fournisseur, à un autre service interne ou au client. Elle reste responsable du respect des exigences et doit démontrer qu’elle gouverne ce processus. Externaliser la gestion des incidents chez un infogérant ne sort donc pas le processus du périmètre d’audit : l’auditeur demandera comment l’organisation le pilote, sur quels indicateurs, et avec quel droit de regard contractuel. Les clauses de sécurité d’un contrat fournisseur deviennent ici des preuves d’audit, pas seulement des protections juridiques.

La gestion des configurations (8.2.6). La norme exige que les éléments de configuration soient identifiés, enregistrés, maîtrisés et que leurs relations soient tenues à jour avec la précision nécessaire aux autres processus. Concrètement, il faut une CMDB (Configuration Management Database) ou équivalent, dont l’exactitude est vérifiée. Une CMDB alimentée à la main une fois par trimestre ne passe pas cette exigence : elle n’est exacte que le jour de sa saisie.

La gestion des changements (8.5.1). Une politique de changement doit définir ce qui est sous contrôle, les catégories de changements (dont les changements d’urgence), les critères d’évaluation des risques et la façon de décider. Les changements doivent être évalués, approuvés, planifiés, puis revus après coup. C’est le processus le plus souvent en écart, parce que c’est le seul que les équipes contournent spontanément dès qu’un incident fait monter la pression.

Le schéma suivant montre pourquoi ces processus ne valent rien séparément : la CMDB est le point de jointure qui permet de relier un incident au changement qui l’a provoqué.

Si l’une des flèches vers la CMDB manque, la corrélation disparaît et la gestion des problèmes revient à deviner. Le modèle de données d’IT4IT décrit précisément ces flèches, pour ceux qui préfèrent les dessiner avant de les perdre.

Sécurité de l’information dans le SMS : la clause 8.7.3 et ses limites

La clause 8.7.3 impose un processus de sécurité de l’information dans le SMS. Elle exige une politique de sécurité approuvée par la direction, une appréciation des risques sur les services menée à intervalles planifiés, des mesures de sécurité mises en œuvre et revues, ainsi qu’un traitement des incidents de sécurité avec la priorité qu’ils méritent. L’édition 2018 laisse l’organisation libre de s’appuyer ou non sur ISO/IEC 27001 pour y répondre.

C’est précisément le piège. Un certificat ISO/IEC 20000-1 prouve qu’un processus de sécurité existe et qu’il est évalué. Il ne prouve ni l’étendue des mesures, ni leur couverture d’un référentiel comme l’annexe A d’ISO/IEC 27001, ni leur efficacité technique. Un prestataire certifié ISO/IEC 20000-1 sans SMSI peut parfaitement avoir une politique de sécurité de deux pages et une appréciation des risques annuelle. La norme ne l’interdit pas, l’auditeur ne le sanctionnera pas.

La règle qui s’en déduit est sans nuance : pour qualifier la sécurité d’un fournisseur, un certificat ISO/IEC 20000-1 seul ne suffit jamais. Il faut un certificat ISO/IEC 27001 couvrant les mêmes services, et sa déclaration d’applicabilité. La page sur ce que garantit une certification ISO 27001 détaille ce que ce second certificat prouve à son tour, et ce qu’il ne prouve pas non plus.

Ce que la clause 8.7.3 apporte en revanche, et qu’ISO/IEC 27001 seul exprime moins nettement, c’est l’ancrage de la sécurité dans les flux d’exploitation. Les incidents de sécurité passent par le même processus de gestion des incidents que les pannes, avec une classification dédiée. Les changements sont évalués aussi sur leur impact sécurité. La continuité (8.7.2) exige des plans de continuité de service testés à intervalles planifiés et après tout changement majeur de l’environnement. Pour une organisation soumise à DORA (Digital Operational Resilience Act) ou à NIS2 (directive (UE) 2022/2555), ces processus fournissent une partie de la mécanique opérationnelle attendue (gestion des incidents liés aux TIC, tests de continuité, registre des fournisseurs), sans couvrir les exigences réglementaires elles-mêmes : délais de notification, tests de résilience, registre d’information, rien de tout cela n’est dans la norme. Voir DORA et la résilience opérationnelle numérique et les obligations NIS2.

Ce que la certification ISO/IEC 20000-1 prouve, et ce qu’elle ne prouve pas

Le certificat atteste qu’un organisme de certification a constaté, sur un échantillon, que le SMS couvrant le périmètre déclaré répond aux exigences de la norme. Le cycle suit ISO/IEC 17021-1 : audit initial en deux étapes (revue documentaire, puis audit de mise en œuvre), audits de surveillance annuels, renouvellement au bout de trois ans.

Ce qu’il ne prouve pas, point par point :

Un niveau de service. La norme exige des accords de niveau de service (SLA, Service Level Agreement) documentés et suivis. Elle ne fixe aucune valeur. Un SLA de disponibilité à 95 % mesuré au mois, avec maintenance exclue, est conforme. Un SLA raté plusieurs mois de suite l’est aussi, tant que l’écart est constaté, analysé et traité.
Un périmètre utile à l’acheteur. Le certificat porte sur les services listés dans sa déclaration de périmètre. Un hébergeur peut certifier son service de sauvegarde et vendre son offre de cloud managé à côté. Lire le certificat sans lire le périmètre revient à lire l’emballage sans lire la liste des ingrédients.
La sécurité. Voir la section précédente.
La qualité d’un outil. Aucun logiciel d’ITSM (IT Service Management) n’est « certifié ISO/IEC 20000-1 ». Un éditeur peut faire certifier le SMS qui exploite son offre SaaS, pas son produit. Une plaquette qui affirme le contraire confond le marteau et la charpente.
La compétence individuelle. Celle-ci relève des certifications de personnes, ITIL ou autres.

Le compromis central se formule ainsi : on gagne une discipline d’exploitation démontrable devant un tiers, avec une traçabilité des changements, des incidents et des fournisseurs qui résiste à un audit ; on paie une charge documentaire et une charge d’audit récurrentes, sans aucune garantie sur le niveau de service lui-même. La certification vaut l’investissement dans deux cas précis : une organisation qui vend des services sur engagement contractuel (infogérance, MSP pour Managed Service Provider, hébergement, DSI pour direction des systèmes d’information facturant ses services en interne) et dont les clients ou les appels d’offres réclament la preuve ; une organisation déjà dotée d’un SMSI qui peut mutualiser les clauses 4 à 10. Hors de ces cas, appliquer la norme sans viser le certificat donne l’essentiel du bénéfice pour une fraction du coût.

L’arbre de décision qui suit résume ce choix ; il se lit de haut en bas, une question par branche.

Prérequis et coût d’exploitation d’un SMS certifié

Avant un audit initial, plusieurs éléments doivent exister et fonctionner, pas seulement être rédigés :

une déclaration de périmètre nommant les services, les sites et les parties intervenantes (ISO/IEC 20000-3 aide à la rédiger) ;
un catalogue de services et des SLA signés pour chaque service du périmètre ;
un outil d’ITSM qui enregistre incidents, demandes, problèmes et changements avec horodatage et historique non modifiable par les opérateurs ;
une CMDB reliée à cet outil et alimentée par découverte automatique ou par les chaînes de déploiement, avec un contrôle périodique d’exactitude ;
des plans de continuité de service et au moins un test documenté ;
un registre des fournisseurs avec contrats et revues de performance ;
un audit interne complet du SMS et une revue de direction tenus avant l’audit de certification.

La partie la plus chère n’est pas l’audit. C’est la production continue de preuves : indicateurs mensuels par service, revues post-changement, revues de fournisseurs, comptes rendus de tests de continuité. Un SMS dont les preuves sont produites à la main par des équipes déjà en astreinte se dégrade en un cycle de surveillance. La règle d’architecture qui en découle : toute preuve que la norme exige de façon récurrente doit être extraite automatiquement des outils d’exploitation, jamais ressaisie. La page preuve de conformité : ce que l’auditeur vérifie traite cette question en général.

Ressemblance trompeuse : ISO/IEC 20000-1 et COBIT 2019 parlent tous deux de processus informatiques. COBIT est un cadre de gouvernance, non certifiable pour une organisation, qui s’adresse à la direction ; ISO/IEC 20000-1 s’adresse au fournisseur du service et se certifie.

Surface d’attaque des processus ITSM et contre-mesures

Un SMS ne se contente pas d’organiser l’exploitation : il crée des points de contrôle centralisés, donc des cibles. Les attaques connues portent sur les processus eux-mêmes, pas sur la norme.

L’outil d’ITSM comme cible privilégiée. Il connaît l’inventaire complet (la CMDB), les vulnérabilités en cours de traitement (tickets de problèmes), les fenêtres de maintenance et souvent des secrets collés dans les tickets. Il porte aussi des intégrations à privilèges : orchestration de déploiement, réinitialisation de comptes, création d’accès. Contre-mesures : authentification fédérée avec MFA (Multi-Factor Authentication) pour tous les comptes, comptes de service d’intégration à privilèges minimaux et à secrets renouvelés, détection automatique des secrets dans les champs libres, journalisation des accès exportée hors de l’outil.

L’ingénierie sociale par la demande de service. La gestion des demandes (8.6.2) industrialise la réinitialisation de mots de passe et l’octroi d’accès. Un attaquant qui appelle le centre de services en se faisant passer pour un utilisateur exploite exactement ce processus. La contre-mesure est une vérification d’identité hors bande définie dans la procédure, avec un niveau d’assurance plus élevé pour les comptes à privilèges, et non laissée à l’appréciation de l’opérateur.

Le contournement par le changement d’urgence. La catégorie « urgence » de la politique de changement est le chemin le plus court pour pousser une modification non revue. Contre-mesures : approbation a posteriori obligatoire sous un délai fixé, indicateur du taux de changements d’urgence suivi en revue de direction, alerte si ce taux dérive.

L’empoisonnement de la CMDB. Une CMDB écrite par trop de sources accepte des éléments fictifs ou des relations fausses, ce qui égare l’analyse d’impact et la réponse à incident. Contre-mesures : sources d’alimentation authentifiées, rapprochement automatique avec la découverte réseau, écarts traités comme des incidents.

Les fournisseurs intégrés au processus. Un infogérant qui exploite un processus pour le compte de l’organisation dispose d’accès à l’outil et souvent aux systèmes. Ces accès relèvent de la gestion des risques tiers : comptes nominatifs, revue périodique, retrait à la fin du contrat.

Conditions d’exploitation : secrets, supervision, sauvegarde et reprise du SMS

Le SMS dépend de ses outils, et la norme exige la continuité des services, pas celle de l’outil d’ITSM. C’est un angle mort fréquent : si l’outil d’ITSM est indisponible pendant une crise majeure, ce qui arrive précisément quand l’annuaire ou le réseau tombe, la gestion des incidents perd son support au pire moment. Le plan de continuité doit donc prévoir un mode dégradé de gestion des incidents (registre hors ligne, canal de coordination indépendant de l’authentification principale) et le tester.

Les secrets des intégrations (jetons d’API vers la supervision, l’orchestrateur, l’annuaire) doivent vivre dans un coffre de secrets, avec rotation planifiée et révocation documentée au départ d’un fournisseur. La sauvegarde de l’outil d’ITSM et de la CMDB doit être restaurable sur un environnement isolé : ces données sont à la fois des preuves d’audit et l’inventaire nécessaire à la reconstruction après une compromission. Une sauvegarde de la CMDB stockée dans le même domaine d’administration que les systèmes qu’elle décrit disparaît avec eux. Enfin, la conservation des enregistrements (tickets, journaux de changements) doit couvrir au minimum le cycle de certification de trois ans, sous réserve d’obligations plus longues imposées par d’autres textes.

Exemple : changement d’urgence et preuves attendues en audit

Cet exemple montre la logique que l’auditeur reconstitue sur un changement d’urgence : qui décide, dans quel ordre, et quelle trace prouve chaque étape. Un correctif de sécurité doit être appliqué hors fenêtre de maintenance, sur un service du périmètre.

Les preuves attendues se lisent sur les flèches. La demande de changement référence le ticket de problème. L’évaluation du risque cite les éléments de configuration touchés, ce qui suppose une CMDB exacte. L’approbation porte un nom et un horodatage. La CMDB reflète la nouvelle version. La revue a posteriori existe et respecte le délai prévu. L’indicateur remonte en revue de direction. L’écart le plus courant ne porte pas sur le déploiement mais sur la revue a posteriori, oubliée une fois l’urgence passée : un changement d’urgence sans revue est un changement non maîtrisé avec un meilleur libellé.

FAQ

Une certification ISO/IEC 20000-1 dispense-t-elle d’ISO/IEC 27001 ?

Non. La clause 8.7.3 exige un processus de sécurité de l’information, pas un SMSI complet ni la couverture d’un catalogue de mesures. Les deux normes se combinent bien dans un système intégré, puisque les clauses 4 à 10 sont communes.

Peut-on exclure des processus de la clause 8 ?

Les exigences des clauses 4 à 10 ne s’excluent pas. Un processus exploité par une autre partie reste dans le périmètre : l’organisation doit démontrer qu’elle le gouverne (8.2.3). Le levier légitime pour réduire l’effort est le périmètre de services, pas la liste des processus.

Faut-il appliquer ITIL pour être certifié ?

Non. La norme ne prescrit aucun cadre de pratiques. ITIL est une source fréquente pour concevoir les processus, mais l’auditeur vérifie le respect des exigences, pas la conformité à un cadre.

Sources

ISO/IEC 20000-1:2018, ISO/IEC.
ISO/IEC 20000-2, ISO/IEC.
ISO/IEC 20000-3, ISO/IEC.
ISO/IEC 20000-6, ISO/IEC.
ISO/IEC 20000-10, ISO/IEC.
ISO/IEC 17021-1, ISO/IEC.
ISO/IEC 27001, ISO/IEC.
Directive (UE) 2022/2555 (NIS 2), Union européenne.
Règlement (UE) 2022/2554 (DORA), Union européenne.

🐝 Ce qui arrive si on s’en passe

Sans gestion des changements reliée à une CMDB exacte, un incident ne se rattache plus au changement qui l’a causé : l’analyse de cause repart de zéro à chaque panne, et un changement malveillant se fond dans le bruit des changements légitimes. Sans maîtrise des parties intervenantes, l’organisation ignore ce que ses fournisseurs exécutent en son nom et ne peut ni le mesurer ni le retirer proprement. Sans plans de continuité testés, la première vérification a lieu pendant la crise. Sans enregistrements horodatés, aucune preuve ne permet de montrer à un client, à un auditeur ou à une autorité ce qui a été décidé, par qui et quand.

🦫 Explication de la marmotte 🍫

Une équipe informatique rend des services à d’autres : faire marcher une messagerie, garder des sauvegardes, héberger un site. La norme ISO/IEC 20000-1 liste ce que cette équipe doit obligatoirement organiser pour bien rendre ces services. D’abord, elle choisit quels services elle surveille et écrit ce qu’elle promet à ses clients. Ensuite, elle tient des registres : chaque panne, chaque demande, chaque modification des machines est notée avec la date et le nom de la personne qui a décidé. Une base de données décrit tous les équipements et leurs liens, ce qui permet de retrouver quelle modification a provoqué une panne. L’équipe teste aussi ses plans de secours et vérifie le travail de ses fournisseurs. Elle mesure ses résultats, sa direction les regarde et corrige ce qui ne va pas. Puis un contrôleur extérieur vient vérifier, chaque année, que tout cela fonctionne vraiment. S’il est satisfait, il délivre un certificat valable trois ans. Attention : ce certificat ne dit pas que le service est excellent, ni que les pirates ne peuvent pas entrer. Il dit seulement que l’équipe suit ses règles et les améliore. Si les registres sont mal tenus, on ne sait plus pourquoi une panne arrive, et le contrôleur relève une erreur à corriger.

Pages voisines

ISO/IEC 20000-1 : exigences et portée réelle de la certification

Elle cite

: les deux pages se citent l’une l’autre.

ISO/IEC 20000-1 : exigences et portée réelle de la certification

ISO/IEC 20000-1 : exigences et portée réelle de la certification

ISO/IEC 20000-1:2018, la norme certifiable de la famille ISO/IEC 20000

Clause 8 : les processus de service que la certification audite

Sécurité de l’information dans le SMS : la clause 8.7.3 et ses limites

Ce que la certification ISO/IEC 20000-1 prouve, et ce qu’elle ne prouve pas

Prérequis et coût d’exploitation d’un SMS certifié

Surface d’attaque des processus ITSM et contre-mesures

Conditions d’exploitation : secrets, supervision, sauvegarde et reprise du SMS

Exemple : changement d’urgence et preuves attendues en audit

FAQ

Une certification ISO/IEC 20000-1 dispense-t-elle d’ISO/IEC 27001 ?

Peut-on exclure des processus de la clause 8 ?

Faut-il appliquer ITIL pour être certifié ?

Sources

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines