---
name: "Registre de formation NIS2 de l'organe de direction"
version: "1.0"
updated: "2026-07-21"
source: "https://www.orbiqhq.com/templates/nis2-management-training-log"
license: "Libre d'utilisation et d'adaptation au sein de votre organisation. Attribution appréciée. Ne constitue pas un conseil juridique."
legal_basis:
  - "https://eur-lex.europa.eu/eli/dir/2022/2555/oj"   # Directive NIS2 — art. 20(1), 20(2), 21(2)(g)
---

# Registre de formation NIS2 de l'organe de direction (lisible par machine)

Objet : tenir le registre auditable des formations cybersécurité que l'article 20,
paragraphe 2, de la directive NIS2 impose aux organes de direction des entités essentielles
et importantes — qui siège à l'organe de direction, quelle formation chaque membre a suivie,
quels objectifs elle couvrait, la preuve associée et la prochaine échéance. Ce fichier est
autonome : un agent peut créer les enregistrements, calculer les échéances, exécuter les
contrôles de santé et produire un extrait d'audit à partir des seules définitions ci-dessous.

Règles structurelles :
1. UN enregistrement de registre par membre de l'organe de direction, Y COMPRIS les membres
   partis (`status` → `departed` ; ne jamais supprimer — les auditeurs comparent les
   approbations historiques à la composition historique).
2. UN enregistrement de journal par membre et par session. Une session suivie par cinq membres
   crée cinq enregistrements, chacun avec sa propre référence de preuve.
3. Ce fichier ne couvre QUE la formation au niveau de la gouvernance (article 20(2)).
   La formation du personnel est un devoir distinct (article 21(2)(g)) — suivez-la dans le
   LMS/SMSI, pas ici.
4. `next_due` est calculé, jamais saisi : `next_due = training_date +
   renewal_interval_months`. La date de conformité d'un membre est le MAXIMUM de `next_due`
   sur ses sessions accomplies.
5. L'intervalle de renouvellement est une décision de droit national, pas une préférence.
   Par défaut, règle la plus stricte applicable : Lettonie → 12 mois (formation régulière,
   contenus revus au moins annuellement — le plus souvent annuelle en pratique) ;
   Allemagne → 36 mois (repère des travaux préparatoires : ~4 h au moins tous les 3 ans,
   § 38 al. 3 BSIG) ; sinon → dériver du programme de formation de l'entité et documenter.

Notes juridictionnelles : la France n'a pas achevé sa transposition — la Commission l'a
renvoyée devant la CJUE le 8 juillet 2026 — mais le guichet MonEspaceNIS2 de l'ANSSI annonce
déjà les devoirs de l'article 20 (approbation, supervision, formation de l'organe de
direction) : constituez le registre dès maintenant. Le § 38 BSIG allemand (en vigueur depuis
le 6.12.2025, sans période transitoire) rend le devoir personnel et non délégable, avec
responsabilité personnelle en cas de manquement fautif (§ 38 al. 2, renonciation aux recours
inefficace). La Belgique (loi du 26.4.2024, art. 31 §2) impose une formation régulière, mais
le CCB ne prescrit ni prestataire, ni certificat, ni durée. La Norvège applique des devoirs
équivalents via la digitalsikkerhetsloven (1.10.2025). Le projet de loi britannique ne
contient pas d'obligation légale de formation — le Cyber Governance Code of Practice reste
volontaire.

---

## 1. Registre de l'organe de direction — un enregistrement par membre

| # | Champ | Type | Définition / règle |
|---|---|---|---|
| 1 | `member_name` | texte, unique | CLÉ PRIMAIRE — nom complet |
| 2 | `role_title` | texte | Rôle/fonction (CEO, CTO, administrateur non exécutif, …) |
| 3 | `governing_body` | enum | `management_board` / `supervisory_board` / `other_governing_organ` |
| 4 | `appointment_date` | date (ISO 8601) | Date d'entrée dans l'organe |
| 5 | `in_scope_art20` | enum : `yes` / `no_documented` | Applicabilité du devoir de l'article 20 ; le périmètre des organes de surveillance varie selon l'État membre |
| 6 | `scope_justification` | texte | Justification du périmètre — requise dans les deux cas |
| 7 | `status` | enum : `active` / `departed` | Les membres partis restent au registre |
| 8 | `latest_session` | date, calculée | MAX(`training_date`) sur les enregistrements du membre |
| 9 | `next_training_due` | date, calculée | MAX(`next_due`) sur les enregistrements du membre |
| 10 | `notes` | texte | Texte libre |

## 2. Journal des formations — un enregistrement par membre et par session

| # | Champ | Type | Définition / règle |
|---|---|---|---|
| 1 | `member_name` | texte | FK → registre |
| 2 | `role_at_training` | texte | Rôle au moment de la formation (les rôles changent ; pas les enregistrements) |
| 3 | `session_title` | texte | Intitulé de la session |
| 4 | `provider_name` | texte | Formateur ou organisme, interne ou externe |
| 5 | `provider_type` | enum | `external` / `internal` |
| 6 | `training_date` | date (ISO 8601) | Date de réalisation |
| 7 | `duration_hours` | nombre | Heures de contact — les autorités attendent la durée par enregistrement |
| 8 | `format` | enum | `classroom` / `virtual_live` / `e_learning` / `tabletop_exercise` / `board_briefing` / `conference` |
| 9 | `objectives_covered` | liste, non vide | Sous-ensemble des trois objectifs de l'art. 20(2) : `identify_risks`, `assess_practices`, `impact_on_services` |
| 10 | `renewal_interval_months` | entier | Selon la règle structurelle 5 |
| 11 | `next_due` | date, calculée | `training_date + renewal_interval_months` |
| 12 | `evidence_ref` | texte, requis si `completed` | ID de certificat, feuille de présence signée, export LMS — avec emplacement d'archivage |
| 13 | `completion_status` | enum | `completed` / `scheduled` / `no_show_reschedule` |
| 14 | `notes` | texte | Texte libre |

## 3. Catalogue des sessions — le programme de formation

| # | Champ | Type | Définition / règle |
|---|---|---|---|
| 1 | `session_id` | texte, unique | CLÉ PRIMAIRE, p. ex. `MT-01` |
| 2 | `topic` | texte | Sujet/intitulé de la session |
| 3 | `audience` | enum | `management_body` / `management_body_plus_ciso` / `supervisory_board` / `all_staff_art21_2g` (ce dernier : suivre la réalisation dans le LMS, pas ici) |
| 4 | `objectives` | liste | Objectifs de l'art. 20(2) visés |
| 5 | `planned_date` | date | Prochaine réalisation prévue |
| 6 | `frequency` | texte | p. ex. `every_12_months`, `every_36_months` |
| 7 | `delivery_method` | enum | même enum que `format` du journal |
| 8 | `provider` | texte | Prestataire prévu |
| 9 | `effectiveness_measure` | texte | Comment la compréhension est démontrée (discussion actée, rapport d'exercice, évaluation) |
| 10 | `status` | enum | `planned` / `scheduled` / `delivered` / `cancelled` |

## 4. Règles de travail pour agents

Enregistrer une session accomplie :
1. Vérifier que le membre figure au registre avec `status: active` ; sinon créer d'abord
   l'enregistrement de registre (avec justification du périmètre).
2. Créer un enregistrement de journal par participant avec `completion_status: completed`,
   une liste `objectives_covered` non vide et une `evidence_ref` pointant vers un artefact
   archivé.
3. Recalculer `latest_session` et `next_training_due` du membre.

Contrôles de santé (avant tout audit ou trimestriellement) :
- COUVERTURE : chaque enregistrement de registre avec `status: active` et
  `in_scope_art20: yes` possède au moins un enregistrement `completed` avec `next_due` dans le
  futur. Tout manquement est un constat — signaler membre, dernière session, jours de retard.
- INTÉGRATION : membres avec `appointment_date` dans les 6 derniers mois et zéro session
  accomplie → planifier la formation de gouvernance initiale.
- PREUVE : chaque enregistrement `completed` a une `evidence_ref` non vide. Un certificat
  introuvable sur demande n'existe pas, du point de vue d'un audit.
- OBJECTIFS : sur les sessions valides de chaque membre, l'union des `objectives_covered`
  doit couvrir les trois objectifs de l'art. 20(2) ; signaler les couvertures partielles.
- DÉRIVE DE PÉRIMÈTRE : enregistrements avec `in_scope_art20: no_documented` et
  `scope_justification` vide → enregistrement invalide.

Extrait d'audit (ce qu'une autorité demande) : pour chaque membre actif dans le périmètre —
nom, rôle, dernière session (intitulé, prestataire, date, heures, objectifs), référence de
preuve, prochaine échéance ; plus le Catalogue des sessions comme document programme.

## 5. Modèles Orbiq associés

- `nis2-supplier-evidence-request-checklist.md` — preuves chaîne d'approvisionnement, art. 21(2)(d)
- `nis2-incident-reporting-pack.md` — les formulaires de signalement de l'art. 23 (24h/72h/1 mois)
- `nis2-compliance-checklist-article-21.md` — la checklist complète des mesures de l'art. 21