Checklist de demande de preuves fournisseurs NIS2 (XLSX & PDF gratuits)

Checklist de demande de preuves fournisseurs NIS2 : modèle gratuit

Une checklist de demande de preuves fournisseurs NIS2 est un registre structuré des preuves de sécurité que vous demandez à chaque fournisseur direct et prestataire de services — certifications, synthèses de tests d'intrusion, SLA de notification d'incidents, divulgations de sous-traitants et résultats de tests de continuité d'activité — aligné sur l'article 21(2)(d) et l'article 21(3) de la directive (UE) 2022/2555. Chaque ligne de preuve précise les types de preuves acceptables et une cadence de revue liée au niveau de criticité du fournisseur, de sorte que votre surveillance de la chaîne d'approvisionnement soit démontrable à tout moment où une autorité le demande.

La plupart des équipes utilisent déjà un questionnaire fournisseurs NIS2. Ce que NIS2 teste réellement, c'est votre capacité à produire des preuves : quels fournisseurs sont critiques, quels artefacts vous détenez pour chacun, quand ils ont été rafraîchis pour la dernière fois, et ce qui se passe quand un fournisseur ne répond plus. Ce modèle gratuit — disponible en XLSX, PDF et en fichier Markdown lisible par machine pour les agents IA (fichiers téléchargeables en anglais) — transforme ces questions en registre opérationnel. C'est le compagnon opérationnel de nos guides sur la vendor assurance sous NIS2 et la sécurité de la chaîne d'approvisionnement NIS2, qui expliquent pourquoi une surveillance continue est requise ; cette page vous donne l'artefact qui l'exécute.

À retenir

• L'article 21(2)(d) de NIS2 fait de la sécurité de la chaîne d'approvisionnement une mesure obligatoire de gestion des risques, couvrant les aspects liés à la sécurité des relations avec chaque fournisseur direct et prestataire de services — et non la base fournisseurs prise dans son ensemble.
• L'article 21(3) vous dit quoi regarder : les vulnérabilités propres à chaque fournisseur direct, la qualité globale de ses produits et de ses pratiques de cybersécurité — y compris explicitement ses procédures de développement sécurisé — et les résultats des évaluations coordonnées des risques au titre de l'article 22(1).
• La preuve prime sur l'auto-déclaration. Les orientations de l'ENISA sur la chaîne d'approvisionnement appellent à évaluer la qualité des pratiques de sécurité des fournisseurs, et son guide technique de mise en œuvre de juin 2025 nomme la vérification des fournisseurs, les clauses de sécurité contractuelles et la surveillance continue comme attentes centrales.
• La cadence suit la criticité. La grille à trois niveaux du modèle attribue à chaque catégorie de preuve une fréquence de rafraîchissement par niveau, plus des déclencheurs événementiels — incident, changement de sous-traitant, expiration de certificat — qui priment sur le calendrier.
• Les enjeux sont concrets : les entités essentielles encourent des amendes jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial, les entités importantes jusqu'à 7 millions d'euros ou 1,4 %, et les autorités de supervision peuvent demander des preuves de chaîne d'approvisionnement à tout moment.

Ce que contient le modèle

Le fichier XLSX contient quatre feuilles : un registre des fournisseurs, la checklist de preuves elle-même, une grille de criticité et une feuille d'instructions. Le PDF reproduit la checklist pour l'impression et les réunions de revue ; la variante Markdown porte la structure complète avec des métadonnées YAML, de sorte qu'un agent IA peut mener une demande de preuves de bout en bout.

Le cœur du modèle est la checklist de preuves — en pratique, une checklist des exigences NIS2 de chaîne d'approvisionnement, ligne par ligne. Voici un aperçu des lignes réelles :

Catégorie de preuve	Quoi demander	Types de preuves acceptables	Cadence (Niveau 1 / 2 / 3)	Ancrage NIS2
Certifications & assurance indépendante	Certificat ou attestation en cours de validité couvrant le service acheté	Certificat ISO 27001 avec périmètre + validité ; rapport SOC 2 Type II (+ bridge letter si >12 mois)	Annuelle + alertes d'expiration / Annuelle / Tous les 3 ans	Art. 21(3) — qualité des pratiques de cybersécurité
Tests d'intrusion	Synthèse exécutive du test d'intrusion le plus récent	Synthèse avec périmètre, méthodologie, gravité des constats, état de remédiation — pas le rapport d'exploitation complet	Annuelle / Annuelle / Auto-attestation	Art. 21(2)(e), (f)
Gestion des vulnérabilités & correctifs	SLA de correctifs et indicateurs de délai de correction	Politique de gestion des vulnérabilités ; indicateurs sur les CVE critiques des 6–12 derniers mois	Indicateurs trimestriels / Annuelle / À l'intégration	Art. 21(2)(e)
Développement sécurisé	Pratiques de sécurité du SDLC pour les fournisseurs de logiciels	Politique de développement sécurisé ; preuves SAST/DAST ; SBOM pour les logiciels critiques	Annuelle / Annuelle / n/a	Art. 21(3) — procédures de développement sécurisé
SLA de notification d'incidents	Engagement contractuel à vous notifier les incidents affectant votre service	Clause signée avec fenêtre de notification (en heures), contacts nommés, chaîne d'escalade	Vérification à l'intégration + annuelle / Annuelle / Revue du contrat	Art. 21(2)(b) ; alimente votre calendrier art. 23
Divulgation des sous-traitants	Registre à jour des sous-traitants + engagement de notification des changements	Registre avec entités, localisations, services ; preuve de clause de sécurité répercutée	Trimestrielle ou au changement / Annuelle / À l'intégration	Art. 21(2)(d)
Continuité d'activité & reprise	PCA/PRA couvrant votre service, avec RTO/RPO et preuves de test	Extrait du plan ; rapport de test le plus récent avec date, scénario, actions correctives	Preuve de test annuelle / Confirmation annuelle / Attestation	Art. 21(2)(c)
Contrôle d'accès & chiffrement	Posture IAM et cryptographie pour les systèmes touchant vos données	Politique MFA/PAM ; échantillon de revue des accès ; standards de chiffrement en transit et au repos	Annuelle / Annuelle / Attestation	Art. 21(2)(i), (j)

Chaque ligne du XLSX porte aussi des champs de workflow — date de demande, date de réception, statut, relecteur — de sorte que le registre fait aussi office de piste d'audit.

Comment l'utiliser : niveaux, cadence, escalade

Étape 1 — Classez chaque fournisseur. La grille de criticité note chaque fournisseur direct sur trois dimensions : la dépendance de service (une panne perturberait-elle votre service essentiel ou important ?), l'accès (systèmes de production, données sensibles, connectivité réseau) et la substituabilité. Les fournisseurs de niveau 1 reçoivent le jeu de preuves complet ; le niveau 2 un jeu central ; le niveau 3 une attestation allégée. C'est ainsi que vous honorez les « vulnérabilités propres à chaque fournisseur direct » de l'article 21(3) sans vous noyer dans la paperasse — la proportionnalité est inscrite dans le standard « appropriées et proportionnées » de la directive.

Étape 2 — Faites tourner la cadence de preuves. Chaque ligne de la checklist indique sa fréquence de rafraîchissement par niveau. La cadence calendaire est le plancher, pas le plafond : les déclencheurs événementiels — incident chez un fournisseur, nouveau sous-traitant, certificat en expiration, changement du périmètre de service — priment sur le calendrier et déclenchent une re-demande immédiate limitée aux catégories concernées. Ce schéma piloté par les événements est exactement ce qui distingue la surveillance des fournisseurs de l'évaluation ponctuelle.

Étape 3 — Escaladez face au silence. Le modèle est livré avec un workflow d'escalade en quatre étapes : relance à 10 jours ouvrés, escalade au responsable commercial à 20, mise en demeure invoquant la clause d'audit/de preuves du contrat à 30, et décision de risque documentée — acceptation, mesures compensatoires ou revue de résiliation — à 45. Chaque étape est consignée, car une trace d'escalade est en elle-même la preuve que votre surveillance fonctionne. Les autorités qui supervisent les entités essentielles et importantes peuvent exiger la preuve des mesures de l'article 21 à tout moment, et les auditeurs demandent de plus en plus exactement ce type de documentation.

Base juridique

La checklist s'ancre dans la directive (UE) 2022/2555 (NIS2), en vigueur depuis le 16 janvier 2023 avec une date limite de transposition au 17 octobre 2024. L'article 21(2)(d) inscrit « la sécurité de la chaîne d'approvisionnement, y compris les aspects liés à la sécurité concernant les relations entre chaque entité et ses fournisseurs ou prestataires de services directs » parmi les mesures minimales de gestion des risques. L'article 21(3) impose aux entités de tenir compte des vulnérabilités propres à chaque fournisseur direct et prestataire de services, de la qualité globale de leurs produits et de leurs pratiques de cybersécurité — y compris leurs procédures de développement sécurisé — et des résultats des évaluations coordonnées des risques de sécurité des chaînes d'approvisionnement critiques au titre de l'article 22(1).

La ligne SLA de notification d'incidents se rattache à l'article 23, qui vous oblige à déposer une alerte précoce sous 24 heures après avoir eu connaissance d'un incident important, une notification d'incident sous 72 heures et un rapport final sous un mois. Vous ne pouvez pas tenir ces fenêtres si un incident fournisseur vous parvient tardivement — raison pour laquelle la clause de notification du fournisseur est un élément de preuve, pas un simple bonus. Notre guide sur les articles 21 et 23 pris ensemble traite cette dépendance en profondeur.

Pour les entités d'infrastructure numérique et de services TIC, le règlement d'exécution (UE) 2024/2690 de la Commission du 17 octobre 2024 précise les exigences techniques et méthodologiques, et le guide technique de mise en œuvre de l'ENISA (juin 2025) détaille la vérification des fournisseurs, les clauses contractuelles et la surveillance continue comme attentes de mise en œuvre. Les précédentes bonnes pratiques de cybersécurité de la chaîne d'approvisionnement de l'ENISA (juin 2023) recommandent de tenir une liste documentée des fournisseurs, de définir des critères de risque par type de fournisseur et de revoir périodiquement la capacité des fournisseurs à respecter les exigences de sécurité — le registre et la grille du modèle mettent directement en œuvre ces pratiques. La transposition reste inégale — la Commission a porté les procédures d'infraction au stade des avis motivés contre 19 États membres en mai 2025, et à la mi-2026 la plupart des États membres, mais pas tous, disposent de lois nationales en vigueur (la NIS2UmsuCG allemande, par exemple, a pris effet le 6 décembre 2025). Vos obligations s'imposent dès que la loi de votre État membre s'applique — mais les clients de vos fournisseurs posent déjà la question. Consultez la vue d'ensemble de la directive NIS2 pour le panorama complet de la transposition.

Au-delà de l'UE : Royaume-Uni et Norvège

La même logique de checklist s'étend à toute la carte européenne. Le Royaume-Uni remplace ses règlements NIS de 2018 par le Cyber Security and Resilience Bill, déposé au Parlement le 12 novembre 2025 et devant la Chambre des Lords à la mi-2026, avec une sanction royale attendue fin 2026. Il fait entrer dans le périmètre direct les fournisseurs de services managés, les centres de données éligibles et les « fournisseurs critiques » désignés par les régulateurs, avec une notification initiale sous 24 heures et complète sous 72 heures — les fournisseurs britanniques doivent donc s'attendre à des demandes de preuves exactement de cette forme. La Norvège applique la directive NIS d'origine au travers de la digitalsikkerhetsloven, en vigueur depuis le 1er octobre 2025 et supervisée par le NSM (qui opère aussi le CSIRT national), tandis que NIS2 attend son incorporation dans l'accord sur l'EEE. Si votre base fournisseurs couvre l'UE, le Royaume-Uni et l'EEE, un registre de preuves unique avec des notes par juridiction — comme le propose ce modèle — vaut mieux que trois tableurs parallèles.

De la checklist à l'assurance continue

Un tableur prouve que vous avez un processus ; il ne peut pas relancer les fournisseurs, re-noter les réponses ni vous alerter quand un certificat expire. Quand le registre dépasse la tenue manuelle, la plateforme de vendor assurance d'Orbiq exécute en continu le même workflow de classification, de collecte de preuves et d'escalade — avec des réponses évaluées par IA et une piste d'audit générée comme sous-produit du travail.

---

Sources et références

1. Directive (UE) 2022/2555 (NIS2) — texte intégral — articles 21(2)(d), 21(3), 22, 23 et 34.
2. Règlement d'exécution (UE) 2024/2690 de la Commission — exigences techniques et méthodologiques pour les entités d'infrastructure numérique.
3. ENISA — Technical Implementation Guidance on Cybersecurity Risk Management Measures — juin 2025, version 1.0.
4. ENISA — Good Practices for Supply Chain Cybersecurity — juin 2023.
5. Commission européenne — page politique de la directive NIS2 — état de la transposition et procédures d'infraction.
6. Gouvernement britannique — collection Cyber Security and Resilience Bill — documents et fiches du projet de loi.
7. NSM — Norwegian National Cyber Security Centre — CSIRT national norvégien et contexte de supervision.

Pour aller plus loin

• Vendor assurance sous NIS2 : ce que l'article 21 exige
• Sécurité de la chaîne d'approvisionnement NIS2 : exigences, lacunes et conformité
• Checklist de conformité NIS2 : les exigences complètes de l'article 21
• Documentation des risques tiers NIS2 : ce que les auditeurs veulent voir
• Articles 21 et 23 de NIS2 : notification des incidents et sécurité de la chaîne d'approvisionnement