Grundschutz++ et le standard BSI 300-1 : méthodologie, catalogue d’application et chemin vers la certification

Trois composantes, un seul référentiel

Le BSI met à disposition le Grundschutz++ pour la mise en place d’un système de management de la sécurité de l’information. La méthodologie est décrite par le standard BSI 300-1 ; selon la présentation du BSI, elle laisse aux utilisatrices et aux utilisateurs une marge de manœuvre, par exemple au regard de la taille de l’institution et de la complexité du réseau d’information. Le catalogue d’application complète la méthodologie : le BSI a transposé ses aspects normatifs en exigences, de sorte que le catalogue regroupe toutes les exigences Grundschutz++ – celles de la méthodologie comme les exigences techniques et organisationnelles. Il est mis à disposition dans la bibliothèque de l’état de l’art, la plateforme technique sur laquelle le BSI publie les exigences et les mesures de manière centralisée et lisible par machine. Les exigences étant disponibles sous une forme lisible par machine, leur vérification devient automatisable ; à l’avenir, selon le BSI, des outils numériques sont appelés à soutenir la mise en œuvre.

Ce que GS++ remplace – et ce qui subsiste pour l’instant

Selon le BSI, la bibliothèque de l’état de l’art remplace le Compendium IT-Grundschutz. En tant qu’évolution de l’IT-Grundschutz, le catalogue d’application ne décrit plus que des exigences qui ne visent pas des solutions informatiques spécifiques ; le catalogue du noyau (Kernel), dont proviennent les 901 exigences techniques et organisationnelles, ne contient, d’après sa description, que des exigences de sécurité neutres vis-à-vis des technologies et des fabricants. Les modules liés à des produits, tels que ceux que l’édition 2023 du Compendium comportait par exemple pour « Windows Server 2012 » ou « Clients unter macOS » (clients sous macOS), n’ont donc pas d’équivalent spécifique à un produit dans le catalogue d’application ; pour de tels systèmes s’appliquent les exigences, neutres vis-à-vis des solutions, des catégories d’objets cibles correspondantes. Au lieu de 111 modules répartis en dix couches, le catalogue s’articule en 20 pratiques ; ce sont les catégories d’objets cibles qui déterminent quelles exigences s’appliquent à un actif. De notre point de vue, les nombres d’exigences du Compendium et du catalogue ne sont donc que partiellement comparables, et le BSI lui-même ne conçoit pas sa correspondance entre le Compendium et GS++ comme une transposition 1:1, mais comme une aide à l’orientation ; au 21/07/2026, elle est signalée comme étant à l’état de projet. Pour l’instant, l’IT-Grundschutz reste certifiable : selon le calendrier des jalons, la certifiabilité prend fin le 30/11/2031, cinq ans après la publication de GS++. Les demandes de certification ISO 27001 sur la base de GS++ doivent pouvoir être déposées à partir du 01/01/2027 ; la phase early adopter est prévue du premier trimestre 2027 au 31/12/2027. Selon ses propres indications, le BSI adapte en permanence le calendrier des jalons.

Caractère contraignant : administration fédérale et entités NIS2

Pour les entités de l’administration fédérale allemande, la loi BSI, dans sa version issue de la loi allemande de transposition de NIS2 du 2 décembre 2025, prescrit des exigences minimales qui découlent des standards BSI, du Compendium IT-Grundschutz – désignés ensemble dans la loi sous le nom « IT-Grundschutz » – et des standards minimaux du BSI pour l’administration fédérale. Leur respect doit être démontré au BSI au plus tard cinq ans après l’entrée en vigueur de la loi, soit en 2030 selon le BSI ; quiconque met en œuvre les exigences minimales satisfait ainsi en même temps aux prescriptions légales en matière de gestion des risques, pour autant qu’aucun acte d’exécution de l’UE n’aille au-delà. La même loi charge le BSI de moderniser l’IT-Grundschutz d’ici le 1er janvier 2026, et le catalogue d’application renvoie dans ses métadonnées précisément à ces prescriptions pour l’administration fédérale. Aucune des sources primaires analysées pour cette page ne précise expressément à partir de quand GS++ fait foi en tant que version de référence au sens de cette obligation. Pour les entités particulièrement importantes et les entités importantes, la loi BSI ne mentionne pas l’IT-Grundschutz : leurs mesures doivent respecter l’état de l’art et tenir compte des normes européennes et internationales pertinentes. De notre point de vue, GS++ constitue pour elles une voie possible, et non une voie prescrite.

Structure : six chapitres, quatre annexes

Public cible, élaboration, compléments annoncés

Dans l’historique des modifications, la version 1.0 porte la date du 20/10/2026 et la mention « Publication initiale de la première version applicable » ; elle indique comme auteur « S 13 », soit, selon l’organigramme du BSI, l’unité « IT-Grundschutz und Mindeststandards » (IT-Grundschutz et standards minimaux). Selon le calendrier des jalons, le standard a été présenté le 27/10/2026 à l’it-sa de Nuremberg et mis à la disposition de la communauté pour application. Le public cible est constitué en premier lieu des early adopters, c’est-à-dire d’institutions expérimentées qui adoptent GS++ tôt et dont l’expérience alimente son évolution. La méthodologie a été élaborée conjointement avec la communauté Grundschutz et éprouvée dans des institutions pilotes sélectionnées ; la phase pilote s’est déroulée du 1er avril au 31 août 2026. Le « Leitfaden zur Methodik Grundschutz++ » (Guide de la méthodologie Grundschutz++) issu de cette phase reste consultable, mais c’est le standard qui fait foi. Plusieurs éléments ne sont encore qu’annoncés par le BSI : des concepts de formation pour les praticiens GS++ et les conseillers GS++ pour le 30/11/2026, un exemple d’application reposant sur l’administration fictive « BDIT » en décembre 2026, le concept de mesure de la performance pour le 26/02/2027 et des indicateurs de performance pour chaque exigence des pratiques méthodologiques pour le 31/03/2027.

Cinq étapes du processus, quatre phases PDCA

Le standard décrit ; il devient contraignant par le biais du catalogue : le BSI a transposé les contenus normatifs de la méthodologie en exigences et les a structurés en pratiques méthodologiques. Ces 99 exigences valent pour toutes les institutions et doivent être appliquées à chaque réseau d’information ; « une démarche individuelle n’est pas prévue ». Le degré de rigueur d’une obligation donnée est déterminé par le verbe modal du catalogue d’application : sur les 99 exigences méthodologiques, 80 sont des exigences DOIT, 19 des exigences DEVRAIT et aucune n’est une exigence PEUT. Le texte du standard et le catalogue ne mettent d’ailleurs pas toujours l’accent sur les mêmes points. À plusieurs endroits, le standard formule une recommandation là où le catalogue exige DOIT ; pour le risque résiduel des exigences DEVRAIT ouvertes, c’est l’inverse. Recommandation VamiSec : planifiez en vous fondant sur les exigences du catalogue et utilisez le texte du standard comme explication.

Contexte, conformité et périmètre

L’analyse du contexte recense les facteurs qui agissent de l’extérieur sur l’institution – géopolitiques, juridiques et réglementaires comme NIS2 ou DORA, technologiques comme le recours à l’IA, économiques comme les dépendances vis-à-vis des chaînes d’approvisionnement, sociétaux ainsi qu’écologiques et physiques, par exemple l’implantation au bord d’un cours d’eau –, et les facteurs internes : stratégies et objectifs, structure, processus établis, paysage informatique sans inventaire détaillé, culture de l’institution et attitude à l’égard de la sécurité ainsi que le manque de ressources. La gestion de la conformité apporte le registre des exigences légales, les lois et les catalogues d’exigences, les référentiels internes ainsi que les obligations légales et contractuelles ; ce qui en découle est pris en compte dans le jeu d’exigences. Le périmètre est fixé par la direction de l’institution : les processus métier, et ce dans leur intégralité, les unités de l’institution, sites, applications et systèmes informatiques pertinents, ainsi que la délimitation vis-à-vis des partenaires et des prestataires externes et, le cas échéant, les domaines exclus. Les parties intéressées telles que les clients, les prestataires, les autorités de surveillance, les collaborateurs ou les représentations du personnel sont recensées avec leurs attentes ; il est déterminé avec la direction quelles obligations contraignantes sont intégrées au SMSI en tant qu’exigences.

Processus métier : aussi simple que possible, aussi précis que nécessaire

Les processus métier du périmètre doivent être identifiés et documentés ; sont également visées les procédures administratives et les procédures spécialisées. Ils constituent la base de la détermination du besoin de protection, de l’inventaire des actifs et de l’analyse des risques. Pour la documentation, il suffit selon le standard que la finalité du processus soit identifiable au regard des objectifs de l’institution. Les sources sont les cartographies des processus et les systèmes de management existants, comme un BCMS (système de management de la continuité d’activité) ou un DSMS (système de management de la protection des données), et, pour les autorités, leurs missions légales. En l’absence de telles vues d’ensemble, l’analyse simplifiée des processus métier présentée en annexe du standard, délibérément conçue comme une exigence minimale, est utile : ne sont exigées ni une gestion exhaustive des processus ni une documentation détaillée des processus.

1. 1
   Examiner les déroulements

   Un processus métier se répète régulièrement ou en fonction des événements, est essentiel pour la mission ou les prestations de l’institution, aboutit à un résultat traçable et se compose de plusieurs activités liées entre elles sur le fond. Des étapes de travail isolées ne sont pas des processus métier ; un découpage trop fin devrait être évité.

2. 2
   Exploiter les sources existantes

   Organigrammes et plans de répartition des tâches, missions légales ou statutaires, registre des activités de traitement, vues d’ensemble des applications et des systèmes issues de la CMDB, répertoires de processus, outils SMSI ainsi que vues d’ensemble des contrats et des prestataires. L’entretien avec les personnes compétentes peut s’avérer particulièrement utile.

3. 3
   Documenter cinq informations

   Identifiant, nom, personne, rôle ou unité organisationnelle responsable sur le plan métier, description succincte et applications essentielles. La description succincte doit faire apparaître la finalité, le résultat essentiel et la contribution aux objectifs de l’institution ; la forme – tableau, répertoire de processus, wiki ou outil SMSI – est laissée au libre choix.

Politique de sécurité de l’information, organisation de la sécurité et approbation

La politique de sécurité de l’information est le document central du SMSI : elle décrit des objectifs concrets et mesurables, par exemple selon les critères SMART, ainsi que la stratégie, fixe l’engagement et la responsabilité de la direction de l’institution, est approuvée par celle-ci et doit être communiquée à l’ensemble du personnel. Une organisation de la sécurité de l’information dotée de rôles et de responsabilités définis est « impérativement requise ». Les conflits d’intérêts, par exemple entre la direction informatique et l’ISB ou entre le délégué à la protection des données et l’ISB, sont à éviter, et l’ISB ou un autre rôle de l’organisation de la sécurité doit être associé aux projets pertinents pour la sécurité. Des procédures pour la communication interne et externe ainsi que pour la maîtrise, au minimum, de tous les documents pertinents pour le SMSI doivent être ancrées. La responsabilité du SMSI incombe à la direction de l’institution et « ne peut pas être déléguée » ; celle-ci reçoit des dossiers de décision sur le périmètre, le besoin de protection, l’ordre de traitement des processus métier, les ressources et la politique de sécurité de l’information. Pour finir, l’institution initie l’analyse des risques : l’appétence au risque et les critères d’acceptation du risque au niveau stratégique, les procédures et les critères au niveau méthodologique, les rôles, y compris les propriétaires du risque, au niveau organisationnel – la direction autorise ce cadre.

Lors de la détermination du besoin de protection, il est décidé pour chaque processus métier recensé quel besoin de protection il présente au regard des valeurs fondamentales que sont la confidentialité, l’intégrité et la disponibilité. Il convient de s’appuyer sur les informations traitées dans le processus ; ce sont les dommages susceptibles de découler d’une atteinte qui sont déterminants. Le besoin de protection doit être déterminé et documenté individuellement pour chaque processus, et la direction de l’institution l’approuve. Le catalogue d’application fait de la procédure et de la classification des exigences DOIT et les rapporte aux « processus métier ou informations » ; la classification s’effectue en tenant compte des objectifs métier et en concertation avec la direction de l’institution. Selon le texte explicatif, un processus doit être classé « élevé » lorsque sont à craindre des dommages financiers ou de réputation menaçant l’existence de l’institution ou des conséquences lourdes sur les objectifs métier ou sur les obligations existantes, de même lorsqu’il traite des informations classées comme particulièrement confidentielles.

Cinq scénarios de dommages, une aide pour la catégorie « élevé »

• Violation de lois, de réglementations ou de contrats aux conséquences menaçant l’existence de l’institution
• Atteinte au droit à l’autodétermination informationnelle entraînant un préjudice considérable pour la réputation
• Atteinte à l’intégrité des personnes
• Effet négatif en interne ou à l’extérieur portant durablement atteinte à la réputation de l’institution
• Conséquences financières d’une ampleur menaçant l’existence de l’institution

L’institution peut, à titre optionnel, définir d’autres catégories propres, mais doit les faire correspondre aux deux catégories GS++ ; pour un SMSI certifiable, l’état de l’art doit toujours être respecté dans la catégorie la plus basse. Pour la première mise en place, le standard recommande de commencer par le processus métier le plus important de la plus haute catégorie de besoin de protection – s’il y en a plusieurs, la direction de l’institution choisit – puis d’examiner successivement tous les processus du périmètre. Le BSI rapporte l’état de l’art publié à des situations de traitement typiques. Dans des situations atypiques ou en cas de besoin de protection accru – sont citées les données classifiées par l’État et les catégories particulières de données à caractère personnel au sens du RGPD –, des mesures de protection supplémentaires peuvent être nécessaires.

Du besoin de protection au niveau de sécurité

Chaque exigence porte l’un des deux niveaux de sécurité : « normal-SdT », le niveau de sécurité standard, ou « renforcé ». Les exigences sélectionnées dépendent du besoin de protection du processus métier considéré. Selon le standard, les exigences du niveau « renforcé » comportent le verbe modal PEUT et sont à satisfaire de manière optionnelle ; elles peuvent être mobilisées dans l’analyse des risques pour identifier des mesures supplémentaires, par exemple en cas de risque accru. Dans le catalogue du 22/10/2026, c’est le cas de 224 des 227 exigences de niveau renforcé ; trois portent DEVRAIT. Sous la forme d’une exigence DEVRAIT, le catalogue d’application prévoit de vérifier la classification initiale des niveaux de sécurité lorsque le contexte de l’institution diverge – selon le texte explicatif, en particulier en cas de besoin de protection élevé ; elle peut aussi être modifiée pour des actifs individuels. Le texte explicatif du catalogue cite expressément un déclassement de « renforcé » à « normal-SdT » comme motif d’une analyse des risques.

Périmètre et réseau d’information

Le périmètre fixe l’étendue formelle et organisationnelle du SMSI ; le réseau d’information en est la représentation concrète et technique. Un périmètre peut comprendre un ou plusieurs réseaux d’information ; un réseau d’information peut couvrir l’ensemble du périmètre ou certaines parties, découpées selon la structure organisationnelle, des processus métier communs ou des applications. Les actifs sont toutes les valeurs matérielles et immatérielles nécessaires aux processus métier considérés, par exemple des applications, des systèmes informatiques ou des locaux. Une délimitation claire garantit que toutes les informations, tous les actifs et toutes les dépendances pertinents sont recensés ; les actifs inventoriés constituent le prérequis du jeu d’exigences. Le catalogue d’application traduit cela en deux exigences DOIT : définir le réseau d’information, délimité de manière traçable, sur la base du périmètre, et définir ses interfaces avec les processus externes.

Les actifs pertinents peuvent notamment être des processus métier, des informations, des systèmes et des applications, des composants de réseau et de communication, des actifs d’infrastructure et physiques, ainsi que des actifs liés au personnel et à l’organisation. Pour la documentation, l’institution peut s’appuyer sur les registres des actifs existants et sur les données système collectées sous forme numérique ; les interfaces avec les processus et systèmes externes ou avec d’autres réseaux d’information doivent être documentées sans ambiguïté sur les plans organisationnel, technique et infrastructurel. L’ordre de l’inventaire suit la priorisation issue de la détermination du besoin de protection, et les actifs présentant des caractéristiques et une finalité d’utilisation similaires peuvent être regroupés. Le catalogue d’application impose, en tant qu’exigence DOIT, de définir tous les actifs pertinents des processus métier considérés ; selon le texte explicatif, les actifs du processus métier le plus important suffisent lors du premier cycle PDCA. Pour chaque actif, il prévoit une désignation univoque, une brève description indiquant sa finalité, l’affectation aux processus métier et un rôle responsable ou un propriétaire de l’actif.

Dépendances : profondeur selon le besoin de protection

Selon le standard, la représentation peut s’appuyer sur des sources existantes telles que les CMDB, les registres des actifs, les manuels d’exploitation, les plans de réseau ou les cartographies des services, afin d’éviter le travail en double. Ce qui compte, c’est que les principales dépendances soient documentées de manière traçable, car l’analyse des risques en cas de besoin de protection élevé part du niveau du processus métier et suit le chemin de ressources. Pour les processus dont le besoin de protection est normal, le standard exige au minimum deux types de relations. Les actifs sont ensuite affectés aux catégories d’objets cibles.

Pratiques : un classement thématique en trois catégories

Selon le standard, les pratiques servent à une meilleure compréhension : elles regroupent les exigences par thème et sont réparties entre les catégories Méthodologie, Organisation et Technique. Avec leurs 99 exigences, les six pratiques méthodologiques forment le cadre de management et ne portent aucune catégorie d’objets cibles. Les huit pratiques organisationnelles et les six pratiques techniques contiennent 901 exigences ; chacune d’elles commence par le sous-groupe « Fondamentaux », puis se subdivise par thème – soit 103 sous-groupes au total, contre 140 pour l’ensemble du catalogue. Les définitions que le BSI donne de chaque pratique précisent les délimitations, par exemple que la pratique Suivi et évaluation correspond à la phase Check du cycle PDCA, que la pratique Amélioration clôt le cycle tout en en ouvrant un nouveau et que la pratique Détection laisse à la pratique Traitement des incidents de sécurité la prise en charge des événements détectés.

Un schéma facilite la lecture : les 14 pratiques techniques et organisationnelles ne comptent que 69 exigences DOIT, et toutes figurent dans le sous-groupe « Fondamentaux ». Dans chaque pratique, elles forment le même cadre procédural – ancrer les procédures et les règles, les documenter, attribuer les tâches qui y sont liées, informer les responsables et réexaminer les règles régulièrement et lorsque des événements le justifient ; dans la pratique Sensibilisation, une exigence DEVRAIT relative à la mesure de l’efficacité remplace le réexamen. Les 832 autres exigences de ces pratiques sont des exigences DEVRAIT ou PEUT, et les exigences PEUT relèvent sans exception du niveau de sécurité « renforcé ». De notre point de vue, DEVRAIT constitue donc le véritable étalon de GS++ : tout écart doit être soigneusement pesé et justifié de manière solide, et une non-satisfaction durable déclenche une analyse des risques.

Catégories d’objets cibles : nœuds parents et nœuds enfants

Les nœuds de niveau hiérarchique supérieur sont appelés nœuds parents, ceux qui leur sont subordonnés nœuds enfants. Les exigences situées au niveau le plus élevé d’une branche ont le plus souvent un caractère conceptuel, par exemple « ancrer les procédures » ; chaque catégorie est définie dans l’annexe du standard, la plupart étant en outre illustrées par des exemples, et chaque actif identifié peut être affecté à au moins une catégorie. L’héritage est déterminant : un actif doit également être affecté à toutes les catégories de niveau supérieur, et ce sont seulement la catégorie directe et les catégories de niveau supérieur prises ensemble qui déterminent ses exigences. Un service SaaS, enregistré comme service cloud, hérite ainsi des exigences des catégories Externalisation, Prestations de services et Achats – 9 directes plus 29, 31 et 39, soit 108 au total. Le catalogue d’application fait de l’affectation, de l’héritage et de la consolidation des exigences DOIT : l’affectation suit une logique fonctionnelle, c’est-à-dire la manière dont l’actif agit dans le processus métier, les exigences qui s’appliquent plusieurs fois ne sont consignées qu’une seule fois, et les actifs difficiles à affecter sont analysés dans le cadre de l’analyse des risques.

Trois types d’exigences

Le standard présente le chemin menant au jeu d’exigences sous la forme d’une chaîne : processus métier avec un besoin de protection normal ou élevé, actifs, catégories d’objets cibles, exigences, jeu d’exigences – et, en cas de besoin de protection élevé, analyse des risques. Il en découle pour chaque actif des prescriptions relatives à l’organisation, à la technique, au personnel et à l’infrastructure ; les exigences qui valent pour plusieurs actifs de la même catégorie ne figurent qu’une seule fois dans le jeu d’exigences. Pour les exigences sans catégorie d’objets cibles, les textes divergent : le standard exige de les intégrer obligatoirement, tandis que le texte explicatif du catalogue prévoit pour chaque exigence une décision sur sa pertinence et la suppression motivée des exigences non pertinentes. Recommandation VamiSec : suivre le standard, les intégrer toutes et, lors de la réalisation, attribuer le statut « non applicable », avec une justification documentée, aux exigences dont le composant n’existe pas dans le réseau d’information – la démarche reste ainsi traçable au regard des deux textes.

Modèles de référence : prévus, mais pas encore publiés

Selon le standard, un modèle de référence est un catalogue d’exigences préétabli qui, contrairement au catalogue d’application, est adapté à des scénarios d’utilisation déterminés, opère une présélection et fixe les paramètres. Les modèles de référence peuvent être affectés à des groupes d’actifs ou à des actifs individuels et combinés entre eux ; la sélection, version comprise, l’affectation et l’adaptation doivent être documentées de manière traçable, les lacunes doivent être comblées par d’autres modèles de référence ou exigences, et la sélection doit être réexaminée en cas de modification du réseau d’information ou des modèles de référence disponibles. Des modèles de référence obligatoires peuvent exister pour certaines institutions ; le standard ne précise pas lesquels. À la date du 29/10/2026, aucun artefact de la bibliothèque de l’état de l’art n’est désigné comme modèle de référence. Sont notamment publiés le profil « Stand der Technik WLAN » (état de l’art WLAN), avec 48 exigences sélectionnées et trois paramètres fixés tels que « WPA3 », ainsi qu’un profil consacré à la sécurité de la chaîne d’approvisionnement, avec 146 exigences sans paramètres fixés ; le BSI ne précise pas s’ils sont considérés comme des modèles de référence. Le BSI a soumis un concept de modèles de référence, sous forme de version alpha, à un groupe de travail de la communauté pour commentaires ; ce concept n’est pas accessible au public.

Exigences propres et choix de paramétrage

Si un actif ne peut pas être représenté de manière suffisante par les exigences existantes, ou si des obligations découlent de la gestion de la conformité ou de l’analyse des parties prenantes, le standard recommande d’élaborer des exigences complémentaires ; le catalogue d’application en fait, dans les deux cas, une exigence DOIT. Pour les actifs dépourvus d’exigences adaptées, le texte explicatif prévoit de documenter les actifs concernés, de justifier pourquoi les exigences GS++ ne suffisent pas, de formuler le cas échéant de nouvelles exigences rapportées aux objectifs de protection, de les intégrer de manière permanente dans le jeu d’exigences et de les transmettre au BSI. Le standard ne précise pas le « format prévu par GS++ » pour les exigences propres ; de notre point de vue, le modèle de phrase sur lequel reposent toutes les exigences du catalogue s’y prête : pratique, le cas échéant catégorie d’objets cibles, verbe modal, résultat, éventuellement une spécification du résultat et un verbe d’action – par exemple « Informations et actifs pour les systèmes informatiques DEVRAIT documenter le besoin de maintenance des composants système et l’infrastructure nécessaire à l’exploitation ». Le catalogue utilise 27 verbes d’action, les plus fréquents étant ancrer, documenter et activer, et indique pour 961 exigences un type de documentation recommandé.

L’institution fait ses choix de paramétrage au moyen de paramètres : des éléments variables tels que « régulièrement », qui indiquent aux auditeurs et aux utilisateurs les marges de manœuvre et peuvent servir au contrôle automatisé. Ils sont précisés lors de l’élaboration du jeu d’exigences ou après celle-ci ; le catalogue d’application impose, en tant qu’exigence DOIT, d’attribuer des valeurs concrètes, selon le texte explicatif par exemple « tous les jours », « toutes les semaines » ou « tous les mois » au lieu de « régulièrement », ou encore les personnes et les rôles auxquels chaque pratique technique et organisationnelle attribue les tâches dans ses « Fondamentaux ». Le catalogue contient 223 paramètres répartis sur 210 exigences. Le profil du catalogue d’application n’en fixe que deux : le standard applicable au SMSI, « BSI Grundschutz++ », et celui applicable à un système de management de la continuité d’activité (SMCA), « BSI-Standard 200-4 » ; toutes les autres valeurs sont déterminées par l’institution, pour autant qu’aucun modèle de référence ne les impose.

État de mise en œuvre : trois valeurs, vérification exhaustive

Pour chaque exigence du jeu d’exigences, l’état de mise en œuvre actuel doit être vérifié de manière exhaustive. Le standard distingue trois valeurs : « satisfaite », « non satisfaite » et « non applicable ». La troisième valeur est soumise à des conditions : une exigence peut être considérée comme « non applicable » lorsqu’elle ne peut pas être satisfaite sur le plan fonctionnel ou que le composant sous-jacent n’existe pas dans le réseau d’information ; la justification doit être documentée. La détermination devrait suivre une procédure structurée, pouvant aller des entretiens et des revues documentaires jusqu’aux contrôles de configuration automatisés et aux scans techniques ; les exigences du niveau de sécurité « normal-SdT » doivent être vérifiées en premier. Dans le catalogue d’application, la vérification de l’état de mise en œuvre est une exigence DOIT, exhaustive et régulière, l’institution fixant l’intervalle sous forme de paramètre. Le texte explicatif de ce catalogue ne retient que « mise en œuvre » et « non mise en œuvre » et ajoute une règle que le standard ne mentionne pas : une exigence n’est considérée comme mise en œuvre que lorsque toutes les exigences en relation de dépendance avec elle sont également mises en œuvre.

Plan de mise en œuvre : chaque mesure rattachée à son exigence

Le jeu d’exigences donne lieu à un plan de mise en œuvre structuré. Celui-ci définit pour chaque exigence des mesures concrètes et les priorise ; à titre d’exemple, le standard cite comme critères l’effort requis par l’exigence sous-jacente, les synergies entre mesures, le niveau des risques, l’importance stratégique et les quick wins à forte efficacité. Il recommande en principe de mettre d’abord en œuvre les exigences des nœuds parents. Pour chaque exigence, les mesures qui lui sont affectées doivent être clairement identifiables ; si une mesure couvre plusieurs exigences, toutes les affectations doivent être indiquées, de même que les dépendances. Pour chaque mesure doivent être consignées au minimum l’exigence correspondante, la date de la mise en œuvre ou de la vérification et la personne qui documente ou qui vérifie. Les responsabilités et des délais réalistes devraient être documentés sous une forme appropriée, par exemple dans un système de gestion de projet ou de tickets ; la direction de l’institution valide la démarche, car c’est elle qui doit mettre les ressources à disposition. L’avancement doit être suivi en continu, et un éventuel conflit d’intérêts entre la mise en œuvre et le suivi de l’avancement doit être évité par une répartition appropriée des rôles.

Preuves, contrôle automatisé et historique

Les preuves utilisées pour l’évaluation doivent être affectées sans ambiguïté à la mesure concernée, afin que la mise en œuvre puisse être retracée. Pour les contrôles automatisés, l’outil utilisé, l’horodatage du contrôle et le résultat doivent figurer dans la documentation ; si l’outil génère un rapport de contrôle, celui-ci est affecté à la mesure et à l’exigence. Si l’affectation, l’état d’avancement de la mise en œuvre ou le résultat du contrôle change, la documentation doit être mise à jour, et, pour la traçabilité, le standard recommande un historique comportant au minimum l’horodatage, la personne responsable et l’outil utilisé. Le texte explicatif relatif à la validation de la planification de la mise en œuvre énumère les contenus que comporte typiquement un plan de mise en œuvre : depuis la description de l’exigence, l’objet cible, l’entité responsable, les délais et les priorités, en passant par les risques avec leur justification, les ressources et les dépendances, jusqu’à la date de validation et la signature du propriétaire du risque. Pour les résultats de contrôle lisibles par machine, la bibliothèque de l’état de l’art prévoit une couche Assessment dédiée ; aucun artefact n’y a été publié jusqu’à présent.

Quand l’institution doit mener sa propre analyse des risques

Le catalogue d’application repose sur une analyse des risques générale du BSI, qui part d’une situation de menace typique supposée ; c’est pourquoi les utilisatrices et utilisateurs n’ont pas à mener leur propre analyse des risques en cas de besoin de protection normal. Une analyse des risques explicite est requise lorsqu’un processus métier présente un besoin de protection élevé pour au moins un objectif de protection, lorsqu’un actif pertinent pour le réseau d’information n’est pas suffisamment couvert par les catégories d’objets cibles et leurs exigences, ou lorsqu’une exigence DEVRAIT applicable ne sera pas satisfaite dans un avenir prévisible ou ne le sera définitivement pas. Dans le catalogue d’application, ces déclencheurs sont formulés sous forme d’exigences DOIT : une analyse des risques dédiée pour les processus métier ou les informations présentant un besoin de protection élevé, et une analyse des risques chaque fois que la méthodologie l’exige. La note explicative correspondante cite en outre l’abaissement du niveau de sécurité de « renforcé » à « normal-SdT », un motif que le standard lui-même ne mentionne pas. L’institution choisit elle-même la procédure d’identification, d’évaluation et de traitement, par exemple sur la base de l’ISO/IEC 27005, de l’ISO 31000 ou du standard BSI 200-3, pour autant que les critères minimaux de l’analyse des risques soient respectés. Ils visent à rendre la méthode comparable et vérifiable, entre autres dans le cadre d’une certification.

Rôles et approbations : qui autorise quoi

Menaces élémentaires : trait d’union entre la dérivation du BSI et votre propre analyse

Les 47 menaces élémentaires G 0.1 à G 0.47, de l’incendie aux effets secondaires préjudiciables des attaques informatiques, décrivent à un niveau abstrait des événements, des circonstances ou des actes fondamentaux. Elles sont neutres vis-à-vis des produits et des technologies, compatibles avec les standards internationaux, associées aux valeurs fondamentales que sont la confidentialité, l’intégrité et la disponibilité, et visent des dangers réalistes ; une mesure de sécurité absente ou insuffisamment mise en œuvre ne constitue en principe pas une menace élémentaire. Dans GS++, elles remplissent deux fonctions : elles constituent l’une des bases à partir desquelles le BSI a dérivé les exigences du catalogue, et elles servent aux utilisateurs de point de départ pour leurs propres analyses des risques. Ce lien est visible dans le catalogue. Les 901 exigences du noyau portent des identifiants G0, les 47 menaces y figurent toutes, et les exigences des pratiques méthodologiques n’en ont aucun. Pour les exigences DEVRAIT durablement non satisfaites, les menaces associées doivent être prises en compte ; en pratique, l’analyse d’une telle lacune commence donc par les identifiants G0 de l’exigence concernée.

Évaluation des performances : obligatoire, mais encore sans prescriptions uniformes

Une évaluation des performances est nécessaire pour vérifier l’efficacité du SMSI et de ses objectifs. Comme l’élaboration de prescriptions uniformes en la matière reste à réaliser dans GS++, les institutions sont libres dans leur conception ; les résultats devraient être présentés à la direction de l’institution de manière traçable. Libre ne veut pas dire facultatif : le catalogue d’application exige, sous forme d’exigences DOIT, des procédures et des règles de mesure et d’évaluation de la performance du SMSI, le réexamen et la mise à jour réguliers du plan de mise en œuvre ainsi qu’une vérification régulière de l’actualité des exigences. Selon son calendrier des jalons, le BSI entend combler cette lacune méthodologique en 2027 : au 26/02/2027, le concept de mesure de la performance doit être intégré à la méthodologie et pouvoir être appliqué ; au 31/03/2027, chaque exigence des pratiques méthodologiques doit disposer d’indicateurs de performance.

Audit, revue de direction et monitoring

Selon le standard, l’audit interne sert à l’autocontrôle : il ne vise pas à mettre en évidence des non-conformités, mais des potentiels d’amélioration. Lors de la planification, les objectifs du programme d’audit doivent être fixés en premier ; ils devraient notamment tenir compte des exigences de sécurité de l’information, de la performance de la détection et du traitement des incidents de sécurité, des risques identifiés, des processus, du degré de maturité du SMSI et des résultats d’audits antérieurs. Les risques du programme d’audit lui-même doivent être déterminés et évalués, y compris les mesures relatives à la confidentialité dans le cadre de l’audit. L’étendue et la fréquence devraient être déterminées en fonction du nombre de systèmes d’information, de sites et de personnes concernées, de la complexité du SMSI et de l’importance des risques ; les audits peuvent être réalisés sur site, à distance ou de manière combinée, et le choix de l’équipe d’audit devrait garantir l’objectivité et l’impartialité. Lors de la revue de direction, la direction de l’institution examine, sur la base du rapport à la direction, si le SMSI est pertinent, adéquat et efficace, au regard des résultats d’audit, de l’évaluation des performances, des incidents de sécurité, de l’état du traitement des risques, des changements au sein de l’institution ou dans la situation de la menace et de l’état des décisions antérieures. Pour le monitoring, trois procédures doivent être ancrées ; s’y ajoute la validation régulière des exigences :

• Détection des incidents de sécurité avec identification et signalement précoces, allant, selon la taille et la complexité de l’institution, de processus manuels à des systèmes de détection automatisés.
• Gestion des vulnérabilités : les identifier, les évaluer, les traiter et en assurer le suivi de manière systématique, avec retour d’information vers l’analyse des risques.
• Recensement des menaces émergentes et réaction à celles-ci, également avec retour d’information vers l’analyse des risques.
• Validation des exigences en cas de changements dans le réseau d’information, dans la bibliothèque de l’état de l’art, dans les modèles de référence utilisés ou dans la méthodologie GS++, en concertation avec les unités organisationnelles compétentes et, le cas échéant, avec adaptation du jeu d’exigences.

Amélioration : du constat au plan de correction et d’amélioration

Lorsque des exigences ne sont pas satisfaites dans la mesure prévue, il y a écart. Les non-conformités sont recensées de manière systématique et leurs causes sont analysées, non seulement les causes immédiates, mais aussi les causes sous-jacentes. Cela comprend l’estimation de la probabilité et des conséquences d’une éventuelle récurrence, l’examen de cas similaires dans d’autres domaines et la question de savoir si le SMSI présente une faiblesse systémique. Les potentiels d’amélioration découlent entre autres de la situation de la menace, de l’efficacité du plan de mise en œuvre, des résultats d’audit, des incidents de sécurité et des propositions du personnel ; ils devraient être évalués en fonction de la réduction des risques, des ressources requises, de l’importance stratégique, des synergies et de la durabilité. Les propositions de correction et d’amélioration doivent être intégrées dans un plan de correction et d’amélioration, priorisé en fonction des ressources, des quick wins et du plus grand potentiel d’amélioration, puis repris dans le plan de mise en œuvre. L’évaluation vérifie ensuite, au moyen de critères mesurables, de tests ou d’audits, si les mesures sont efficaces. Les vulnérabilités détectées et l’évolution de la situation de la menace déclenchent un nouveau cycle d’analyse des risques, et la boucle se referme sur le plan de mise en œuvre de la réalisation.

Verbes modaux, niveaux de sécurité et rattachement aux catégories d’objets cibles

Niveaux d’effort : la charge de travail attendue par le BSI

Ce qui a changé depuis avril 2026

Les changements concernent surtout les pratiques méthodologiques : des sous-groupes y ont été supprimés ou fusionnés, dix des douze exigences supprimées proviennent de la méthodologie, et cinq exigences méthodologiques sont passées de DEVRAIT à DOIT. Au total, onze exigences ont changé de verbe modal ; outre ces cinq, quatre sont passées de PEUT à DEVRAIT, une est descendue de DEVRAIT à PEUT et une autre de DOIT à DEVRAIT. Les nouvelles exigences relèvent majoritairement de la pratique « Habilitations ». En pratique, l’enseignement qui se dégage compte davantage que chaque chiffre pris isolément : les identifiants dépendent de la position et peuvent changer d’un état du catalogue à l’autre, alors que l’UUID est stable. Une simple comparaison des identifiants ferait apparaître nettement plus d’exigences nouvelles et supprimées qu’il n’y en a réellement. Si vous fondez l’état de mise en œuvre, les correspondances ou les déclarations d’applicabilité sur les identifiants d’exigence, vous devriez donc comparer chaque nouvel état du catalogue au moyen des UUID ; selon nous, il s’agit d’une fonction de base de tout outil GS++. Autres chiffres clés en un coup d’œil :

• Pratiques les plus étendues : KONF avec 157, BES avec 109, BER avec 92, SENS avec 87, DET avec 82 et GEB avec 75 exigences ; les six pratiques méthodologiques comptent ensemble 99 exigences, dont 80 DOIT et 19 DEVRAIT.
• Types de documentation les plus fréquents : historique de configuration avec 183, concept d’exploitation informatique avec 116, critères d’achat avec 70, concept de détection avec 61, instruction de travail et plan de formation avec 60 mentions chacun.
• Le libellé de paramètre le plus fréquent est « régulièrement », avec 68 occurrences ; le profil du catalogue d’application ne fixe que deux des 223 paramètres, l’institution précisant tous les autres.
• Menaces élémentaires les plus fréquentes : G 0.18 avec 385, G 0.23 avec 142, G 0.30 avec 130, G 0.36 avec 110, G 0.19 avec 98 et G 0.39 avec 95 associations.
• L’héritage le long des catégories d’objets cibles accroît le volume par actif : 9 exigences sont directement associées à un actif de la catégorie « Services cloud » ; avec les catégories parentes « Externalisation », « Prestations de services » et « Achats », elles sont 108.
• Gabarit de phrase : 27 verbes d’action différents, les plus fréquents étant « ancrer » avec 137, « documenter » avec 100 et « activer » avec 78 exigences.

La bibliothèque de l’état de l’art

Selon le BSI, la bibliothèque de l’état de l’art est la plateforme technique sur laquelle l’ensemble des exigences et des mesures est mis à disposition de manière centralisée ; elle remplace le Compendium IT-Grundschutz, et le catalogue d’application Grundschutz++ en fait partie. D’après le BSI, le dépôt BSI-Bund/Stand-der-Technik-Bibliothek est public depuis le 29/09/2025 et placé sous licence CC BY-SA 4.0. Depuis le passage à une structure en couches le 27/07/2026, le BSI publie les mises à jour sous forme de « rolling publication » automatisée à intervalles variables ; à la date de rédaction du 29/10/2026, la dernière remontait au 23/10/2026. OSCAL, l’Open Security Controls Assessment Language du NIST américain, sert de format ; le BSI justifie ce choix par le fait que cela lui évite de développer sa propre solution nationale et accroît la compatibilité avec les standards de sécurité internationaux. Formellement, la page du BSI « Stand der Technik » (état de l’art) décrit toujours la bibliothèque comme étant en phase pilote.

Ce que contient chaque exigence

• Identifiant et UUID : selon le manuel du BSI destiné aux auteurs de la bibliothèque de l’état de l’art, l’identifiant dépend de la position et peut changer lors de restructurations, tandis que l’UUID reste lié au sens de l’exigence. Entre avril et octobre 2026, 157 exigences ont reçu un nouvel identifiant.
• Gabarit de phrase composé de la pratique, le cas échéant de la catégorie d’objets cibles, du verbe modal, du résultat et du verbe d’action. Selon ce même manuel des auteurs, les prescriptions doivent être formulées de sorte qu’un tiers indépendant puisse vérifier par oui ou par non si elles sont satisfaites.
• Métadonnées : niveau de sécurité, niveau d’effort et, lorsqu’ils sont attribués, catégories d’objets cibles, type de documentation et mots-clés ; les exigences du noyau comportent en outre des valeurs de pertinence de 0 à 2 pour la confidentialité, l’intégrité, la disponibilité et l’authenticité ainsi que les identifiants G0 des menaces élémentaires.
• Paramètres sous forme de texte à trous pour les choix de paramétrage, par exemple « régulièrement ». Les profils peuvent fixer des valeurs ou les restreindre ; le profil du catalogue d’application n’en fixe que deux, dont « BSI Grundschutz++ » comme standard pour le SMSI.
• Liens vers des exigences connexes et des exigences préalables, ainsi que notes explicatives qui précisent une exigence et donnent des exemples de mise en œuvre.

Correspondances : des passerelles vers l’ISO/IEC 27001 et le Compendium IT-Grundschutz

Pour la lecture, le README du dépôt du BSI recommande le Stand-der-Technik-Viewer (visionneuse de l’état de l’art), une application web issue de l’organisation communautaire bsi-community. Il affiche côté client les catalogues, les définitions de composants et les correspondances, filtre selon des caractéristiques telles que le niveau de sécurité, l’effort, la catégorie d’objets cibles, le verbe modal ou la menace et, lorsqu’une catégorie d’objets cibles est sélectionnée, ajoute automatiquement les catégories parentes. Selon le BSI, de nombreux éditeurs d’outils IT-Grundschutz travaillent à l’intégration des données OSCAL. Les limites devraient être claires : selon le BSI, les catalogues OSCAL n’automatisent aucune mise en œuvre et ne remplacent pas l’examen technique sur site, la couche Assessment est encore vide, et aucun artefact désigné comme modèle de référence n’a été publié à ce jour. Les profils pour la sécurité de la chaîne d’approvisionnement, avec 146 exigences, et pour le WLAN, avec 48, sont des sélections issues du noyau ; le BSI ne les qualifie pas de modèles de référence.

Certification de système : ce qui est établi et ce qui reste ouvert

Ce qui est établi : à partir du 01/01/2027, les demandes de certification ISO 27001 sur la base de GS++ peuvent être déposées. Dans son communiqué sur la publication du standard, le BSI décrit un SMSI mis en place selon Grundschutz++ comme certifiable à partir de 2027 et compatible avec l’ISO/IEC 27001. La procédure de contrôle reste ouverte : aucun schéma d’audit pour GS++ n’a été publié. Selon le programme du BSI pour l’it-sa, une conférence de l’organisme de certification du BSI intitulée « Ausblick auf die Zertifizierung nach Grundschutz++ » (Perspectives de la certification selon Grundschutz++) était annoncée pour le 28/10/2026 ; elle devait présenter les réflexions actuelles sur le schéma d’audit, y compris les défis liés aux objets et aux critères de contrôle. Les documents en vigueur pour la certification ISO 27001 sur la base de l’IT-Grundschutz, à savoir la base de contrôle 4.8, le schéma de certification 2.2 et le schéma d’audit 2.5 du 01/02/2026, se réfèrent à l’ISO/IEC 27001:2022, au standard BSI 200-2 et au Compendium IT-Grundschutz édition 2023. Le standard lui-même contient des indications sur la future pratique de contrôle : si les exigences DEVRAIT durablement non satisfaites s’accumulent, un écart important pourrait être constaté dans le cadre d’une certification, et les critères minimaux visent à rendre la méthode d’analyse des risques comparable et vérifiable, entre autres en vue d’une certification.

Formation et certification de personnes : praticien GS++, conseiller GS++, responsable d’équipe d’audit GS++

Le BSI réorganise également la qualification des personnes. Des concepts de formation destinés à former des praticiens GS++ et des conseillers GS++ doivent paraître pour le 30/11/2026. À partir du 01/01/2027, les demandes de certification en tant que conseiller GS++ et en tant que responsable d’équipe d’audit GS++ peuvent être déposées ; au premier trimestre 2027 démarre, pour les conseillers IT-Grundschutz et responsables d’équipe d’audit déjà certifiés, une formation complémentaire spécifique menant à la certification de conseiller GS++ ou de responsable d’équipe d’audit GS++. Le calendrier des jalons ne précise ni les contenus, ni le volume, ni les conditions d’accès. Pour les appels d’offres et les offres, il en découle selon nous une règle de vérification simple : avant le 01/01/2027, personne ne peut être certifié conseiller GS++ ou responsable d’équipe d’audit GS++ ; les qualifications BSI existantes se rapportent à l’IT-Grundschutz.

Qui doit tenir compte de quoi

État au 29/10/2026. Le calendrier des jalons est actualisé par le BSI ; font foi les référentiels de certification publiés, dans leur version en vigueur. VamiSec n’est pas un organisme de certification, et la certification de personnes GS++ ne débute qu’en 2027.

Chemin A : depuis l’IT-Grundschutz

Chemin B : depuis l’ISO/IEC 27001

Plan de démarrage à 90 jours

1. 1
   Jours 1–15 · BSI 300-1 chap. 2.3 et 2.10 · GC.1.2, GC.6.1, GC.8.1Clarifier le mandat, le périmètre et l’objectif

   La direction de l’institution confirme le projet, fixe le périmètre, débloque les ressources et décide si une certification ISO 27001 sur la base de GS++ est visée en 2027. Une équipe restreinte composée de l’ISB, des responsables de processus et de l’informatique est désignée.

2. 2
   Jours 16–30 · chap. 2.5 et 2.6 · GC.7.1.1, GC.7.1.2Processus métier et besoin de protection

   Documenter les processus métier du périmètre et, en l’absence de cartographie des processus, utiliser l’analyse simplifiée des processus métier de l’annexe 2. Sélectionner le processus le plus important de la catégorie de besoin de protection la plus élevée et faire valider par la direction le besoin de protection normal ou élevé pour chaque objectif de protection.

3. 3
   Jours 31–50 · chap. 3 · STM.2.1.2 à STM.2.1.5, STM.5.1Actifs, catégories d’objets cibles et jeu d’exigences

   Selon le texte explicatif du catalogue, les actifs du processus métier le plus important suffisent pour le premier passage. Affecter les actifs aux catégories d’objets cibles, y compris aux catégories de niveau supérieur, intégrer les exigences méthodologiques et les exigences sans catégorie d’objets cibles, éliminer les doublons et fixer les valeurs des paramètres.

4. 4
   Jours 51–70 · chap. 4.1 · UMS.1.1Relever l’état de mise en œuvre

   Commencer par les exigences de niveau normal-SdT et documenter pour chaque exigence, avec justification, l’état « satisfaite », « non satisfaite » ou « non applicable ». Les résultats existants du contrôle IT-Grundschutz ou de la déclaration d’applicabilité servent de valeur de départ, non de résultat.

5. 5
   Jours 71–85 · chap. 2.11 et 4.2 · annexe 3Mettre en place l’analyse des risques

   Faire autoriser par la direction de l’institution l’appétence au risque, les critères d’acceptation du risque, la procédure et les rôles ; lancer des analyses des risques pour les processus ayant un besoin de protection élevé, les actifs insuffisamment couverts et les exigences DEVRAIT durablement non satisfaites.

6. 6
   Jours 86–90 · chap. 4.3 à 4.5 et 5.3 · UMS.2.1, RISK.1.10, PERF.4.1Plan de mise en œuvre et premier rapport à la direction

   Prioriser les mesures, nœuds parents en premier, désigner les responsables et fixer les échéances, faire autoriser la planification de la mise en œuvre par les propriétaires du risque et présenter à la direction, dans le rapport à la direction, l’état d’avancement, les risques résiduels et le prochain processus métier.

Points ouverts : ce que le BSI doit encore fournir