NIS2 Role-Based Security Training: CIR 8.2.2 Requires ‘Criteria’ but Never Names Them — 6 Tests for Helpdesk, Finance, OT and Developers

Short answer: under NIS2’s binding technical rules, a role is “security-relevant” if your own written criteria say it is. Point 8.2.2 of the Annex to Commission Implementing Regulation (EU) 2024/2690 requires a training programme that “lays down the training needs for certain roles and positions based on criteria”. It never says what the criteria are. Published guides fill the gap with lists of departments; none of those we reviewed explains how the list was drawn up.

Below are six criteria tests, each tied to a clause the regulation already contains, and a training-needs matrix for the four roles that most often fall through the gap: helpdesk, finance, operational technology (OT) and developers. The same register also covers role transfers, the annual review of role assignments and background verification.

Does point 8.2 apply to you? Scope first

In plain terms: every NIS2 entity must train staff (see our overview of NIS2 training requirements), but only eleven types of digital-sector entity are bound by the wording of point 8.2. For everyone else it is a benchmark, not the legal test.

Your organisation	Binding training rule	Role of CIR point 8.2
DNS service provider, TLD registry, cloud, data centre, CDN, managed service provider, managed security service provider, online marketplace, search engine, social network, trust service provider	Article 21(2)(g) of the Directive, specified by the CIR Annex (Article 1 of the CIR)	Binding text. Point 8.2 is what your supervisor checks against.
Any other essential or important entity	Your national law transposing Article 21(2)(g)	Not binding on you, but it is the most detailed EU-level description of what “cybersecurity training” means, which makes it a sensible benchmark.
Members of the management body (every entity)	Article 20(2) of the NIS2 Directive: they “are required to follow training”	Separate duty. Point 10.1.2(c) adds mechanisms so management understands its role.

What point 8.2 requires, and the one word it leaves blank

In plain terms: decide which roles need security skills, write down why, train those people on their own systems and threats, check it worked, and repeat when people move or threats change. Point 8.2 contains no “where appropriate” escape clause, so none of this is optional for an entity bound by the CIR.

Point	What it requires	What it leaves to you
8.2.1	Identify employees “whose roles require security relevant skill sets and expertise” and give them “regular training”	Which roles, and what “regular” means
8.2.2	A training programme, in line with your security policy and topic-specific policies, that lays down training needs “for certain roles and positions based on criteria”	The criteria themselves
8.2.3	Training relevant to the job function, effectiveness “shall be assessed”, covering (a) secure configuration and operation of systems including mobile devices, (b) known cyber threats, (c) behaviour when security-relevant events occur	The assessment method
8.2.4	Training for staff who transfer into roles needing security skills	The trigger that spots the transfer
8.2.5	Programme updated and run periodically, taking account of assigned roles, known threats and technological developments	The interval

By our count the word “criteria” appears eight times in the Annex. In point 5.1.2, supplier-selection criteria come with a list of what they “shall include”. In point 10.2.2(a), the criteria have a defined job: to “set out which roles, responsibilities and authorities shall only be exercised by persons whose background has been verified”. Point 8.2.2 gives neither. You write both.

ENISA’s Technical Implementation Guidance (June 2025, non-binding) narrows it only slightly. Its 8.2.2 examples name secure system administration courses for IT professionals, OWASP training for web developers and “advanced social engineering awareness training for high-profile roles”. For security specialists, ENISA points to the European Cybersecurity Skills Framework and its 12 professional role profiles. That covers your CISO and SOC analysts, not the accounts-payable clerk who can change a supplier’s bank details.

Six criteria tests that decide who is a security-relevant role

In plain terms: test what a person can do, not which department they sit in. If a role holds any of six kinds of authority, it is security-relevant.

Authorities hold up better than job titles: titles change with every reorganisation, while authorities are already recorded in your access-control and finance systems. The CIR thinks in the same terms. Point 1.2.1 makes you “lay down responsibilities and authorities” and assign them to roles, and point 10.1.2(b) speaks of users acting “in accordance with their roles, responsibilities and authorities”. US federal guidance reaches a similar answer. NIST SP 800-50r1 says role-based material should be built on “two important criteria”: the attendee’s role and the security responsibilities that role carries.

Test	Question to ask of the role	Clause it is anchored to	Roles it typically catches
T1 Privileged access	Does the role hold administrative or privileged access to any network or information system?	10.1.2(b); 11.3; 11.6.2(f)	System and cloud admins, helpdesk with admin rights, OT engineers, DevOps
T2 Identity authority	Can the role issue, reset or re-enrol passwords, MFA factors or access rights for other people?	11.6.2(b) and (d); 11.2	Helpdesk and service desk, identity admins, HR staff who trigger joiner and leaver changes
T3 Payment authority	Can the role release payments or change supplier or payee master data?	10.2.2(a), via ENISA’s “roles with financial responsibilities” example	Accounts payable, treasury, procurement, payroll
T4 Production change	Can the role change code, configuration or a pipeline that reaches production?	6.2.2(b) secure coding principles; 6.3 configuration management	Developers, DevOps and platform engineers, network engineers
T5 Physical-process control	Can the role change how a physical process, safety system or plant behaves?	8.2.3(a) secure operation of your systems; NIST SP 800-82r3 (reference)	Control engineers, operators, maintainers, OT integrators
T6 High-profile exposure	Is the person a likely impersonation or pretexting target because of seniority or public visibility?	ENISA 8.2.2 guidance; 10.1.2(c) for management	Executives, their assistants, spokespeople, investor relations

A role that triggers no test gets the general awareness and cyber hygiene programme under point 8.1. A role that triggers any test joins the 8.2.1 population, with one module per test. Incident-response roles usually trigger T1 or T2 anyway; ENISA’s 8.2.3 guidance adds crisis-management training with simulated events.

Two anchors are interpretive, so label them that way in your criteria document. T3 borrows the “financial responsibilities” example from ENISA’s background-verification guidance, not from point 8.2. T5 rests on the general wording of 8.2.3(a) plus NIST’s OT guide, because the CIR never mentions OT. The other four point to binding text.

The training-needs matrix: helpdesk, finance, OT and developers

In plain terms: point 8.2.3 fixes three content headings. Fill each with the role’s own systems and threats, and test behaviour, not course completion.

Role	Tests	8.2.3(a) Secure configuration and operation	8.2.3(b) Known threats	8.2.3(c) Behaviour during events	Effectiveness check (8.2.3)
Helpdesk / service desk	T1, T2	Identity-verification procedure for resets and MFA re-enrolment; use of separate admin credentials	Callers posing as employees to get passwords reset or MFA moved	Refuse, call back on a number from the directory, raise a ticket to security	Sample reset tickets for the verification step; scripted test calls
Finance (AP, treasury, payroll)	T3 (often T6)	Payee-change workflow, dual approval, out-of-band confirmation	Business email compromise, invoice redirection, executive impersonation	Freeze the payment, verify through a known contact, report to security	Sample payee changes for the call-back record; scenario exercise
OT engineers and operators	T1, T5	Remote-access and vendor-connection rules; when and how to disconnect from external networks	Threats relevant to your control systems and vendors	Recognise anomalous process behaviour, escalation path, safe-state decisions	Tabletop or walkthrough of the disconnect procedure
Developers / DevOps	T1, T4	Your secure coding standard, secrets handling, pipeline and configuration rules	Web application weakness classes, dependency and pipeline attacks	Reporting a suspected leaked secret or compromised dependency	Trend of security findings in code review; lab exercise scores

Helpdesk: the role attackers ask to reset an MFA factor

The helpdesk can change who is able to log in as whom. In advisory AA23-320A, CISA and the FBI describe Scattered Spider first calling to learn “what steps are needed to conduct password resets from helpdesks”, then calling again to convince staff “to reset passwords and/or transfer MFA tokens”, which led to account takeover in single sign-on environments. The group also targets contracted help desks, so an outsourced desk’s training belongs in the contract under point 5.1.4(b) (“requirements regarding awareness, skills and training”, where appropriate). Desk admin rights fall under the CIR 11.3 privileged-account rules.

Finance: authority over money, not over systems

Finance staff rarely hold privileged access, so IT-led criteria miss them. The FBI’s 2024 IC3 report recorded $2.77 billion in business email compromise losses from 21,442 complaints, and defines the scam as targeting businesses that regularly make wire transfers. Those are US complaints, but the method doesn’t depend on geography. An attack that leads to a fraudulent payment can also raise NIS2 reporting questions, covered in our guide to when BEC becomes a significant incident.

OT: training on the physical process, not only the network

The CIR never mentions OT, so this row relies on point 8.2.3(a) and NIST SP 800-82r3. NIST tells organisations to “identify, document, and train all personnel who have significant OT roles and responsibilities”. It adds that training “should cover the physical process being controlled as well as the OT system”, including when and how to connect to and disconnect from external security domains. Its role list includes control engineers, operators, maintainers and third-party providers. Our IEC 62443 mapping shows how the OT standard lines up with Article 21.

Developers: the one row the CIR names a principle for

Point 6.2.2(b) requires you to “apply principles for engineering secure systems and secure coding principles” to development activity. Developers can only apply principles they have been taught, so T4 is the easiest test to defend. NIST’s Secure Software Development Framework practice PO.2.2 gives a model: “provide role-based training for all personnel with responsibilities that contribute to secure development”, periodically review proficiency, and create a training plan for each role. For the pipeline side, see NIS2 and DevSecOps.

One criteria register, four clauses: transfers, annual review, admins and background checks

In plain terms: keep the six tests in one register that HR and IT both use, run it when someone joins, moves or gains access, and review it yearly. That one record supports four clauses.

• 8.2.4 transfers. When someone moves role, rerun the six tests; each newly triggered test creates a training need. NIST SP 800-50r1’s sample policy requires role-based training before access to systems that process sensitive information, a sensible default for T1 and T2 that the CIR doesn’t mandate.
• 10.1.3 annual review. The CIR requires you to review “the assignment of personnel to specific roles”, meaning the roles under point 1.2, “at planned intervals and at least annually”. By our count it is one of only three “at least annually” duties in the Annex, and it applies to the role list, not the training. If the register is your role list, one review covers both.
• 10.1.2(b) admin awareness. You need mechanisms to ensure users with administrative or privileged access act within their roles and authorities. A T1 module with a signed acknowledgement can serve as one; ENISA suggests “specialised training” for these users.
• 10.2.2(a) background verification. You need criteria for which roles require a verified background: add one column to the same register. ENISA’s indicative list for this clause (executives, sensitive-information access, financial responsibilities, procurement, physical security) overlaps heavily with T3 and T6.

Step	Owner	Effort	Output
Write and approve the six criteria	CISO, approved alongside the security policy	Low	Criteria section in the training programme
Run the tests against every role	HR with IT, finance and OT leads	Medium	Role register with tests triggered
Build modules per test	CISO plus the system owners	Medium to high	Module content for 8.2.3(a)–(c)
Wire the transfer trigger	HR	Low	Role change in the HR system creates a training task
Annual role review and effectiveness results	CISO, reported to management	Low	Dated review record

Article 2(2) of the CIR lets you scale depth to your size and exposure, but because point 8.2 has no “where appropriate” wording, it doesn’t let you skip the criteria. The training policy template guide shows where the register sits within the policy document.

What to show an auditor

In plain terms: show the reasoning, the list it produced, and proof the training changed behaviour.

• The criteria, dated and approved, with T3 and T5 marked as interpretation
• The role register: each role, tests triggered, current holders. ENISA lists a “list of employees whose roles require specific security skills and their assignment to roles” as example evidence under point 10.1.1
• The programme outline per role: objectives, content and frequency (ENISA’s example evidence for 8.2.1–8.2.3)
• Attendance and completion records per person, including transfers (8.2.4)
• Effectiveness results per role, not just completion rates
• The dated 10.1.3 review and the 8.2.5 programme update, with the threat changes that triggered it

A training platform covers attendance and delivery; the criteria and the register are documents you write yourself, as our training platform vs template comparison explains. The training audit checklist turns this list into controls you can test.

Frequently asked questions

What is role-based security training under NIS2?

It is the specialist training in CIR 2024/2690 point 8.2, separate from general awareness under point 8.1: identify roles needing security skills, set their training needs “based on criteria”, and assess whether the training works.

Does NIS2 say which roles need role-based training?

No. Point 8.2.2 requires criteria but doesn’t define them. ENISA’s guidance gives examples (IT professionals, web developers, high-profile roles), and point 10.1.2(b) requires mechanisms for users with privileged access. The rest of the list is yours to justify in writing.

Is annual role-based training mandatory?

The CIR says “regular” (8.2.1) and “periodically” (8.2.5), not annually. ENISA recommends reviewing the programme at least annually. The binding annual duty is in 10.1.3: reviewing the assignment of people to roles. Our guide to how often NIS2 training must run covers the interval question in depth.

Do contractors and outsourced helpdesks count?

The 8.2 duty covers your employees. For suppliers, point 5.1.4(b) asks you to set awareness, skills and training requirements in contracts, where appropriate. An outsourced desk that resets your users’ MFA triggers T2, so write its training into the contract.

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

1. European Commission. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — Articles 1–2 and Annex points 1.2, 5.1.2, 5.1.4, 6.2.2, 6.3, 8.1–8.2, 10.1–10.2, 11.3, 11.6. EUR-Lex, OJ L, 18.10.2024.
2. European Parliament and Council. Directive (EU) 2022/2555 (NIS 2 Directive) — Articles 20 and 21. EUR-Lex, OJ L 333, 27.12.2022.
3. ENISA. Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0. June 2025.
4. ENISA. European Cybersecurity Skills Framework (ECSF).
5. CISA and FBI. Cybersecurity Advisory AA23-320A: Scattered Spider (updated 29 July 2025).
6. FBI Internet Crime Complaint Center. 2024 IC3 Annual Report.
7. NIST. SP 800-82r3, Guide to Operational Technology (OT) Security. September 2023.
8. NIST. SP 800-218, Secure Software Development Framework (SSDF) Version 1.1. February 2022.
9. NIST. SP 800-50r1, Building a Cybersecurity and Privacy Learning Program. September 2024.