monsys.ai
NLFREN
ConnexionCommencer
Guide conformité · 2026-05-25

Ce qu'un auditeur NIS2 attend de vous — et comment le prouver concrètement

NIS2 est en vigueur en Belgique. Neuf exigences de l'article 21, chacune avec la question de l'auditeur, la preuve qu'il attend, et la page monsys qui livre cette preuve sans travail supplémentaire.

NIS2 est en vigueur en Belgique. Le CCB (Centre pour la Cybersécurité Belgique) a des pouvoirs de contrôle. Mais que cela signifie-t-il concrètement quand un auditeur sonne à votre porte ?

Cet article n'est pas une interprétation juridique — pour cela vous avez besoin d'un avocat. Ce qu'il donne : un aperçu concret des questions que pose un auditeur NIS2, des preuves qu'il attend, et de la façon de produire ces preuves dès aujourd'hui.

Les neuf exigences de l'article 21

L'article 21 NIS2 impose des « mesures techniques et organisationnelles appropriées ». La transposition belge spécifie neuf domaines. On parcourt chacun avec la question que pose l'auditeur, et la preuve nécessaire.

1. Politique d'analyse des risques et de sécurité de l'information

Question auditeur : « Montrez-moi votre analyse de risques de l'année écoulée. »

Ce qu'il faut : Une analyse documentée + preuve qu'elle est à jour.

Comment monsys aide : Le Trust Score (0-100) est un chiffre de risque reproductible sur six composantes : patch hygiene, agent health, secrets exposure, configuration drift, EAT discipline, evidence continuity. Le chiffre change toutes les 30 minutes en fonction des données live. Vous pouvez montrer l'évolution sur 90 jours comme tendance — c'est une analyse de risques vivante, pas un document annuel qui dort dans un tiroir.

Vue d'ensemble du Trust Score avec évolution et composantes Le Trust Score pour le tenant — un seul chiffre, composition transparente, mis à jour en continu.

2. Gestion des incidents

Question auditeur : « Quel était votre temps de réponse moyen sur les incidents critiques ? Montrez-moi la timeline des trois derniers. »

Ce qu'il faut : Une piste d'audit par incident avec horodatage : détecté, escaladé, résolu.

Comment monsys aide : Chaque événement de détection a detected_at, acknowledged_at, resolved_at. Le worker de corrélation SMART ajoute les tags MITRE. Les Emergency Actions sont journalisées avec issued_at et exit_code. Le dashboard MTTR montre p50/p95 par sévérité sur 90 jours.

Vue d'ensemble des alertes & incidents La vue alertes montre les incidents ouverts et fermés avec sévérité, source et âge — directement cliquables vers la timeline complète.

3. Continuité d'activité et gestion de crise

Question auditeur : « Prouvez que vos backups fonctionnent et ont été testés récemment. »

Ce qu'il faut : Logs des runs de backup par système, succès/échecs inclus.

Comment monsys aide : L'agent inventorie les configurations et runs de backup par hôte. L'auditeur voit pour chaque serveur de production quand le dernier backup réussi a tourné et combien de runs ont échoué sur 90 jours.

4. Sécurité de la chaîne d'approvisionnement

Question auditeur : « Comment savez-vous quels composants logiciels tiers tournent en production et s'ils sont vulnérables ? »

Ce qu'il faut : Une BOM logicielle (Bill of Materials) à jour avec statut CVE.

Comment monsys aide : L'agent scanne package-lock.json, requirements.txt, composer.lock, go.sum et les packages OS. Le hub compare quotidiennement à OSV.dev et NVD. Vous avez à tout moment un statut CVE par hôte, par dépendance, avec version corrigée, pondéré par exposition Internet et probabilité d'exploitation EPSS.

Recommandations avec actions CVE priorisées Les recommandations sont priorisées par blast radius : une Critical sur un edge Internet-facing pèse plus qu'une même Critical sur un dev-serveur isolé.

5. Sécurité dans l'acquisition, le développement et la maintenance

Question auditeur : « Comment détectez-vous les changements de logiciels en production ? »

Ce qu'il faut : Preuve de détection de changement et de gestion des changements.

Comment monsys aide : Le fingerprinting Process DNA détecte quand une binaire en production change sans mise à jour de package connue. La drift detection compare les fichiers de configuration à une baseline. Le time-machine diff montre par hôte ce qui a changé entre deux moments : packages ajoutés/supprimés/upgradés, services, ports ouverts, kernel.

Page intégrité avec statut process DNA par hôte La page intégrité montre par hôte si des binaires dévient de la baseline ou d'un manifest connu.

6. Politiques et procédures pour l'évaluation de l'efficacité des mesures

Question auditeur : « Comment mesurez-vous si vos mesures de sécurité fonctionnent ? »

Ce qu'il faut : Un KPI mesurable qui démontre l'efficacité des contrôles.

Comment monsys aide : Le Trust Score est précisément cela. Le worker compliance-erosion détecte quand les contrôles dégradent silencieusement. La timeline de conformité montre par framework (NIS2, ISO 27001, CRA) quels contrôles passent ou échouent dans quel mois.

Page conformité avec statut par framework Statut de conformité par framework, avec vue directe sur les contrôles en échec.

7. Pratiques de base d'hygiène cyber

Question auditeur : « Quelles mesures d'hygiène de base sont techniquement appliquées ? »

Ce qu'il faut : Preuve de contrôles techniques, pas seulement un document politique.

Comment monsys aide : L'inventaire contient pour chaque hôte : password policy depuis /etc/shadow, empreintes des clés SSH, configuration sudoers, fichiers SUID/SGID, répertoires world-writable. C'est une preuve d'implémentation technique de l'hygiène de base.

Inventaire avec contrôles techniques par hôte La page inventaire agrège ce que l'agent a trouvé sur l'hôte : packages, services, utilisateurs, clés SSH, certificats.

8. Politiques et procédures pour la cryptographie

Question auditeur : « Quels contrôles cryptographiques sont actifs et audités ? »

Comment monsys aide : La signing chain (Ed25519 par agent, par hub) est documentée et auditable. La rotation des clés est journalisée dans le transparency log. Les scans de certificats détectent les certificats expirant 60+ jours à l'avance.

9. Sécurité du personnel et politique d'accès

Question auditeur : « Quels utilisateurs ont des droits admin et comment est-ce suivi ? »

Comment monsys aide : La page RBAC montre par utilisateur le rôle, l'accès par agent/groupe et l'usage récent. Les admins qui n'exécutent jamais d'Emergency Actions → candidats pour rétrogradation vers least-privilege.

RBAC : utilisateurs, rôles et scope La page RBAC montre qui a quel rôle sur quel scope (tenant-wide ou limité à un groupe / agent).

Le jour de l'audit : ce que vous apportez

Un audit NIS2 se déroule en deux phases : une revue documentaire et une vérification technique. Pour la revue documentaire, un auditeur ne veut pas de dashboards — il veut un artifact qu'il peut vérifier offline.

L'Auditor Workbench monsys génère mensuellement une bundle ZIP :

Vue audit packs avec bundles mensuels Les audit packs mensuels sont générés automatiquement ; un auditeur télécharge la tarball et vérifie offline.

L'auditeur vérifie :

python verify.py evidence_acme-corp_Q1-2026.tar.gz
✓ Signature valid (Ed25519)
✓ All 847 entries intact
✓ Period: 2026-01-01 → 2026-03-31
exit 0

Pas besoin d'accès dashboard. Pas de captures d'écran. Pas de « faites-nous confiance ».

Ce que nous ne promettons pas

La conformité NIS2 n'est pas un produit qu'on achète — c'est un effort continu. monsys livre :

monsys ne livre pas :

Mais si un auditeur demande « prouvez que CVE-2026-XXXX a été corrigée endéans sept jours sur tous vos serveurs de production », et que vous pouvez le montrer en cinq minutes avec une timeline signée — alors vous avez un avantage significatif sur ceux qui doivent le reconstruire manuellement.

Les workflows auditeur sont documentés dans docs.monsys.ai/fr/practical/auditor. Cinq premiers serveurs gratuits, pas de carte bancaire : monsys.ai/fr/signup.

← Retour au blog