L’ENS distingue deux obligations concernant vos prestataires TIC qui ne sont pas identiques : l’article 2.3 du décret royal 311/2022 étend les précautions de sécurité à la chaîne d’approvisionnement « dans la mesure nécessaire » selon l’analyse de risques, dès n’importe quelle catégorie ; et la mesure op.ext.3 de l’annexe II, qui s’appelle littéralement « Protection de la chaîne d’approvisionnement », n’est obligatoire qu’en catégorie HAUTE. Confondre les deux mène à exiger trop, ou pas assez.
L’ENS exige deux choses distinctes concernant vos prestataires technologiques, et les confondre mène à des conclusions fausses dans les deux sens. D’une part, l’article 2.3 du décret royal 311/2022 impose d’étendre les précautions de sécurité à la chaîne d’approvisionnement « dans la mesure nécessaire et conformément aux résultats de l’analyse de risques correspondante », dès n’importe quelle catégorie. D’autre part, la mesure de l’annexe II qui s’appelle littéralement « Protection de la chaîne d’approvisionnement » (op.ext.3) n’est obligatoire qu’en catégorie HAUTE. Traduire ces obligations légales en clauses contractuelles fait partie de notre service de mise en œuvre technique de l’ENS.
Ce que dit l’ENS sur la chaîne d’approvisionnement de vos contractants (art. 2.3)
L’article 2.3 du décret royal 311/2022 exige que les cahiers des charges des contrats conclus par les entités soumises à l’ENS prévoient les exigences nécessaires pour garantir la conformité des systèmes sur lesquels reposent les services contractés, et ajoute :
« Cette précaution s’étendra également à la chaîne d’approvisionnement desdits contractants, dans la mesure nécessaire et conformément aux résultats de l’analyse de risques correspondante. »
— Décret royal 311/2022, art. 2.3 (BOE-A-2022-7191)
La clé est « dans la mesure nécessaire » : l’obligation est proportionnelle au risque, pas automatique selon la catégorie. L’analyse de risques qui détermine cela commence par bien calculer la catégorie de votre système (disponible en espagnol), bien que, comme le montre la section suivante, l’article 2.3 puisse exiger des précautions contractuelles envers les prestataires avant même que la mesure formelle de l’annexe II ne soit active.
La mesure spécifique de l’annexe II, op.ext.3 : pourquoi elle n’est obligatoire qu’en catégorie HAUTE
op.ext.3 fait partie de la même annexe II que nous avons déjà détaillée ici. Vérifié directement dans le tableau officiel : op.ext.3 est « non applicable » à la fois en basique et en moyenne, et ne devient une exigence formelle qu’en catégorie haute ; le reste de la famille op.ext (contractualisation, gestion quotidienne et interconnexion) s’active déjà en moyenne, comme nous le détaillons dans ce qu’ajoute la catégorie moyenne par rapport à la basique. Cela ne signifie pas que la chaîne d’approvisionnement « ne compte pas » avant la haute : l’article 2.3 peut exiger des précautions contractuelles plus tôt si l’analyse de risques le justifie, sans que op.ext.3 doive être active en tant que mesure formelle.
Lorsque op.ext.3 est active (catégorie haute), elle comporte trois renforcements avec des clauses très concrètes : R1, un plan de contingence couvrant la dépendance aux prestataires critiques ; R2, la protection des flux de données B2B ; et R3, un registre des composants logiciels, très proche de ce que l’on appelle aujourd’hui internationalement un SBOM (nomenclature logicielle) :
« [...] un registre formel actualisé sera tenu, contenant les détails et les relations de la chaîne d’approvisionnement des différents composants utilisés dans la construction des programmes informatiques [...]. Cette liste sera fournie par le fournisseur de l’application, de la bibliothèque ou du produit fourni. »
— Décret royal 311/2022, annexe II, renforcement op.ext.3.R3 (BOE-A-2022-7191)
Pourquoi ce n’est pas une simple case à cocher : quatre obligations, quatre bases légales différentes
Il est courant de traiter la « sécurité des prestataires » comme s’il s’agissait d’une exigence unique satisfaite par une clause de confidentialité générique. Le décret royal 311/2022 distingue en réalité quatre obligations séparées, chacune avec sa propre base légale : l’extension proportionnelle au risque de l’article 2.3, la certification des produits de l’article 19, la qualification du personnel de l’article 16, et la mesure formelle de continuité de l’annexe II en cas de défaillance d’un prestataire critique (op.ext.3). Respecter l’une ne signifie pas respecter les autres : un prestataire peut avoir un personnel parfaitement qualifié (art. 16) sans pour autant proposer un seul produit avec une certification de sécurité proportionnelle à votre catégorie (art. 19), ou inversement.
Avant la chaîne d’approvisionnement : ce qu’il faut exiger de tout prestataire dès la MOYENNE (op.ext.1 et op.ext.2)
Avant d’en arriver à op.ext.3, deux mesures de la même famille s’appliquent déjà dès la catégorie moyenne à tout prestataire externe, pas seulement aux prestataires critiques : op.ext.1 exige un accord de niveau de service (SLA) formel préalable à l’utilisation de la ressource, et op.ext.2 exige un système de routine de mesure de ce SLA et des procédures de coordination de la maintenance. op.ext.3 ne s’applique qu’en haute ; pour le reste des mesures par catégorie, consultez le détail complet de la catégorie basique et sa suite en moyenne.
Si votre prestataire est un fournisseur d’infrastructure en nuage, ces clauses générales s’ajoutent à ce qu’exige la mesure spécifique op.nub.1 : nous le traitons dans ce guide sur l’ENS dans le nuage. Nous avons déjà expliqué ici le modèle de service de votre prestataire (SaaS, PaaS ou IaaS), et il conditionne exactement quelle clause lui correspond.
Produits et services de sécurité certifiés : ce qu’exige l’article 19 du décret royal 311/2022
L’article 19 exige que les produits et services de sécurité acquis disposent d’une fonctionnalité de sécurité certifiée, de façon proportionnelle à la catégorie du système, et renvoie au CCN la détermination des exigences fonctionnelles et des certifications supplémentaires. C’est la base légale pour comprendre pourquoi n’importe quel produit « de sécurité » ne vaut pas de la même façon pour n’importe quelle catégorie : plus la catégorie est élevée, plus le niveau de certification que l’on peut exiger est strict.
Personnel qualifié du prestataire : ce qu’exige l’article 16 (professionnalisme)
L’article 16 exige un personnel qualifié, dédié et formé tout au long du cycle de vie du système, et impose expressément d’exiger, de manière objective et non discriminatoire, que les organisations qui fournissent des services de sécurité disposent de professionnels qualifiés. C’est une obligation distincte de la certification des produits de l’article 19 : ici, ce qui est certifié, c’est la compétence des personnes qui fournissent le service, pas le produit.
Le point de contact de sécurité obligatoire dans les services externalisés (art. 13.5) et pourquoi il ne vous décharge pas de votre responsabilité
L’article 13.5 impose au prestataire d’un service externalisé de désigner un point de contact de sécurité, mais précise explicitement que cela ne transfère pas la responsabilité : « sans préjudice du fait que la responsabilité ultime incombe à l’entité du secteur public destinataire desdits services ». Exiger une preuve de tests de sécurité du prestataire renvoie à pentesting et red teaming, détaillé dans ce guide : un point de contact sans preuve technique derrière n’est qu’une case cochée, pas une garantie réelle.
Un cas fréquent : le prestataire qui rechigne à signer ces clauses
Dans la pratique, tous les prestataires TIC ne sont pas familiarisés avec ces exigences — surtout les plus petits, ou ceux qui n’ont pas l’habitude de travailler avec le secteur public —, et certains rechignent à signer un SLA formel ou à s’engager à tenir un registre des composants logiciels. Il convient ici de distinguer deux situations : si le prestataire ne peut pas fournir la preuve parce que son service ne le permet pas (par exemple, un composant fermé sans visibilité sur ses dépendances internes), c’est un signal de risque réel qui devrait peser sur la décision de contractualisation. Si le prestataire ne l’a simplement jamais fait parce que personne ne le lui avait demandé auparavant, la négociation se résout généralement en expliquant précisément ce qu’exige la norme et pourquoi l’exigence n’est pas arbitraire de la part de votre organisation, mais une obligation que vous devez vous-même répercuter en aval de la chaîne.
Les trois clauses concrètes d’op.ext.3 à intégrer dans un contrat
Pour les systèmes de catégorie haute, ou pour toute organisation qui souhaite anticiper sur la base de sa propre analyse de risques, les trois clauses d’op.ext.3 se traduisent ainsi dans un contrat : (1) un plan de contingence documenté en cas de défaillance d’un prestataire critique, avec des alternatives identifiées ; (2) une protection spécifique des flux d’échange d’information B2B avec ce prestataire, pas seulement de l’accès général ; et (3) l’obligation contractuelle pour le prestataire de fournir et de tenir à jour un registre des composants logiciels (bibliothèques, dépendances) qui font partie de ce qu’il fournit. Ces clauses coexistent avec ce qu’exige le respect du RGPD lorsque le prestataire traite des données personnelles : ce sont des obligations parallèles, pas substitutives l’une de l’autre.
Liste de contrôle : que demander à un prestataire TIC selon votre catégorie
- Toute catégorie (art. 2.3) : des précautions proportionnelles au risque si l’analyse le justifie, même si la mesure formelle n’est pas encore active.
- Dès la moyenne (op.ext.1, op.ext.2) : un SLA formel écrit et une procédure de mesure et de coordination de la maintenance.
- Dès la moyenne (art. 19, art. 16) : des produits avec une certification de sécurité proportionnelle à la catégorie et un personnel du prestataire qualifié et accrédité.
- Uniquement en haute (op.ext.3) : un plan de contingence en cas de défaillance d’un prestataire critique, la protection des flux B2B et un registre des composants logiciels.
Si le coût de l’audit de vos prestataires constitue un frein, il existe des aides à la cybersécurité pour les PME qui peuvent couvrir une partie de ce travail ; il convient de vérifier l’appel en vigueur avant de le tenir pour acquis dans une proposition à un client.
Questions fréquentes
Dois-je exiger des clauses de chaîne d’approvisionnement si mon système est de catégorie basique ?
La mesure formelle op.ext.3 ne vous y oblige pas en basique : elle n’est obligatoire qu’en haute. Mais l’article 2.3 du décret royal peut exiger des précautions contractuelles proportionnelles au risque dès n’importe quelle catégorie, si votre propre analyse de risques le justifie. Ce sont deux couches distinctes, pas une seule case.
Qu’est-ce que la « liste des composants logiciels » que demande l’ENS, et à quoi ressemble-t-elle ?
C’est le renforcement R3 d’op.ext.3 : un registre actualisé des composants (bibliothèques, dépendances) utilisés dans la construction d’un logiciel, que le prestataire lui-même doit fournir. C’est fonctionnellement équivalent à ce que l’on appelle aujourd’hui internationalement un SBOM (nomenclature logicielle), bien que l’annexe II n’utilise pas ce terme.
L’article 2.3 s’applique-t-il aussi aux prestataires d’entités privées, ou seulement du secteur public ?
L’article 2.3 est rédigé dans le cadre des cahiers des charges des contrats des entités du secteur public. Les entreprises privées agissant comme prestataires de ces entités sont concernées par la relation contractuelle, pas en tant que sujet direct de l’article, mais c’est en pratique le mécanisme par lequel l’exigence se répercute en aval de la chaîne.
Ce contenu a un caractère informatif et pédagogique. Il ne constitue pas un conseil juridique et ne remplace pas l’analyse d’un professionnel qualifié pour votre cas concret.