Actualités

Paquet cybersécurité UE (20 janv. 2026) : small mid-cap et reclassification NIS2 — comment sécuriser votre statut et vos preuves

Icon svg Cyber Filing

Paquet cybersécurité UE (20 janv. 2026) : small mid-cap (projet) et impacts possibles sur NIS2. Checklist pour sécuriser statut et preuves.

Le 20 janvier 2026, la Commission européenne a présenté un paquet cybersécurité (projet) incluant des modifications ciblées proposées à NIS2 et une révision du Cybersecurity Act. (Source)

Une nouveauté attire l’attention : la catégorie “small mid-cap” (projet), qui pourrait reclasser certaines ETI régulées en “important entities” et faire évoluer la supervision associée.

Pour les équipes conformité et sécurité, l’enjeu est double : sécuriser la classification et tenir un dossier de preuves robuste — sans traiter une proposition comme du droit applicable.

Convention de lecture : les mesures issues du paquet du 20 janv. 2026 sont indiquées (projet). Le reste décrit le droit en vigueur.


TL;DR

  • 20 janv. 2026 : paquet cybersécurité UE présenté (projet) : modifications proposées à NIS2 + révision du Cybersecurity Act. (Source)
  • “Small mid-cap” (projet) : la proposition renvoie à la Recommandation (UE) 2025/1099 (définition).
  • Impact possible (projet) : les small mid-caps seraient, en règle générale, désignées comme “important entities”.
  • Droit en vigueur : tant que non adopté/transposé, le cadre applicable reste celui de NIS2 telle que transposée et des textes nationaux applicables — y compris sanctions et exigences de preuve. (Source)
  • 30 jours : dossier de classification + Evidence Pack multi-cloud + capacité de preuve incident/ransomware.

Projet vs droit en vigueur — ce qui change, ce qui reste

Projet — package du 20 janv. 2026 (en négociation)

  • Small mid-cap (projet) : la proposition prévoit d’introduire la catégorie dans NIS2 (renvoi à la Recommandation (UE) 2025/1099) ; désignation “important entity” comme règle générale.
  • DNS (projet) : la proposition mentionne des ajustements de périmètre concernant certains fournisseurs DNS (détails dans le texte de proposition).
  • Électricité (projet) : la proposition mentionne un seuil pour certains producteurs d’électricité (détails dans le texte de proposition).
  • Ransomware reporting (Article 23) (projet) : la proposition précise les informations qui pourraient être demandées dans des actes d’exécution (ex. vecteur d’attaque, mesures d’atténuation, informations sur rançon), à confirmer dans le texte final.
  • Certificat “cyber posture” (projet) : si le certificat démontre la conformité aux exigences couvertes, le texte prévoit que l’autorité ne devrait pas imposer de mesures additionnelles sur ces exigences couvertes ; la responsabilité de conformité demeure (sous réserve du texte final).
  • Transposition / entrée en vigueur (projet) : transposition 12 mois après l’entrée en vigueur ; entrée en vigueur 20 jours après publication au JOUE.
  • ENISA (renforcement) (projet) : rôle renforcé + budget plus de 75% + deux liaison officers par État membre (selon Q&A). (Source)
  • Single-entry point (projet) : proposé dans le Digital Omnibus (initiative séparée), et le package indique qu’il le complète. (Source)

Droit en vigueur (cadre actuel)

  • NIS2 : entrée en vigueur le 16 janvier 2023 ; échéance de transposition 17 octobre 2024 ; application dépend des textes nationaux. (Source)
  • Incident reporting NIS2 (Article 23) : exigences de reporting en plusieurs étapes (souvent résumées 24h / 72h / rapport final). (Source)
  • Sanctions minimales NIS2 (Article 34) : essential entities ≥ 10 M€ ou 2% CA mondial ; important entities ≥ 7 M€ ou 1,4% (selon transposition). (Source)
  • DORA : entrée en vigueur 16/01/2023, applicable 17/01/2025. (Source)
  • CRA : entrée en vigueur 10/12/2024 ; obligations de reporting 11/09/2026 ; obligations principales 11/12/2027. (Source)

Note compliance-grade : l’applicabilité exacte dépend du texte final et des transpositions nationales. Ne pas traiter une proposition comme une obligation en vigueur.


Pourquoi documenter la classification dès maintenant

Le package n’est pas du droit directement applicable : il suit la procédure législative (Parlement/Conseil), puis transposition. (Source)

En revanche, une action “no-regret” existe : documenter la classification et industrialiser un dossier de preuves (Article 21 + incident + multi-cloud), parce que c’est ce qui tient en audit, indépendamment des débats en cours.


Small mid-cap (projet) : définition et impacts sur la classification NIS2

Small mid-cap enterprise : Catégorie (projet) renvoyant à la Recommandation (UE) 2025/1099 ; utilisée pour adapter des obligations et/ou modalités de supervision à des entreprises intermédiaires.

Définition (renvoi à la Recommandation (UE) 2025/1099)

La proposition définit “small mid-cap enterprise” par renvoi à la Recommandation (UE) 2025/1099. Dans cette recommandation, les small mid-caps sont définies notamment par < 750 employés et ≤ 150 M€ de CA ou ≤ 129 M€ de total bilan. (Source)

Impact potentiel sur supervision & sanctions

Le texte indique que les small mid-caps seraient, en règle générale, désignées comme “important entities”.

Conséquence pratique : si votre statut bascule, le plafond de sanctions applicable est celui d’“important entity” (règles minimales NIS2 déjà en vigueur), plutôt que celui d’“essential entity”. (Source)

Selon le modèle de supervision retenu au final, votre capacité à démontrer a posteriori (preuves, journaux, décisions, timelines) devient encore plus critique.


Évolutions possibles du périmètre et du reporting ransomware

Scope : quelques clarifications explicitement mentionnées

Le projet indique des clarifications concernant notamment les fournisseurs DNS et les producteurs d’électricité (détails dans le texte de proposition).

Ransomware : standardisation des données reportées

Le projet précise les informations qui pourraient être demandées :

  • informations sur la détection de ransomware, le vecteur d’attaque, les mesures d’atténuation ;
  • sur demande CSIRT/autorité, information sur la demande de rançon et le paiement (détails à confirmer dans le texte final).

Conséquence pratique (bonnes pratiques d’audit) : votre playbook doit permettre de documenter ces éléments et de produire une timeline exploitable, surtout en contexte multi-cloud.


ENISA (projet) : rôle envisagé et coordination au niveau UE

La Commission décrit un renforcement d’ENISA (opérationnel + ressources) : budget plus de 75% et deux liaison officers par État membre. (Source)

Le “single-entry point” de reporting est mentionné comme une initiative du Digital Omnibus, que le package vient compléter. (Source)


Audit NIS2 : preuves attendues

  1. Classification : effectifs/CA/bilan consolidés + décision interne (et rationale).
  2. Art. 21 : méthode risques → contrôles → preuves, avec revues périodiques.
  3. Gouvernance : PV, responsabilités, formation/implication direction.
  4. Incident : playbooks, horodatage, capacité à produire early warning/notifications selon le cadre applicable. (Source)
  5. IAM/MFA & privilèges : politiques, couverture MFA, gestion comptes à privilèges.
  6. Logs/monitoring : sources, rétention, corrélation, preuves d’investigation.
  7. Tiers : clauses, évaluations, suivi remédiation.

Evidence Pack checklist (minimum viable)

DomaineÉléments requis
ClassificationEffectifs/CA/bilan consolidés + décision interne documentée
PérimètreInventaire AWS/Azure/M365 + actifs critiques + dépendances
Art. 21Méthode risques + registre + revues périodiques
Contrôles clésIAM/MFA + comptes à privilèges + vuln/patch + sauvegardes + segmentation
Logs/monitoringSources + rétention + preuves d’investigation
IncidentPlaybooks + timeline + pièces justificatives + décisionnel
TiersClauses + évaluations + suivi remédiation

Plan d’action 30 jours

  1. Dossier classification : consolider effectifs/CA/bilan + décision interne.
  2. Evidence Pack Article 21 : risques → contrôles → preuves (multi-cloud).
  3. Incident/ransomware : capacité à documenter détection, vecteur, atténuation, timeline et décisions.
  4. Centralisation des preuves : éviter les silos AWS/Azure/M365.
  5. Tiers critiques : clauses + preuves de suivi.

Visualiser la chaîne de preuves

Concept : pipeline de preuves NIS2

┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   SOURCES   │ →  │  CONTRÔLES  │ →  │  FINDINGS   │ →  │  RAPPORTS   │
│ AWS/Azure/  │    │ Politiques  │    │ Écarts      │    │ Evidence    │
│ M365/On-prem│    │ IAM/MFA     │    │ Conformité  │    │ Pack Audit  │
│ Logs/Config │    │ Monitoring  │    │ Risques     │    │ Timeline IR │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘

Ce pipeline peut gagner à être automatisé et auditable pour réduire la charge d’audit.


Conclusion

Le paquet cybersécurité du 20 janvier 2026 n’est pas encore du droit applicable, mais il indique une direction possible (classification, supervision, ransomware reporting, rôle ENISA) sous réserve du texte final et des transpositions. (Source)

Le meilleur move “no-regret” reste le même : verrouiller la classification et maintenir un Evidence Pack exploitable, surtout en multi-cloud.

Si vous souhaitez réduire la charge d’audit et industrialiser la collecte de preuves multi-cloud, découvrez Legili — automatisation de la détection des écarts et génération de rapports conformes.

Cet article est fourni à titre informatif et ne constitue pas un conseil juridique.

Lire aussi