Insider Threat Under NIS2: What CIR §10.3 and Article 21(2)(i) Require From HR — Not Just IT

Most NIS2 insider-threat guidance reads like an IT security checklist: user behaviour analytics, privileged-access monitoring, endpoint detection. That framing misses where the directive actually puts the obligation. Article 21(2)(i) of Directive (EU) 2022/2555 names “human resources security, access control policies and asset management” as one of ten mandatory risk-management measures — not a security-team side project, a named legal requirement with HR’s name on it.^[1]

Insider risk isn’t a rare, film-plot event either. Research from the Ponemon Institute and DTEX Systems puts the average annual cost of insider risk at $19.5 million per organisation in 2026, with negligent (non-malicious) insiders responsible for the largest single share — roughly $10.3 million a year across an average of 13.8 incidents.^[5] Most of that cost sits in the gap between what a security team can see technically and what only HR ever knew: who’s on a performance improvement plan, who gave notice, who was just written up for a policy breach.

Who This Actually Binds — and Who Should Build It Anyway

Two different obligations are in play here, and conflating them causes real compliance mistakes. Article 21(2)(i) applies to every essential and important entity in scope of NIS2 — it’s part of the binding minimum list every in-scope organisation must implement.^[1] Commission Implementing Regulation (EU) 2024/2690 (CIR), which is the source of the detailed sub-requirements this article walks through, has a narrower scope: it applies specifically to DNS service providers, TLD registries, cloud computing providers, data centre providers, content delivery networks, managed service and managed security service providers, and a handful of other digital-infrastructure and digital-provider categories.^[2]

If your organisation falls inside that narrower CIR scope, Section 10 and Section 11 of its Annex are directly binding technical requirements. If you don’t — a manufacturer, hospital, or energy operator, for instance — CIR doesn’t apply to you by name, but it’s still the most detailed official articulation the European Commission has published of what “human resources security” and “access control” mean in practice. Building to it is a defensible way to demonstrate the “appropriate and proportionate” standard Article 21(1) sets, even outside CIR’s formal scope.^[1] Check your entity classification against the site’s scope guide if you’re not sure which bucket you’re in.

The distinction matters in practice, not just on paper. A managed service provider (in CIR scope) that gets audited will be asked to produce the exact §10 sub-documents this article covers. A regional hospital operator (bound by Article 21(2)(i) but outside CIR’s named scope) won’t face that specific document request — but its national supervisory authority will still expect a comparably detailed HR-security policy, because “appropriate and proportionate” under Article 21(1) is measured against the state of the art, and CIR is now the closest thing the EU has to a published state-of-the-art baseline for this measure.^[1][2]

What CIR Section 10 Actually Requires From HR

Section 10 of the CIR Annex breaks “human resources security” into four distinct sub-requirements. None of them are abstract — each maps to a specific HR-owned document or process.^[2]

CIR §10 point	What it requires	Who owns the deliverable
10.1 — Security responsibility	Mechanisms confirming staff and direct suppliers understand and follow standard cyber-hygiene practices; privileged and admin users specifically must be aware of, and act in line with, their roles and authorities	HR (onboarding content) + CISO (privileged-role definitions)
10.2 — Background verification	Verification of employee background “to the extent feasible,” with documented criteria for which roles require it, performed before the person starts exercising that role	HR + Legal (criteria must respect local employment and data-protection law)
10.3 — Post-employment duties	Terms and conditions of employment or contract that keep confidentiality and security obligations valid after the employment relationship ends	HR + Legal (contract language)
10.4 — Disciplinary process	A documented, communicated disciplinary process for handling security-policy violations, reviewed at planned intervals	HR (process ownership), CISO (violation classification input)

The pattern across all four: CIR treats HR as a control owner, not a bystander who gets looped in after IT flags something. A background-verification criterion that only Legal has seen, or a disciplinary process that only exists in a slide deck, won’t survive an auditor asking to see the document.

Access Review Cadence: The Control Most Programmes Skip

Access review sits inside the broader access control requirement of Article 21(2)(i), but it deserves separate treatment because it’s the one insider-threat control most programmes get half-right: they build the access-provisioning process and skip the review that catches what provisioning missed. CIR §11.2 requires that access rights be reviewed “at planned intervals” and updated when organisational changes occur, with the results of that review documented.^[2] That wording is deliberately open — the regulation doesn’t fix a number of days. ENISA’s technical implementation guidance fills the gap with a concrete recommendation: quarterly review for access to critical systems, as part of a broader Joiner-Mover-Leaver (JML) process that provisions access when someone joins, adjusts it when they change roles, and revokes it promptly when they leave.^[4]

Germany’s BSI, in its own NIS2 guidance on personnel security and access control, names the specific failure mode that access reviews exist to catch: accounts that stay active after someone has left the organisation, especially where access management is decentralised across systems and nobody owns simultaneous lockdown across all of them.^[3] That’s not a hypothetical — it’s the single most common finding when access-review evidence is tested during an audit.

Access tier	Recommended review cadence	Trigger for out-of-cycle review
Privileged / admin accounts, critical systems	Quarterly (ENISA-recommended baseline)[4]	Role change, disciplinary action, resignation notice
Standard user access	Semi-annually, as a practical interpretation of “planned intervals”	Department transfer, contract change
Third-party / contractor access	At contract renewal, minimum annually	Contract termination, scope change

The right-hand column is where most programmes actually fail. A calendar-driven quarterly review catches stale access eventually; it does nothing for the three months between reviews when someone resigns on a Tuesday and keeps VPN access until the next scheduled cycle. The termination trigger has to be event-driven, not calendar-driven, and HR is the only function that reliably knows the event happened on day one.

In practice, that means two parallel workflows, not one. The scheduled review (quarterly for privileged accounts, semi-annually for standard access) is a batch process: IT security pulls a current access list, checks it against current role assignments, and documents the result — the CIR §11.2 deliverable. The event-driven review is a trigger, not a batch: the moment HR processes a termination, a resignation with immediate effect, or a role change, that person’s access should be revoked or adjusted within hours, not at the next scheduled cycle. Programmes that only run the scheduled version and treat the event-driven trigger as “covered by the same process” are the ones that show up in BSI’s named failure mode — an account still live weeks after the person who used it has left.^[3]

Separation of Duties: Article 21(2)(i)’s Quietest Control

CIR §11.2 also requires that “conflicting duties and conflicting areas of responsibility shall be segregated, where applicable” — access rights assigned on need-to-know, least privilege, and separation of duties.^[2] BSI’s guidance frames the same idea as “functional separation” that prevents conflicts of interest, and flags password reuse and weak decentralised access management as the practical failure modes that erode it.^[3]

For insider threat specifically, separation of duties matters because it’s the control that limits damage a single trusted person can do alone, regardless of how well they were screened at hiring. The classic example is financial: the person who approves a payment shouldn’t also be the person who can create the payee. The HR-adjacent version is less discussed but just as important — the person who requests access provisioning shouldn’t be the same person who approves it, and the person managing an employee’s exit shouldn’t be the sole party responsible for confirming their system access was actually revoked. Build that as a two-person check into the offboarding workflow itself, not as a policy sentence nobody follows under deadline pressure.

A Behavioural Indicators Programme HR and IT Can Actually Run Together

Neither the NIS2 Directive nor CIR 2024/2690 uses the phrase “behavioural indicators” or defines a formal insider-threat detection programme — this section is original synthesis, not a regulatory citation, so treat it as practical guidance rather than a compliance requirement in itself. What follows is a framework for combining the technical signals a security team already collects with the HR-observable signals only HR has, because in practice neither category alone catches most insider incidents in time.

Technical signals — unusual data-transfer volumes, access to systems outside a person’s normal working pattern, repeated failed authentication attempts, use of unsanctioned removable media — are what most “insider threat” tooling markets itself around. They’re necessary but not sufficient: negligent insiders, who account for the largest share of incident cost, don’t set off anomaly detection because nothing about their access pattern looks wrong. They’re using systems they’re authorised to use, carelessly.^[5]

HR-observable signals are the other half, and they’re rarely fed into the same escalation path: a resignation with a working notice period, a sudden and unexplained decline in performance, an active disciplinary case, a role change that hasn’t yet been matched by an access-rights update. None of these alone justifies suspicion — most departing employees are not insider risks — but a documented escalation path that says “when HR opens a disciplinary case or receives a resignation, security reviews that individual’s access and recent activity within five business days” turns two isolated data points into a single, defensible control. Keep the criteria behaviour-based and role-neutral to avoid discrimination exposure, and route any HR-to-security data share through the same lawful-basis review you’d apply to other employee monitoring.

Where GDPR and Works Councils Limit How Far This Can Go

Sharing HR signals with a security team is itself the processing of employee personal data, and Article 88 GDPR specifically authorises EU member states to set stricter national rules for exactly this context — including monitoring systems at the workplace.^[6] Every member state has used that authorisation differently, which means a behavioural indicators programme that’s compliant in one jurisdiction can be unlawful in another. Germany and the Netherlands generally require works council consultation, and in some cases formal co-determination approval, before a monitoring system that could be used to evaluate employee conduct or performance goes live. France, Italy, and Belgium restrict employee monitoring more directly and require workers to be informed in advance of the existence, purpose, and duration of any monitoring — after-the-fact disclosure doesn’t cure the gap.^[6]

The practical implication for the behavioural indicators framework above: don’t design it centrally and roll it out EU-wide as a single policy. Treat the technical-signal half (data-transfer monitoring, authentication anomalies) as an IT security control subject to your existing employee-monitoring lawful basis, and treat the HR-signal half (disciplinary case, resignation, performance decline) as an internal escalation trigger rather than a new monitoring system — routing an existing HR record to security on a defined trigger is a materially different (and generally easier to justify) processing activity than building a new behavioural-scoring system. Get Legal and, where one exists, the works council or employee representative body, to sign off on the escalation criteria before go-live, not after a first incident forces the question.

Who Owns What

Task	HR	CISO / IT Security	Legal
Draft HR security policy (CIR §10.1-10.4)	Owner	Reviewer	Reviewer
Background verification criteria	Owner	Input (role sensitivity)	Reviewer (employment law)
Access provisioning / revocation trigger	Trigger source (start/change/exit events)	Owner (execution)	—
Quarterly / periodic access review	—	Owner	—
Disciplinary process for security violations	Owner	Input (violation classification)	Reviewer
Behavioural indicators escalation path	Joint owner	Joint owner	Reviewer (monitoring lawfulness)

The Documentation Checklist Auditors Will Ask For

Compliance officers building the audit file for Article 21(2)(i) — alongside the broader CIR documentation set — should expect to produce all of the following on request:

• The HR security policy itself, with a visible last-review date
• Background-verification criteria showing which roles require it and why
• Signed acknowledgements of post-employment confidentiality obligations for relevant roles
• A disciplinary process document, with evidence it has been reviewed at a planned interval
• Access-review records showing the date of each review, who performed it, and what changed as a result
• An offboarding checklist with a timestamped access-revocation confirmation, ideally signed off by someone other than the requester

A policy that exists but was never reviewed, or an access review that happened with no documented output, reads to an auditor as equivalent to no control at all. The paper trail is the control, as far as CIR §11.2’s “document the results” language is concerned.^[2]

Key Takeaways

Article 21(2)(i) makes HR a named control owner under NIS2, not a downstream recipient of security requirements. Build the CIR §10 document set even if CIR’s narrower scope doesn’t formally bind your entity — it’s the clearest official reference point available. Make access review event-driven at termination and calendar-driven everywhere else, because the gap between a resignation and the next scheduled review is where stale access actually gets exploited. Separate the person who requests access changes from the person who approves them, and route HR’s disciplinary and departure signals into the same escalation path your security team already runs for technical anomalies — most insider incidents involve a person whose risk was visible to HR well before it was visible to a SIEM.

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

• NIS2 Directive (EU) 2022/2555, Article 21 — nis-2-directive.com
• Commission Implementing Regulation (EU) 2024/2690, Annex I, Sections 10-11 — advisera.com
• BSI (Germany) — Personalsicherheit, Zugriffskontrolle und Asset-Management, NIS-2 Infopaket — bsi.bund.de
• ENISA — NIS2 Technical Implementation Guidance (26 June 2025) — enisa.europa.eu
• Ponemon Institute / DTEX Systems — 2026 Cost of Insider Risks Global Report, via Help Net Security — helpnetsecurity.com
• Regulation (EU) 2016/679 (GDPR), Article 88 — gdpr-info.eu