NIS2 Article 21 : contrôles techniques pour le B2B SaaS, guide de mise en oeuvre

NIS2 Article 21(2) liste dix catégories de mesures de gestion des risques de cybersécurité que toute entité essentielle ou importante doit mettre en place. Le langage de la directive est volontairement agnostique sur les produits. C’est utile pour un régulateur. Ça ne l’est pas pour un lead ingénierie B2B SaaS à 22h qui doit répondre à « quels contrôles avons-nous déjà, et lesquels faut-il déployer ? »

Ce guide est la traduction technique. Pour chaque mesure Article 21(2) : la composante d’architecture B2B SaaS typique qui la satisfait, la vérification qu’un auditeur contrôle réellement, et l’implémentation à faire ce trimestre. Pas de théorie. Stack supposée : un SaaS multi-tenant sur un cloud managé (AWS, GCP, OVH ou similaire), Postgres ou équivalent, un tier web de production, un pipeline CI/CD.

La carte mesures-stack

Mesure Article 21(2)	Où elle vit dans votre stack	Ce qu’un auditeur vérifie
(a) Analyse des risques et politiques de sécurité	Confluence/Notion + une cadence trimestrielle	Politiques datées de moins de 12 mois, signées
(b) Gestion des incidents	Runbook + astreinte + paquet Article 23	Un tabletop chronométré dans les 12 derniers mois
(c) Continuité d’activité	Automatisation des sauvegardes + runbook DR	Un exercice de restauration réussi, daté
(d) Sécurité de la chaîne d’approvisionnement	SBOM + registre sous-traitants + DPA	La liste, les contrats, la cadence de revue
(e) Acquisition sécurisée et gestion des vulnérabilités	Dependabot/Renovate + SAST + SCA	SLA de patch tenus sur les 90 derniers jours
(f) Évaluation de l’efficacité	Audit interne + scan externe	Une note A-F datée, mappages de contrôles
(g) Hygiène cyber et formation	LMS onboarding + simulation phishing	Attestations de complétion par nom
(h) Cryptographie	Config TLS + chiffrement au repos + vault secrets	Chaîne TLS, clés KMS, aucun secret en clair
(i) Sécurité RH et contrôle d’accès	SSO + RBAC + playbook offboarding	Un journal de révocations, pas une promesse
(j) MFA / authentification continue	MFA workforce + MFA client	Taux de couverture, liste d’exceptions

La suite de ce guide détaille les cinq mesures qui sont du ressort de l’ingénierie pure : cryptographie, MFA, logs, gestion des vulnérabilités, et réponse aux incidents.

(h) Cryptographie : TLS est la moitié visible

Un régulateur et un auditeur client ne peuvent pas inspecter votre configuration KMS de l’extérieur. Ils peuvent inspecter votre chaîne TLS depuis un navigateur. La plupart des revues supply-chain NIS2 commencent là car c’est le signal le moins coûteux à obtenir.

Implémentation à faire ce trimestre :

• TLS 1.3 activé, TLS 1.0 et 1.1 désactivés, TLS 1.2 uniquement avec des suites de chiffrement robustes (pas de CBC, pas de RC4, pas de 3DES). Auditez avec testssl.sh ou la méthodologie ouverte dans notre spec de notation transparente.
• Chaîne de certificats complète servie (l’intermédiaire inclus, pas seulement la feuille). Ce point échoue dans environ 1 scan de production B2B SaaS sur 5.
• HSTS avec max-age >= 31536000 et includeSubDomains. Ajoutez preload une fois que vous avez vérifié les sous-domaines.
• Cookies HTTPS uniquement : Secure; HttpOnly; SameSite=Lax ou Strict pour les cookies de session.
• Présence dans les CT logs : chaque cert de production dans au moins deux CT logs. Let’s Encrypt et Cloudflare gèrent cela automatiquement ; les CA privées souvent non.

Au repos : données clients chiffrées avec une CMK dans votre KMS. Les sauvegardes de base de données héritent du chiffrement. L’isolation de clé par tenant n’est pas exigée par l’Article 21(2)(h) mais se lit bien au niveau supérieur d’un entretien d’audit.

Secrets : Doppler, AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault. La vérification est : il n’existe pas de chemin de « clone frais du dépôt » vers « credential de production » qui ne passe pas par le gestionnaire de secrets. Cherchez dans votre codebase sk_live_, AKIA et BEGIN PRIVATE KEY avant que l’auditeur ne le fasse.

(j) MFA et authentification continue : deux surfaces, deux types de risques

L’Article 21(2)(j) nomme explicitement le MFA. Il ne dit pas « pour certains utilisateurs ». Pour un B2B SaaS, le MFA couvre deux populations distinctes.

MFA workforce (salariés, prestataires, fournisseurs avec accès) :

• SSO sur tous les outils adjacents à la production (Okta, Google Workspace, Microsoft Entra). Pas de comptes admin locaux sur les consoles cloud.
• MFA hardware (WebAuthn / FIDO2) pour les rôles privilégiés : admins console cloud, accès production-DB, propriétaires d’organisation GitHub/GitLab. SMS ne compte pas pour ces rôles.
• TOTP acceptable pour les rôles non privilégiés, mais le chemin de migration vers WebAuthn doit être documenté.
• Un compte « break-glass » existe, est nommé, est dans un vault scellé, et son utilisation déclenche une alerte.

MFA client (vos utilisateurs finaux) :

• MFA disponible sur le formulaire de connexion, activé par défaut pour les rôles admin, optionnel pour les utilisateurs finaux (NIS2 est permissif ici ; vos clients enterprise ne l’seront pas).
• TOTP minimum ; WebAuthn pour les plans où c’est économiquement faisable.
• Offboarding SCIM pour les clients avec SSO activé. L’offboarding manuel produit des oublis.

Métrique de couverture à suivre : pourcentage des événements d’accès à la production authentifiés par un facteur résistant au phishing (WebAuthn ou carte à puce). Un auditeur ne demande pas « avez-vous le MFA » ; il demande « quel est votre taux de couverture et votre liste d’exceptions ».

(b) Logs : le contrôle ennuyeux qui décide des audits

Les auditeurs et les intervenants sur incident ont besoin de reconstruire ce qui s’est passé, quand, par qui, et depuis où. Les logs sont le moyen d’y parvenir. Le piège : des logs sans rétention sont du théâtre, et une rétention sans intégrité est pire.

La surface minimale à journaliser :

• Événements d’authentification : succès / échec / défi MFA / assertion SSO / émission de token, avec IP source et user-agent.
• Changements d’autorisation : attribution de rôles, modifications de périmètre, élévations de privilèges.
• Accès à la production : chaque session console, chaque session kubectl/psql/SSM, avec l’identité de l’utilisateur (pas « l’équipe d’astreinte »).
• Événements d’export de données : toute lecture en masse ou téléchargement de données client au-dessus d’un seuil (ex : >1 000 lignes).
• Actions API administratives dans votre propre produit : qui a modifié quelle configuration tenant et quand.

Rétention et intégrité :

• 12 mois minimum pour les logs liés à la sécurité. Plus longtemps si les évaluateurs supply-chain le demandent (c’est souvent le cas).
• Logs expédiés hors de la machine qui les a générés, idéalement en quelques secondes. Un log auto-supprimable équivaut à aucun log.
• Stockage inaltérable (S3 Object Lock, GCS Bucket Lock, un datastore en ajout seul). Le test de l’auditeur : « quelqu’un ayant accès à la prod peut-il supprimer une entrée de log sans que ce soit visible ? »
• Une couche interrogeable (Loki, OpenSearch, Datadog) pour répondre aux questions d’audit en minutes, pas en jours.

Si vous journalisez tout mais ne pouvez pas répondre à « montrez-moi chaque accès à la production-DB par l’utilisateur X en mars », vos logs sont incomplets.

(e) Gestion des vulnérabilités : la cadence que les auditeurs contrôlent

L’Article 21(2)(e) couvre la gestion des vulnérabilités. Le schéma qui le satisfait pour un B2B SaaS :

• SCA : Dependabot, Renovate ou Snyk sur chaque dépôt. PR automatique pour les versions non majeures. Revue hebdomadaire pour le reste. SBOM (CycloneDX ou SPDX) générés à chaque build et conservés par release.
• SAST : un scanner de base (Semgrep OSS, CodeQL, Snyk Code) en CI. Bloquage des merges sur les nouveaux résultats critiques / élevés ; les moyens / faibles passent avec un ticket de suivi.
• DAST : scan externe contre le staging et la production (c’est ce que SaaSFort exécute contre le domaine de production en 60 secondes, mappé aux contrôles NIS2 ; exécutez-le depuis la CI pour détecter les régressions à chaque déploiement).
• Scan containers et infra : Trivy / Grype sur chaque build d’image. Blocage des déploiements sur les CVE critiques dans l’image de base.
• SLA de patch, écrits : critique 7 jours, élevé 30 jours, moyen 90 jours. Suivez l’adhérence. Les auditeurs demandent le dashboard.

Surface de divulgation : un security.txt public par RFC 9116 à /.well-known/security.txt. Un email de contact sécurité surveillé. Un SLA de réponse que vous tenez réellement. Le bug-bounty le plus léger possible (page de divulgation responsable, pas de programme payant requis) couvre l’obligation de divulgation de l’Article 21(2)(e).

(b) Réponse aux incidents : runbook, tabletop et paquet auditeur

Les logs vous disent ce qui s’est passé. Le runbook dit à votre équipe quoi faire. L’Article 23 informe le régulateur. Le paquet auditeur informe l’évaluateur du client au prochain cycle fournisseur.

La stack minimum :

• Un rôle de commandant d’incident nommé (rotation, pas « le CTO »). Une rotation d’astreinte qui inclut les nuits et les week-ends.
• Un runbook d’incident contenant au minimum : sources de détection, classification des sévérités, modèles de communication (interne, client, régulateur), le calendrier de reporting NIS2 24h / 72h / 30j.
• Un tabletop chronométré une fois par an. Daté. Résultats documentés. Exécutez le kit de préparation aux incidents gratuit une première fois pour l’amorcer.
• Les rapports post-incident conservés au moins cinq ans.

La vérification qu’un auditeur effectue : « montrez-moi votre tabletop le plus récent. » Si la réponse est « nous n’en faisons pas » ou « de manière informelle », c’est noté comme un écart. Si la réponse est un compte-rendu daté de trois pages avec des participants nommés et un registre de remédiation, ça clôt la ligne.

Les contrôles transversaux que la plupart des équipes oublient

Trois contrôles vivent à travers plusieurs mesures et passent entre les mailles d’une implémentation pilotée par la conformité.

• (d) Supply chain : un registre de sous-traitants, des DPA avec chacun, un processus d’évaluation des risques fournisseurs, la preuve que l’évaluation s’exécute à l’onboarding et au renouvellement. Un sous-traitant est tout ce qui traite des données client pour votre compte : votre cloud, votre expéditeur d’emails, votre tracker d’erreurs, votre fournisseur IA. Le registre est l’artefact, pas une intention.
• (i) Contrôle d’accès : RBAC dans votre propre produit, pas seulement AdminUser vs RegularUser. Un auditeur veut voir « quels rôles existent, qui les détient, quand ont-ils été passés en revue pour la dernière fois ». Une revue d’accès trimestrielle avec signature est le moyen le moins coûteux de passer.
• (g) Hygiène et formation : simulation de phishing, onboarding de sensibilisation à la sécurité, rappels. Le livrable est des attestations de complétion par nom, conservées.

Comment ça s’intègre au workflow SaaSFort

Le modèle d’auto-audit Article 21 est la couche documentation. Le scan externe gratuit est la couche de vérification pour les mesures techniquement testables (h), (e), et les parties visibles de l’extérieur de (b). La page de confiance publique est ce qu’ouvre l’auditeur de votre client enterprise avant l’appel. Ensemble : documenté, scanné, publié. C’est le schéma opérationnel.

FAQ

Les dix mesures sont-elles toutes obligatoires ou fondées sur le risque ?

Obligatoires dans le périmètre. La directive utilise « le cas échéant » pour la cryptographie et le MFA, ce qui a été interprété restrictivement par les régulateurs des États membres. Supposez obligatoires lors de l’audit jusqu’à indication contraire.

La certification ISO 27001 est-elle un raccourci ?

Elle se mappe étroitement à l’Article 21(2) et satisfait la plupart des mesures dans l’esprit. Elle ne vous exempte pas de devoir démontrer les contrôles de manière externe. Beaucoup de fournisseurs certifiés ISO 27001 échouent encore aux revues fournisseurs parce que la note de posture externe est testable et que le certificat ne l’est pas.

Quel est le programme Article 21 minimum viable ?

Politiques documentées (a, c, g, i), un runbook d’incident fonctionnel avec un tabletop par an (b), TLS + MFA + secrets (h, j), Dependabot + SAST + scan externe (e), un registre de sous-traitants (d), et une note externe que vous pouvez présenter à la demande (f). Tout ce qui dépasse cette base est une réduction de risque incrémentale, pas un prérequis.

Comment ça se rapporte à DORA ou SOC 2 ?

DORA se superpose pour les entités du secteur financier (reporting ICT-risque et incidents plus granulaire). Les Trust Services Criteria de SOC 2 recoupent environ 70 % de l’Article 21 ; les différences portent sur les délais de notification d’incident et la profondeur supply-chain. Aucun ne remplace les autres lors d’un audit.

---

Les mesures de l’Article 21(2) ne sont pas une liste de souhaits. Ce sont les contrôles qu’une équipe B2B SaaS doit démontrer en direct, en 45 minutes, face à l’évaluateur d’un client qui a fait ça vingt fois ce trimestre. Lancez un scan gratuit pour voir le sous-ensemble testable de l’extérieur noté maintenant, puis publiez votre page de confiance pour que la prochaine revue commence là où elle devrait : à la vérification.