---
name: "NIS2 Management Training Log"
version: "1.0"
updated: "2026-07-21"
source: "https://www.orbiqhq.com/templates/nis2-management-training-log"
license: "Free to use and adapt within your organisation. Attribution appreciated. Not legal advice."
legal_basis:
  - "https://eur-lex.europa.eu/eli/dir/2022/2555/oj"   # NIS2 Directive — Art. 20(1), 20(2), 21(2)(g)
  - "https://www.recht.bund.de/bgbl"                    # DE: BSIG (NIS2UmsuCG) § 38 Abs. 2–3, BGBl. 2025 I Nr. 301
---

# NIS2 Management Training Log (machine-readable)

Purpose: maintain the auditable record of management-body cybersecurity training that NIS2
Article 20(2) requires — who sits on the management body of an essential or important entity,
which governance-level training each member completed, what it covered against the Article 20(2)
objectives, the evidence for it, and when it is next due. This file is self-contained: an agent
can create register and log records, compute due dates, run the health checks and produce an
audit extract from the definitions below.

Structural rules:
1. ONE register record per management-body member, INCLUDING departed members (flip `status`
   to `departed`; never delete — auditors sample historical approvals against historical
   membership).
2. ONE training-log record per member per session. A session attended by five members creates
   five log records, each with its own evidence reference.
3. This log covers GOVERNANCE-level training under Article 20(2) only. Staff awareness training
   is a separate duty (Article 21(2)(g)) — track it in the LMS/ISMS, not here. A record whose
   audience is general staff does not belong in this file.
4. `next_due` is computed, never hand-set: `next_due = training_date + renewal_interval_months`.
   A member's compliance date is the MAX of `next_due` across their completed sessions.
5. The renewal interval is a national-law decision, not a preference. Defaults by strictest
   applicable rule: Latvia → 12 months (regular training with content reviewed at least
   annually — commonly implemented as annual); Germany → 36 months (explanatory-materials
   benchmark ~4 h at least every 3 years, § 38 Abs. 3 BSIG); otherwise → set from the
   entity's own training programme and document why.

Jurisdiction notes: Germany's § 38 BSIG (in force 6 Dec 2025, no transition period) makes the
duty personal and non-delegable, with personal liability for culpable breaches under § 38 Abs. 2
(recourse waivers invalid). Czechia (Act No. 264/2025 Coll., in force 1 Nov 2025)
requires governing bodies to oversee cybersecurity and be properly trained — keep documented
evidence (agenda, date, trainer, attendance). Belgium (law of 26 Apr 2024, Art 31 §2)
requires regular training but the CCB prescribes no provider, certificate or duration. Norway
applies equivalent duties via digitalsikkerhetsloven (in force 1 Oct 2025) even though NIS2 is
not yet incorporated into the EEA Agreement. The UK Cyber Security and Resilience Bill contains
no statutory training duty — board expectations ride on the voluntary Cyber Governance Code of
Practice.

---

## 1. Management Body Register — one record per member

| # | Field | Type | Definition / rule |
|---|---|---|---|
| 1 | `member_name` | text, unique | PRIMARY KEY — full name |
| 2 | `role_title` | text | Role/title (CEO, CTO, non-executive director, …) |
| 3 | `governing_body` | enum | `management_board` / `supervisory_board` / `other_governing_organ` |
| 4 | `appointment_date` | date (ISO 8601) | When the member joined the body |
| 5 | `in_scope_art20` | enum: `yes` / `no_documented` | Whether the Article 20 duty applies; supervisory-organ scope varies by member state |
| 6 | `scope_justification` | text | Why in/out of scope — required in both cases |
| 7 | `status` | enum: `active` / `departed` | Departed members stay on the register |
| 8 | `latest_session` | date, computed | MAX(`training_date`) over this member's log records |
| 9 | `next_training_due` | date, computed | MAX(`next_due`) over this member's log records |
| 10 | `notes` | text | Free text |

## 2. Training Log — one record per member per session

| # | Field | Type | Definition / rule |
|---|---|---|---|
| 1 | `member_name` | text | FK → register |
| 2 | `role_at_training` | text | Role held when trained (roles change; records don't) |
| 3 | `session_title` | text | What the session was |
| 4 | `provider_name` | text | Trainer or organisation, internal or external |
| 5 | `provider_type` | enum | `external` / `internal` |
| 6 | `training_date` | date (ISO 8601) | Date delivered |
| 7 | `duration_hours` | number | Contact hours — supervisors expect this per record |
| 8 | `format` | enum | `classroom` / `virtual_live` / `e_learning` / `tabletop_exercise` / `board_briefing` / `conference` |
| 9 | `objectives_covered` | list, non-empty | Subset of the three Art 20(2) objectives: `identify_risks`, `assess_practices`, `impact_on_services` |
| 10 | `renewal_interval_months` | integer | Per structural rule 5 |
| 11 | `next_due` | date, computed | `training_date + renewal_interval_months` |
| 12 | `evidence_ref` | text, required for `completed` | Certificate ID, signed attendance sheet, LMS export — with storage location |
| 13 | `completion_status` | enum | `completed` / `scheduled` / `no_show_reschedule` |
| 14 | `notes` | text | Free text |

## 3. Session Catalogue — the forward training programme

| # | Field | Type | Definition / rule |
|---|---|---|---|
| 1 | `session_id` | text, unique | PRIMARY KEY, e.g. `MT-01` |
| 2 | `topic` | text | Session topic/title |
| 3 | `audience` | enum | `management_body` / `management_body_plus_ciso` / `supervisory_board` / `all_staff_art21_2g` (last one: track delivery in LMS, not here) |
| 4 | `objectives` | list | Art 20(2) objectives targeted |
| 5 | `planned_date` | date | Next planned delivery |
| 6 | `frequency` | text | e.g. `every_12_months`, `every_36_months` |
| 7 | `delivery_method` | enum | same enum as Training Log `format` |
| 8 | `provider` | text | Planned provider |
| 9 | `effectiveness_measure` | text | How understanding is evidenced (minuted discussion, tabletop report, assessment) |
| 10 | `status` | enum | `planned` / `scheduled` / `delivered` / `cancelled` |

## 4. Agent workflow rules

Adding a completed session:
1. Verify the member exists on the register with `status: active`; if not, create the register
   record first (with scope justification).
2. Create one Training Log record per attendee with `completion_status: completed`,
   a non-empty `objectives_covered` list and an `evidence_ref` pointing at a stored artefact.
3. Recompute the member's `latest_session` and `next_training_due`.

Log health checks (run before any audit or quarterly):
- COVERAGE: every register record with `status: active` and `in_scope_art20: yes` has at least
  one log record with `completion_status: completed` and `next_due` in the future.
  Any miss is a finding — report member, last session, days overdue.
- ONBOARDING: members with `appointment_date` in the last 6 months and zero completed sessions
  → schedule initial governance training.
- EVIDENCE: every `completed` record has a non-empty `evidence_ref`. A certificate that cannot
  be produced does not exist, as far as an audit is concerned.
- OBJECTIVES: across each member's in-date completed sessions, the union of `objectives_covered`
  should equal all three Art 20(2) objectives; flag members with partial coverage.
- SCOPE DRIFT: register members with `in_scope_art20: no_documented` and an empty
  `scope_justification` → invalid record.

Audit extract (what a supervisor asks for): for each in-scope active member — name, role,
latest session (title, provider, date, hours, objectives), evidence reference, next due date;
plus the Session Catalogue as the programme document.

## 5. Related Orbiq templates

- `nis2-supplier-evidence-request-checklist.md` — Article 21(2)(d) supply-chain evidence
- `nis2-incident-reporting-pack.md` — the Article 23 24h/72h/1-month reporting forms
- `nis2-compliance-checklist-article-21.md` — the full Article 21 measure checklist