NIS2 Training Policy Template: The 5 Fields Auditors Check (Plus a 12-Month Calendar)

Most NIS2 gap analyses mark “Article 21(2)(g) — training” complete the moment a company runs one all-staff phishing simulation and calls it done. That’s a training program, not a policy. A supervisory authority reviewing your file wants a dated document that states five specific things — and if you’re building this from scratch, a calendar and a role matrix that turn those five things into evidence you can point to on the day of an inspection, rather than assembling on the morning of one. This guide covers exactly that: the fields, the calendar, and the matrix a NIS2 Training and Awareness Policy needs to hold up as audit evidence, not just as good intentions written down.

A Training Program Isn’t a Training Policy — Here’s the Difference Auditors Care About

Running phishing simulations and onboarding sessions proves you deliver training. It doesn’t prove you have a policy. Under NIS2, those are two separate audit questions, and conflating them is one of the more common reasons a Training and Awareness Policy gets sent back for revision.

Article 21(2)(g) of the NIS2 Directive requires essential and important entities to implement “basic cyber hygiene practices and cybersecurity training” as one of ten mandatory risk-management measures. That’s the legal obligation to train. A separate, written policy — the document stating who gets trained, how often, through what method, and how you prove it happened — is the evidence that the obligation is managed, not improvised. Germany’s BSI, the national competent authority under the country’s NIS2 transposition law, makes this explicit: “documentation of the implementation of measures is a necessary condition” for meeting the Act’s requirements. A verbal commitment to “do awareness training every year” doesn’t survive an audit; a dated, version-controlled policy document does.

The distinction matters for scope, too. Article 21(2)(g) covers staff generally. Article 20(2) imposes a separate, non-delegable obligation: management body members must personally complete training that lets them “identify risks and assess cybersecurity risk-management practices and their impact on the services provided by the entity.” Because board members can be held personally liable for the entity’s infringements under Article 20(1), a policy that lumps staff training and board training into one undifferentiated paragraph is already missing its first mandatory field — more on that in the board-specific training obligations guide.

This article covers what the policy document itself must state — the five mandatory fields, a 12-month calendar structure you can adapt, and a role-specific matrix — rather than the underlying legal requirements, which we cover in full in our training requirements guide.

The 5 Fields Every NIS2 Training Policy Must State

A NIS2 Training and Awareness Policy earns its place as audit evidence only when it commits to five specific things in writing. Skip one, and the document reads as a summary of the law rather than an operational policy your organisation actually follows.

1. Scope — Management vs Staff. State both obligations separately, with their own legal basis. Board and executive-committee training exists to satisfy Article 20(2) and is personal and non-delegable — it cannot be satisfied by sending a CISO in a board member’s place. General staff training, covering everyone including contractors and temporary workers with system access, satisfies Article 21(2)(g) and Commission Implementing Regulation (CIR) 2024/2690‘s requirement for a security awareness programme covering “all personnel.” One accuracy note: CIR 2024/2690 formally binds specific digital-infrastructure and service-provider entity types directly; for other essential and important entities, its training-tier structure functions as a widely used implementation benchmark rather than a direct statutory mandate — worth writing the policy to that benchmark regardless, since auditors reference it either way.

2. Training Frequency. Article 21(1) sets a proportionality standard: measures — including how often you train — must match “the degree of the entity’s exposure to risks, the entity’s size and the likelihood of occurrence of incidents.” The Directive doesn’t fix a number of sessions per year. What CIR 2024/2690’s training section does require is that training happen at induction and at planned intervals thereafter — a one-time induction alone fails this test. BSI’s practical guidance for German entities is induction plus an annual refresh on current developments, reinforced with ongoing awareness measures such as posters or campaigns between formal sessions. Write frequency as a concrete cadence in the policy (“within 30 days of start date, then annually, with quarterly phishing simulations for all staff”) rather than “regularly” — a vague frequency field is functionally the same as no frequency field to an auditor checking evidence against a stated commitment.

3. Delivery Methods. List every channel you actually use: e-learning modules, instructor-led workshops, tabletop exercises, phishing simulations, and threat briefings are the standard mix. Simulated phishing campaigns aren’t named explicitly anywhere in the Directive or CIR text, but in practice they’ve become the evidence competent authorities expect for measuring the cyber-hygiene half of Article 21(2)(g) — list them in the policy if you run them, since undocumented evidence doesn’t count as evidence.

4. Assessment Requirement. CIR 2024/2690 requires organisations to assess training effectiveness, not just log attendance. A policy field that only says “training will be provided” fails this. State the assessment mechanism per audience: a post-training quiz with a minimum pass threshold for general staff, phishing-simulation click-and-report rates tracked over time, and a documented debrief for board-level tabletop exercises. Attendance sign-off proves someone showed up; assessment proves the training worked.

5. Record Retention Period. Neither the Directive nor CIR 2024/2690 sets an explicit retention period for training records — this is the field most templates leave blank or borrow language for from an unrelated data-retention policy. BSI is unambiguous that documentation is “a necessary condition” for compliance, which means the retention period has to be long enough to survive between supervisory inspections. In practice, compliance teams commonly retain general staff training records for a minimum of three years — roughly one national audit cycle — and retain management-body training records for the duration of each board member’s tenure plus a reasonable buffer, given the personal liability exposure under Article 20(1). Check your national competent authority’s specific guidance before finalising a shorter period.

A 12-Month Training Calendar Template You Can Adapt

A policy that states “training happens annually, with quarterly refreshers” is only as credible as the calendar behind it. Building the calendar into the policy as a dated annex — rather than leaving it as an undated intention — is what turns the frequency field above into something an auditor can check against actual dates.

The structure below follows the induction-plus-planned-intervals pattern from CIR 2024/2690 and BSI’s induction-plus-annual-refresh recommendation, scaled to a typical mid-sized entity. Adjust the cadence to your own risk profile per the Article 21(1) proportionality standard — a critical infrastructure operator with high staff turnover needs tighter cycles than a low-risk service provider.

Month	Activity	Audience	Format	Owner
Jan	New-joiner induction (Dec/Jan starters)	All new staff	E-learning + quiz	HR + IT Security
Feb	Board/management annual training session	Management body	Instructor-led workshop	CISO / external trainer
Mar	Q1 phishing simulation	All staff	Simulated phishing campaign	IT Security
Apr	New-joiner induction	All new staff	E-learning + quiz	HR + IT Security
May	Role-specific refresher	High-risk / privileged roles	Workshop + hands-on lab	CISO
Jun	Q2 phishing simulation	All staff	Simulated phishing campaign	IT Security
Jul	New-joiner induction	All new staff	E-learning + quiz	HR + IT Security
Aug	Mid-year effectiveness review (scores, click-rates)	Compliance / CISO	Internal review — no delivery	Compliance Officer
Sep	Q3 phishing simulation	All staff	Simulated phishing campaign	IT Security
Oct	New-joiner induction	All new staff	E-learning + quiz	HR + IT Security
Nov	Annual comprehensive refresher	All staff	E-learning + tabletop for high-risk roles	HR + IT Security
Dec	Q4 phishing simulation + annual policy review/sign-off	All staff + Compliance	Simulated phishing + document review	IT Security + Compliance Officer

Two rows do double duty as audit evidence. The August mid-year review turns the assessment-requirement field into a scheduled event rather than an afterthought, and the December policy review closes the loop by forcing an annual look at whether the calendar itself still matches current risk. Skip either one and the policy risks becoming the kind of document that’s accurate on the day it’s signed and wrong for the other eleven months.

Role-Specific Training Matrix

Frequency and delivery method aren’t uniform across an organisation, and a policy that treats a board member and a warehouse temp identically hasn’t actually engaged with the proportionality standard in Article 21(1). The matrix below separates four role categories that map to genuinely different legal bases and risk exposure.

Role	Legal Basis	Frequency	Delivery Method	Assessment
Board / Management Body	Article 20(2) — personal, non-delegable	Annual, minimum	Instructor-led workshop or briefing	Documented debrief; per-individual sign-off
IT & Security Staff (privileged access)	Art. 21(2)(g) + CIR role-specific tier	Annual + ad hoc on new threats	Workshop, hands-on lab, tabletop exercise	Scenario-based test; incident-response drill performance
General Staff (incl. contractors with system access)	Art. 21(2)(g) + CIR universal tier	Induction + annual refresher	E-learning + phishing simulation	Quiz pass threshold; phishing click/report rate
High-Risk Roles (finance/procurement, IT admins, HR handling personal data)	Art. 21(2)(g), heightened by role exposure	Induction + annual + role-specific top-up	Targeted e-learning + role-specific fraud/phishing scenarios	Role-specific scenario testing; documented sign-off

The “high-risk roles” row is the one most templates skip entirely, and it’s the row auditors increasingly probe first — a general staff phishing pass rate says little about whether the finance team can spot a business-email-compromise attempt aimed at a wire transfer specifically. Naming these roles explicitly in the policy, rather than leaving everyone above “general staff” undifferentiated, is what turns “basic cyber hygiene practices” from a phrase in the Directive into an operational control your organisation can point to. For the board row specifically, see the full breakdown of what management-body training must cover in our board training requirements guide.

Structuring the Policy Document Itself

The five fields and two tables above are the content. The document wrapping them needs its own structure to be treated as a governance artifact rather than a memo. If you’ve already built an Information Security Policy for your ISMS, use the same skeleton — our guide to writing that policy uses an eight-section structure that a Training and Awareness Policy should mirror:

1. Purpose and scope statement — which entity type (essential/important) and which roles the policy covers.
2. Roles and responsibilities — who owns delivery (HR, IT Security, external trainer), who owns assessment and record-keeping (Compliance Officer), and who approves the policy (management body).
3. Policy statements — the five mandatory fields above, written as commitments (“all staff shall complete…”) rather than descriptions.
4. Training calendar — the 12-month structure, as an annex so it can be updated yearly without re-approving the whole policy.
5. Role-specific matrix — the four-role table, also as an annex.
6. Non-compliance and escalation — what happens when someone misses mandatory training (access restriction, escalation to manager, repeat-offender procedure).
7. Review and version control — annual review minimum, version history table, change log.
8. Approval and sign-off — dated signature from the management body, satisfying the same Article 20 accountability that makes board training mandatory in the first place.

Building this from a blank page usually takes longer than the training program it describes. The Complete Toolkit’s Initial Training Plan starts from this exact structure with role-specific modules already mapped to the matrix above, plus a Training Tracker spreadsheet for the record-retention field — faster than assembling the same skeleton from six different source documents.

What Auditors Actually Check When They Review This Policy

A competent authority reviewing your Training and Awareness Policy isn’t reading it for style. It’s checking whether the document’s stated commitments match the evidence in your Training Tracker: does the frequency field say “annual” while the tracker shows a 14-month gap somewhere? Does the scope field mention contractors, and does the tracker have contractor rows at all? Non-compliance with Article 21 training obligations sits inside the same enforcement regime that allows fines up to €10 million or 2% of global annual turnover for essential entities — the policy document is what a supervisory review reaches for first, precisely because it’s faster to check a document against a tracker than to interview every employee. Put together, the five fields, the calendar, and the matrix turn a one-paragraph training commitment into the kind of policy an authority can actually verify — because every claim it makes points to a place where the evidence lives. For the full ten-measure picture Article 21 sits inside, see our complete Article 21 breakdown.

FAQ

Do we need separate documents for board and staff training?
Not necessarily separate documents — a single policy with clearly separated scope fields (see Field 1 above) satisfies both obligations, provided the board section reflects Article 20(2)’s personal, non-delegable nature rather than being folded into general staff language.

How often does the policy document itself need review, separate from the training calendar?
Annual review is the practical minimum most compliance teams use, timed to coincide with the calendar’s own year-end review point, even in years when no individual training frequency changes.

Does e-learning alone satisfy the requirement?
It can satisfy the delivery-method field for general staff, but CIR 2024/2690’s role-specific tier expects a different, more hands-on method for staff with security tasks and for management — an all-e-learning policy for every role is a common reason a Delivery Methods field gets flagged.

Do contractors and temporary staff belong in scope?
Yes, for general staff training — CIR 2024/2690’s awareness-programme requirement covers “all personnel” with system access, not just permanent employees. Leaving contractors out of the scope field is one of the more common gaps found in practice.

What happens if we can’t prove training took place?
Undocumented training is, from an audit perspective, indistinguishable from training that didn’t happen. This is why BSI treats documentation as “a necessary condition” for compliance, not a nice-to-have — the record-retention field exists precisely so a Training Tracker can answer this question before an auditor asks it.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• NIS 2 Directive, Article 21: Cybersecurity risk-management measures — nis-2-directive.com (mirror of Directive (EU) 2022/2555)
• NIS 2 Directive, Article 20: Governance — nis-2-directive.com
• BSI (Bundesamt für Sicherheit in der Informationstechnik) — #nis2know: Grundlegende Schulungen und Sensibilisierungsmaßnahmen
• nisd2.eu — CIR 2024/2690: NIS2 Technical Measures (Annex Section 8 summary)