SaaSFort Quand l’équipe procurement d’un acheteur enterprise lance sa revue de sécurité fournisseur, elle envoie généralement un DDQ — questionnaire de due diligence — de 80 à 150 questions. Environ 40 % des questions mappent directement aux 10 mesures de l’Article 21 de NIS2. Si vous ne pouvez pas produire des preuves dans les 48 heures, vous n’êtes plus en lice.
Cet article décompose les 7 domaines de preuves que les auditeurs NIS2 vérifient, avec exactement ce qu’il faut préparer dans chacun. Pour le plan semaine par semaine sur 90 jours, consultez notre plan d’action NIS2 en 90 jours.
Les 7 domaines de preuves NIS2 pour les éditeurs SaaS
Domaine 1 — Posture de sécurité externe
Mesure Article 21 : 21.2(e) sécurité réseau, 21.2(h) cryptographie
C’est ce que les auditeurs et les attaquants voient depuis l’extérieur de votre périmètre. C’est aussi la première chose vérifiée — en 60 secondes, n’importe quel auditeur peut scanner votre domaine et voir votre état de sécurité externe.
Ce que vous devez préparer :
- Rapport de scan de sécurité externe datant de moins de 30 jours, avec une note A ou B
- Validation de la chaîne de certificats TLS (pas d’expiration imminente, chaîne complète)
- Headers de sécurité en place : HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy
- Enregistrements DNS : SPF, DKIM, DMARC (politique p=quarantine ou p=reject), DNSSEC, CAA
- Aucun port admin ou service de gestion exposé publiquement
Preuve type : Rapport PDF SaaSFort horodaté avec mapping des contrôles NIS2. Disponible en scan gratuit en 60 secondes.
Fréquence : Scans continus (hebdomadaires minimum). Les auditeurs veulent voir un historique, pas un snapshot unique.
Domaine 2 — Contrôle d’accès et gestion des identités
Mesure Article 21 : 21.2(i) contrôle d’accès, 21.2(j) MFA
L’Article 21 exige la MFA et des politiques documentées de contrôle d’accès. La plupart des équipes ont la MFA disponible — les auditeurs veulent la preuve qu’elle est appliquée.
Ce que vous devez préparer :
- Politique de contrôle d’accès écrite (principe du moindre privilège, RBAC, révision d’accès)
- Preuve d’application de la MFA : export des utilisateurs avec statut MFA, politique d’administration montrant la MFA obligatoire (pas optionnelle)
- Processus de gestion des accès : onboarding, départ (offboarding dans les 24h), changement de rôle
- Registre de révision d’accès privilégié (au moins trimestriel)
- Comptes de service et API keys : inventoriés, rotatifs périodiquement, pas dans le code source
Preuve type : Export de la politique d’administration (ex. Azure AD / Okta / Google Workspace) montrant MFA = required pour tous les utilisateurs. Log de départ du dernier employé avec date de révocation d’accès.
Erreur courante : La MFA est activée mais pas obligatoire. Les auditeurs testent cela en demandant « montrez-moi un utilisateur sans MFA actif » — si la liste n’est pas vide, c’est une non-conformité.
Domaine 3 — Réponse aux incidents
Mesure Article 21 : 21.2(b) gestion des incidents
Article 23 : notification 24h/72h/1 mois
La réponse aux incidents est le domaine le plus procédural de NIS2. Les auditeurs ne vérifient pas seulement si vous avez un plan — ils vérifient si votre plan a été testé.
Ce que vous devez préparer :
- Plan de réponse aux incidents (IRP) écrit, daté et signé par la direction
- Définition de l’incident « significatif » adaptée à votre contexte (avec exemples concrets)
- Matrice d’escalade : qui appelle qui, dans quel ordre, à n’importe quelle heure
- Contact BSI Meldeportal épinglé et numéro d’inscription BSI (si applicable)
- Modèles de notification 24h/72h/1 mois pré-remplis (disponibles dans notre kit de préparation aux incidents)
- Journal des incidents : log de tous les incidents (même mineurs) avec horodatages, nature, remédiation
- Preuve de test : rapport d’exercice tabletop (90 minutes, 3 scénarios recommandés)
Preuve type : Rapport de l’exercice tabletop avec date, participants, scénarios testés, et notification de 24h produite pendant l’exercice.
Fréquence : IRP révisé annuellement. Exercice tabletop au moins une fois avant octobre 2026, puis semestriel.
Domaine 4 — Continuité d’activité et reprise après sinistre
Mesure Article 21 : 21.2(c) continuité d’activité, sauvegardes, gestion de crise
Les auditeurs distinguent le plan théorique de la preuve de fonctionnement. Une politique de sauvegarde non testée n’est pas une preuve — c’est une intention.
Ce que vous devez préparer :
- Politique de continuité d’activité (BCP) avec RTO et RPO définis par système critique
- Politique de sauvegarde : fréquence, rétention, chiffrement, emplacement (hors site obligatoire)
- Rapport de test de restauration (daté, avec résultat de vérification de l’intégrité des données)
- Plan de reprise après sinistre (DR) avec étapes documentées
- Inventaire des systèmes critiques avec leurs dépendances et priorités de reprise
Objectifs typiques pour un éditeur SaaS :
| Système | RTO | RPO |
|---|---|---|
| Application principale | 4 heures | 1 heure |
| Base de données | 2 heures | 15 minutes |
| Infrastructure CI/CD | 8 heures | 24 heures |
| Outils internes | 24 heures | 24 heures |
Preuve type : Log de restauration avec horodatage, système restauré, données vérifiées, durée de l’opération. Idéalement : capture d’écran ou export de votre outil de backup montrant la dernière restauration réussie.
Fréquence : Test de restauration au moins annuel, semestriel recommandé.
Domaine 5 — Chiffrement
Mesure Article 21 : 21.2(h) politiques et procédures cryptographiques
L’Article 21(2)(h) exige des politiques documentées sur l’utilisation de la cryptographie. Pour les éditeurs SaaS, cela couvre le chiffrement en transit et au repos.
Ce que vous devez préparer :
- Politique cryptographique écrite : algorithmes approuvés, durées de vie des clés, gestion des clés
- Chiffrement en transit : TLS 1.2+ (TLS 1.3 recommandé), cipher suites documentées, pas de protocoles dépréciés (SSL, TLS 1.0/1.1)
- Chiffrement au repos : AES-256 pour les données sensibles, documentation de l’implémentation
- Gestion des clés : rotation périodique, stockage sécurisé (HSM ou KMS géré), inventaire des clés
- Certificats : inventaire avec dates d’expiration, processus de renouvellement automatisé
Preuve type : Rapport de scan TLS montrant la configuration des cipher suites. Document d’architecture de chiffrement. Export du gestionnaire de secrets (Vault, AWS KMS, Doppler) sans les valeurs des secrets.
Erreur courante : TLS configuré correctement en production mais pas sur les environnements de staging ou les sous-domaines internes. Les auditeurs scannent tous les sous-domaines.
Domaine 6 — Sécurité de la chaîne d’approvisionnement
Mesure Article 21 : 21.2(d) sécurité de la chaîne d’approvisionnement
C’est le domaine où la plupart des éditeurs SaaS ont le plus de lacunes. L’Article 21(2)(d) exige que vous évaliiez la sécurité de vos propres fournisseurs — pas seulement que vos clients vous évaluent.
Ce que vous devez préparer :
- Liste exhaustive de vos sous-traitants et fournisseurs ayant accès à vos systèmes ou données (registre des sous-traitants RGPD est un bon point de départ)
- Évaluation de sécurité pour chaque fournisseur critique : certification ISO 27001 ou SOC 2, ou questionnaire de sécurité complété, ou scan de posture externe
- Critères documentés pour la sélection et la contractualisation avec les fournisseurs
- Clauses de sécurité dans les contrats fournisseurs (exigences de notification d’incident, droit d’audit)
- Processus de revue fournisseur périodique (annuel minimum)
Fournisseurs typiques à évaluer :
- Hébergeur cloud (AWS, GCP, Azure, OVH) — ISO 27001 déjà certifiés, télécharger le certificat
- Outils SaaS critiques (CRM, analytics, support) — demander leur rapport SOC 2 ou leur questionnaire de sécurité
- Processeur de paiement (Stripe, Adyen) — certifications PCI-DSS disponibles publiquement
- Service d’email transactionnel — vérifier SPF/DKIM/DMARC de leur infrastructure
Preuve type : Tableau fournisseurs avec colonne certification / évaluation / date de dernière revue. Certificats ISO 27001 téléchargés pour les hébergeurs cloud. Scan SaaSFort sur le domaine principal de chaque fournisseur clé.
Domaine 7 — Gestion des vulnérabilités
Mesure Article 21 : 21.2(f) traitement et divulgation des vulnérabilités
L’Article 21 exige un processus documenté de gestion des vulnérabilités — avec des SLA de correction définis et un historique de respect de ces SLA.
Ce que vous devez préparer :
- Politique de gestion des vulnérabilités avec SLA de correction par niveau de criticité
- Calendrier de scan : fréquence, périmètre (externe, dépendances, conteneurs), outil utilisé
- Registre de vulnérabilités : liste de toutes les vulnérabilités connues, statut, date cible de correction
- Politique de divulgation responsable (fichier security.txt, page de contact sécurité)
- Historique de remédiation : preuves que les vulnérabilités critiques ont été corrigées dans les SLA
SLA de correction NIS2-compatibles :
| Niveau | CVSS | Délai de correction |
|---|---|---|
| Critique | 9.0 – 10.0 | 24 heures |
| Élevé | 7.0 – 8.9 | 7 jours |
| Moyen | 4.0 – 6.9 | 30 jours |
| Faible | 0.1 – 3.9 | 90 jours |
Preuve type : Historique de scans SaaSFort avec horodatages (montre la surveillance continue). Log de remédiation des 6 derniers mois avec dates d’ouverture et de fermeture des vulnérabilités. Fichier security.txt accessible sur votre domaine.
Structure recommandée du dossier de preuves
Organisez vos preuves dans une structure de dossiers logique pour faciliter le partage avec les auditeurs :
/dossier-conformite-nis2/
├── /01-posture-externe/
│ ├── scan-saasfort-YYYY-MM.pdf
│ ├── rapport-tls-YYYY-MM.pdf
│ └── historique-scans/ (6 derniers mois)
├── /02-controle-acces/
│ ├── politique-controle-acces-vN.pdf
│ ├── export-mfa-obligatoire.pdf
│ └── registre-revisions-acces.xlsx
├── /03-reponse-incidents/
│ ├── plan-reponse-incidents-vN.pdf
│ ├── rapport-tabletop-YYYY-MM.pdf
│ ├── journal-incidents.xlsx
│ └── modeles-notification/
├── /04-continuite-activite/
│ ├── politique-bcp-vN.pdf
│ ├── rapport-test-restauration-YYYY-MM.pdf
│ └── registre-sauvegardes.xlsx
├── /05-chiffrement/
│ ├── politique-cryptographie-vN.pdf
│ ├── inventaire-certificats.xlsx
│ └── rapport-cipher-suites.pdf
├── /06-chaine-approvisionnement/
│ ├── registre-fournisseurs.xlsx
│ ├── certifications-fournisseurs/
│ └── clauses-contractuelles-type.pdf
└── /07-gestion-vulnerabilites/
├── politique-vulnerabilites-vN.pdf
├── registre-vulnerabilites.xlsx
├── security.txt (confirmation de publication)
└── historique-remediation/
Versionez vos politiques (vN) et datez tous vos rapports. Un auditeur qui reçoit un dossier bien organisé passe 80 % de son temps à vérifier — pas à chercher.
Les 3 erreurs qui font échouer les éditeurs SaaS aux audits NIS2
Erreur 1 : Preuves obsolètes
Un rapport de scan de septembre 2025 n’est pas une preuve de conformité en 2026. Les auditeurs veulent une surveillance continue — pas un snapshot ponctuel. La règle pratique : toute preuve datant de plus de 90 jours doit être régénérée pour l’audit.
Solution : Configurez des scans automatisés hebdomadaires. SaaSFort génère des rapports horodatés à chaque scan — votre historique devient automatiquement votre preuve de surveillance continue.
Erreur 2 : Politique sans preuve d’implémentation
Vous avez une politique de sécurité de 20 pages qui dit « nous appliquons la MFA ». L’auditeur demande à voir un utilisateur sans MFA active. Il y en a 12. La politique dit une chose ; la réalité en dit une autre.
Solution : Pour chaque contrôle politique, identifiez la preuve technique correspondante. La politique d’accès → export du statut MFA. La politique de chiffrement → rapport TLS. La politique de sauvegarde → log de restauration.
Erreur 3 : Chaîne d’approvisionnement non documentée
C’est la lacune la plus fréquente. Les éditeurs SaaS documentent leurs propres contrôles mais n’évaluent pas leurs fournisseurs. L’Article 21(2)(d) est explicite : vous devez évaluer la sécurité de vos sous-traitants.
Solution : Démarrez avec vos 5 fournisseurs les plus critiques. Lancez un scan SaaSFort sur leur domaine — vous obtenez une preuve objective de leur posture externe en 60 secondes. Téléchargez leur certificat ISO 27001 ou rapport SOC 2. Documentez dans votre tableau fournisseurs.
FAQ : Préparation aux audits NIS2
Combien de temps faut-il pour préparer un dossier de preuves NIS2 complet ?
Avec les bons outils, 4 à 6 semaines pour une première préparation. Le plus long : la documentation de la chaîne d’approvisionnement (Domaine 6) et la mise en place d’un processus de réponse aux incidents testé (Domaine 3). La posture de sécurité externe (Domaine 1) est prête en 60 secondes avec un scan automatisé.
Les auditeurs acceptent-ils les preuves auto-générées ?
Oui, si elles sont horodatées et vérifiables. Un rapport de scan SaaSFort avec horodatage et signature numérique est une preuve acceptable. Une capture d’écran sans horodatage l’est moins. Les preuves générées automatiquement (exports de systèmes d’administration, logs de scan) ont plus de poids que les documents préparés manuellement.
Faut-il un auditeur externe pour la conformité NIS2 ?
Non obligatoirement — la directive ne prescrit pas d’audit externe par défaut. Pour les entités essentielles (250+ salariés), les régulateurs peuvent exiger un audit externe. Pour les entités importantes, l’auto-évaluation documentée est généralement acceptée. Consultez votre autorité nationale (BSI pour l’Allemagne, ANSSI pour la France) pour les exigences spécifiques à votre secteur.
Comment prouver la conformité NIS2 à mes propres clients ?
Partagez votre Deal Report SaaSFort — il mappe votre posture de sécurité externe à tous les contrôles Article 21(2). Complétez-le avec votre politique de réponse aux incidents et votre certification hébergeur. Ce package couvre 80 % des questions des équipes procurement enterprise. Consultez notre guide sur les preuves de sécurité pour les deals enterprise.
Quelle est la différence entre le dossier de preuves NIS2 et un rapport SOC 2 ?
Le SOC 2 est un audit tiers volontaire — il couvre des domaines similaires mais produit un rapport standardisé signé par un auditeur externe. Le dossier de preuves NIS2 est auto-assemblé mais obligatoire légalement. Pour la comparaison complète : SOC 2 vs NIS2 — quel cadre en premier.
La préparation NIS2 n’a pas à prendre des mois. Lancez votre scan de sécurité externe gratuit maintenant — 60 contrôles en 60 secondes, rapport PDF mappé NIS2 inclus. Téléchargez ensuite le modèle d’audit NIS2 en 10 contrôles pour travailler systématiquement sur chaque domaine de preuves.
Von der Theorie zur Praxis
Scannen Sie Ihre Domain kostenlos. Erste Ergebnisse in unter 10 Sekunden — ohne Registrierung.