NIS2 Access Control and Human Resources Security: A Complete Guide to Article 21(2)(i)

This article explains what NIS2 Article 21(2)(i) and Commission Implementing Regulation (EU) 2024/2690 require for access control, human resources security, and asset management. It reflects the CIR Annex requirements and ENISA’s Technical Implementation Guidance (June 2025). It does not constitute legal advice — consult a qualified practitioner for organisation-specific guidance.

Access control failures are not a peripheral risk in NIS2 compliance — they are the primary attack vector regulators are focused on. Stolen credentials are the leading initial access method, appearing in 22% of data breaches according to Verizon’s 2025 Data Breach Investigations Report — ahead of phishing. IBM’s 2025 analysis puts the average cost of a breach involving compromised credentials at $4.8 million [4]. When supervisory authorities conduct inspections under Article 21, access control gaps — particularly excessive privileges and accounts that persist after termination — are consistently among the highest-priority findings.

Article 21(2)(i) of the NIS2 Directive addresses this by requiring measures covering human resources security, access control policies, and asset management. The Commission Implementing Regulation (EU) 2024/2690 translates this into more than 15 binding sub-requirements across three Annex sections: Section 10 (HR security), Section 11 (access control), and Section 12 (asset management). This guide maps every requirement to practical controls and explains what evidence regulators expect.

What Article 21(2)(i) Requires: Three CIR Sections

Unlike some NIS2 provisions that leave scope for national interpretation, the CIR is precise. The table below maps the three sections to their NIS2 provision and the templates that address them. Section 11 also covers Art. 21(2)(j) on multi-factor authentication, making it one of the most cross-referenced sections in the entire CIR.

CIR Section	Title	NIS2 Point	Primary Templates
Section 10	Human Resources Security	Art. 21(2)(i)	33 HR Security Policy, 34 Statement of Acceptance, 44 Confidentiality Statement
Section 11	Access Control	Art. 21(2)(i) and (j)	28 Access Control Policy, 29 Authentication Policy, 30 Password Policy
Section 12	Asset Management	Art. 21(2)(i)	16 Information Classification, 17 Asset Management Procedure, 18 IT Asset Register

The 10 Article 21 cybersecurity measures form an integrated programme. Access control cannot be implemented correctly in isolation from HR security and asset management — Section 12 determines what assets exist, Section 10 determines who is authorised to access them, and Section 11 controls how that access is granted and revoked.

CIR Section 11: Access Control Requirements

Section 11 is the most technically dense of the three sections, covering seven sub-areas from access rights management to multi-factor authentication.

Access Control Policy (CIR 11.1)

You must establish, document, and implement logical and physical access control policies based on business and security requirements (11.1.1). The policy must address three categories of user: staff, visitors, and external entities — explicitly including suppliers, service providers, and contractors (11.1.2). Policies must be reviewed and updated at planned intervals and after significant incidents or changes (11.1.3).

The most common compliance gap is fragmented documentation: separate policies for IT system access, visitor badges, and third-party accounts that are never reconciled into a coherent framework. The CIR requires a single, integrated access control policy that addresses all user categories. Template 28 (Access Control Policy) provides this structure.

Access Rights and the Least Privilege Principle (CIR 11.2)

CIR 11.2.2 is the most operationally demanding requirement in Section 11. Access rights must be assigned and revoked based on need-to-know, least privilege, and separation of duties. In practice, this creates four concrete obligations:

• Access rights modified on termination or role change — not queued for the next IT maintenance window
• Third-party access limited in scope and duration — open-ended contractor accounts that persist after contract end are a direct CIR violation
• A register of all access rights granted maintained — a live record traceable to individual authorisations, not a spreadsheet updated quarterly
• Logging applied to access rights management — who granted what access, when, and with whose authorisation

Access rights must be reviewed at planned intervals with results documented (11.2.3). ENISA’s Technical Implementation Guidance maps this requirement to ISO/IEC 27001:2022 control A.5.18, which typically establishes quarterly reviews for privileged accounts and annual reviews for standard access. Your access control policy must specify these frequencies explicitly — “at planned intervals” without a defined cadence does not satisfy the requirement during an inspection.

Privileged Accounts and Administration Systems (CIR 11.3–11.4)

Privileged and administration accounts carry the highest regulatory and operational risk. CIR 11.3.2 requires four specific controls:

• Strong identification, authentication (including MFA), and authorisation for all privileged accounts
• Separate accounts exclusively for system administration, distinct from accounts used for everyday work such as email and web browsing
• Administration privileges individualised and restricted to the highest extent possible
• Admin accounts connecting only to admin systems, not to general application networks or internet-facing services

CIR 11.4.2 adds that administration systems must be logically separated from non-admin application software and protected through both authentication and encryption. The practical implication: your domain administrator credential cannot be the same login used for email. This separation is technically straightforward but organisationally difficult because it adds friction for senior IT staff who have historically used a single account for everything. The CIR removes the option of accepting this risk by policy exemption.

Identity Lifecycle Management (CIR 11.5)

CIR 11.5.2 requires unique identities for all systems and users, with each user identity linked to a single person. Shared accounts are permitted only where strictly necessary for business or operational reasons, must be explicitly approved and documented, and must be factored into risk management (11.5.3). Identities that are no longer needed must be deactivated without delay (11.5.4) — not on a scheduled review cycle.

Identity lifecycle management connects directly to the Joiner-Mover-Leaver process below and to the asset inventory under Section 12. You cannot manage identity lifecycles reliably without knowing what systems exist and what classification they carry — which is why Section 12 is a prerequisite for Section 11, not an afterthought.

Authentication Strength and Multi-Factor Authentication (CIR 11.6–11.7)

Authentication strength must match the classification of the asset being accessed (11.6.2). Specific controls include: credential change at first use and at predefined intervals, session termination after inactivity, account blocking after a predefined number of failed login attempts, and separate credentials for privileged accounts.

CIR 11.7.1 requires MFA or continuous authentication “where appropriate per asset classification.” For entities in scope of CIR 2024/2690 — DNS providers, cloud computing services, CDNs, managed service providers, and trust service providers — ENISA’s guidance treats MFA as effectively mandatory for any privileged or remote system access. Art. 21(2)(j) of the Directive reinforces MFA as a standalone requirement for the broader NIS2 entity population. See the NIS2 security requirements guide for the Art. 21(2)(j) framework and how it interacts with Section 11.

CIR Section 10: Human Resources Security

Section 10 governs people from the moment of hiring to after they leave. Four sub-sections cover security commitments, background screening, termination, and disciplinary process.

Security Commitments in Employment (CIR 10.1)

CIR 10.1.1 requires that employees and direct suppliers or service providers understand and commit to their security responsibilities appropriate to their role and the services they deliver. CIR 10.1.2 specifies how this is operationalised across three groups:

• All employees and supplier staff follow cyber hygiene practices per CIR Section 8 — see the NIS2 training requirements guide for Section 8’s full obligations
• Users with admin or privileged access are specifically aware of and act in accordance with their roles, responsibilities, and authorities
• Management bodies understand and fulfil their security governance obligations under Article 20 of the Directive

CIR 10.1.2(d) adds a hiring control: reference checks, vetting, certification validation, and written tests for roles with elevated access. This exceeds standard HR practice in most organisations, which applies rigorous screening only to senior hires. Under the CIR, the trigger is access level and role criticality — not seniority.

CIR 10.1.3 requires that assignments to specific security roles and commitment of human resources are reviewed at least annually. Your role-to-access mapping cannot sit in a policy document reviewed on a three-year cycle — it requires a documented annual governance process.

Background Verification (CIR 10.2)

CIR 10.2.2 requires background verification before individuals begin exercising roles that require it, considering applicable law, ethics, business requirements, asset classification, and perceived risk. The scope of checks can include criminal records, credit history, professional references, educational credentials, and screening against sanctions and PEP (politically exposed persons) lists.

Two implementation points are critical:

1. Verification must be completed before access is granted, not during a probation period — CIR 10.2.2 is explicit on timing
2. Contractors and direct service provider staff are in scope (10.2.1) — the requirement is not limited to permanent employees

NIS2 does not mandate government-grade security clearances. CIR 10.2.2(a) requires organisations to establish their own criteria determining which roles require verification, proportionate to asset classification and risk profile. These criteria must be documented in the HR Security Policy (Template 33) rather than decided case-by-case — inconsistent application is the most common audit finding in this area.

Termination and Change of Employment (CIR 10.3)

CIR 10.3.1 requires that security responsibilities surviving employment — confidentiality obligations, intellectual property restrictions, data handling duties — are contractually defined and enforced after termination. CIR 10.3.2 specifies these obligations must appear in employment terms, conditions, or contracts with post-termination clauses explicitly referenced. Template 44 (Confidentiality Statement) documents these obligations for departing personnel.

This provision is frequently underimplemented. Most organisations include confidentiality clauses in employment contracts but do not run a systematic process to remind leavers of ongoing obligations at exit and obtain signed acknowledgement. Regulators expect documented evidence that this process was followed for each departing employee — not just that the clause exists in the contract template.

Disciplinary Process (CIR 10.4)

A formal disciplinary process for security policy violations must be established, communicated, and maintained (10.4.1). This applies to all personnel with system access, including contractors and third parties. The process must be reviewed when legal requirements change. CIR 10.4 does not prescribe the substance of the disciplinary process — only that it exists, is communicated, and is applied consistently.

The Joiner-Mover-Leaver (JML) Process in Practice

The JML process is the operational integration of CIR Sections 10 and 11: it links HR lifecycle events to access rights changes in a single, auditable workflow. Without a defined JML process, compliance with both sections is structurally impossible — access rights cannot be managed correctly if IT is not notified of terminations and role changes in time to act.

Joiner: New Employees, Contractors, and Supplier Staff

Action	Timing	CIR Reference
Background check completed	Before access granted	CIR 10.2.2
Role and access scope defined per least privilege	Before account creation	CIR 11.2.2(a)
Unique identity created; shared accounts prohibited unless documented exception	Day 1	CIR 11.5.2–11.5.3
Statement of Acceptance signed (Template 34)	Before first login	CIR 1.2.2, 10.1.1
MFA enrolled for all relevant systems	Before first login	CIR 11.7.1
Role-appropriate security training completed	Before unsupervised system access	CIR 8.1.1

Mover: Role Changes and Promotions

When an employee changes role, two processes must happen in parallel: new access rights granted and previous role permissions explicitly revoked. The most common failure mode is adding new access while leaving old permissions intact — resulting in privilege accumulation that directly violates the least privilege requirement in CIR 11.2.2. If the new role involves higher privilege levels, an updated MFA check and revised Statement of Acceptance should also be completed.

Leaver: Terminations and Contract Endings

Action	Timing	CIR Reference
Privileged access revoked	Same day as termination decision	CIR 11.2.2(b), 11.5.4
All user account access revoked	Within 24 hours	CIR 11.2.2(b)
All identities deactivated across systems	Without delay	CIR 11.5.4
Assets returned and documented	Before final working day	CIR 12.5
Post-termination obligations confirmed in writing	On or before final day	CIR 10.3.1–10.3.2

ENISA’s Technical Implementation Guidance identifies delayed offboarding — access persisting more than 24–48 hours after termination — as one of the most frequently cited findings under Art. 21(2)(i) inspections. For privileged accounts, same-day revocation is the expected standard, not a best practice target.

CIR Section 12: Asset Management

Asset management completes the Art. 21(2)(i) triad. Without knowing what assets you have and how they are classified, access control policies cannot be applied correctly — the CIR links these explicitly because asset classification drives authentication strength requirements under Section 11.

Asset Classification (CIR 12.1): All assets — hardware, software, data, and services — must be assigned classification levels based on confidentiality, integrity, authenticity, and availability requirements (12.1.2). Classification determines which authentication controls apply: a classified system processing personal data requires stronger access controls than a public-facing marketing site. Without formal classification, access decisions default to informal judgement, which is inconsistent and indefensible in an inspection.

Asset Inventory (CIR 12.4): CIR 12.4.1 requires a complete, accurate, up-to-date, and consistent inventory of assets, with changes recorded traceably. This is a structural prerequisite for meaningful access reviews under Section 11.2.3 — you cannot review who has access to what if you do not maintain a reliable record of what systems exist. The IT Asset Register (Template 18) provides the structure for this inventory.

Asset Handling (CIR 12.2): An asset handling policy must cover the complete lifecycle from acquisition to secure disposal, including rules for safe storage, transport, and irretrievable deletion or destruction (12.2.2). This is relevant both to physical hardware and to data held in cloud services — cloud data must be classified and handled in accordance with the policy, not treated as out-of-scope.

Removable Media (CIR 12.3): A removable storage media policy must be implemented, covering technical prohibition of unauthorised media connection, malicious code scanning, and cryptographic protection where appropriate. This is frequently overlooked in access control reviews but is an explicit requirement under Art. 21(2)(i).

Asset Return on Termination (CIR 12.5): When employment ends, all assets under that person’s custody — laptops, tokens, access cards, licensed software — must be returned, deposited, or deleted, with each action documented. This links directly to the Leaver stage of the JML process and must be completed before offboarding is recorded as closed.

The NIS2 vs ISO 27001 comparison details how CIR Sections 10, 11, and 12 align with ISO 27001:2022 controls A.5–A.8 if your organisation is using an ISO 27001 framework as a compliance baseline.

Templates That Cover CIR Sections 10, 11, and 12

The templates below directly address the primary requirements across the three CIR sections:

• Template 28 — Access Control Policy: Covers CIR 11.1–11.7 — the full access control framework including privileged account rules, access rights management, identity lifecycle, authentication requirements, and MFA obligations.
• Template 29 — Authentication Policy: Supplements Template 28 with specific authentication procedures, credential management rules, and session control requirements.
• Template 30 — Password Policy: Addresses CIR 11.6.2 credential requirements — complexity, rotation, and reset procedures after suspected compromise.
• Template 33 — HR Security Policy: Covers CIR 10.1–10.4 — background screening criteria, security commitments by role type, termination procedures, and disciplinary process.
• Template 34 — Statement of Acceptance of Cybersecurity Documents: The signed acknowledgement that each person with system access has read and agrees to their security obligations (CIR 1.2.2, 10.1.1). Required for all joiners and on material role changes.
• Template 44 — Confidentiality Statement: Documents post-termination obligations for departing personnel (CIR 10.3).
• Template 16 — Information Classification Policy: Covers CIR 12.1 — classification levels, labelling, and handling rules.
• Template 17 — Asset Management Procedure: Covers CIR 12.2–12.3 and 12.5 — asset handling, removable media policy, and termination procedures.
• Template 18 — IT Asset Register (XLSX): The live inventory supporting CIR 12.4 — a complete, traceable record of all in-scope assets.

All templates are available in the NIS2 compliance template library. Use the NIS2 compliance checklist to track which requirements each template addresses before a supervisory authority inspection.

Frequently Asked Questions

Does Art. 21(2)(i) apply to contractors and third-party staff?

Yes. CIR 10.1.1 explicitly includes direct suppliers and service providers, wherever applicable. Background checks (10.2.1), security commitments (10.1.2), and offboarding procedures must cover anyone with access to your network and information systems — not just permanent employees.

How often must access rights be reviewed under NIS2?

CIR 11.2.3 requires reviews “at planned intervals.” The CIR does not specify a minimum frequency, but ENISA’s guidance maps this to ISO 27001:2022 control A.5.18. In practice, most supervisory authorities expect quarterly reviews for privileged accounts and annual reviews for standard access, with results documented and retained.

Is MFA mandatory under NIS2?

CIR 11.7.1 requires MFA or continuous authentication where appropriate per asset classification. For entities in scope of CIR 2024/2690, MFA is expected for all privileged and remote access. Art. 21(2)(j) reinforces this as a standalone requirement for the broader NIS2 entity population.

What background checks does NIS2 require?

CIR 10.2.2 requires verification appropriate to the role: criminal records, credit history, references, educational credentials, and sanctions or PEP screening are all in scope. Verification must happen before access is granted. NIS2 does not mandate government-grade clearances — the scope is proportionate to role risk and asset classification.

What evidence should organisations retain for access control compliance?

Signed Statements of Acceptance, access review logs with dates and approvers, offboarding checklists with completion timestamps, background check authorisation records, and disciplinary case documentation. The CIR does not specify a retention period — align to your national data protection law minimum or use five years as a practical default.

How quickly must access be revoked when an employee leaves?

CIR 11.2.2(b) requires access rights modified on termination; CIR 11.5.4 requires identities deactivated without delay. ENISA’s guidance identifies access persisting more than 24–48 hours after termination as a common audit finding. For privileged accounts, same-day revocation is the expected standard.

For related NIS2 security measures, see the NIS2 risk assessment guide and the incident reporting requirements.

Sources

1. NIS2 Directive (EU) 2022/2555, Article 21 — EUR-Lex
2. Commission Implementing Regulation (EU) 2024/2690, Annex Sections 10, 11, 12 — EUR-Lex
3. ENISA Technical Implementation Guidance on Cybersecurity Risk Management Measures, Version 1.0 — ENISA, June 2025
4. Compromised Credential Statistics 2025 — DeepStrike (citing Verizon 2025 DBIR and IBM Cost of a Data Breach 2025)
5. ISO/IEC 27001:2022, Controls A.5.15–A.5.18 (Access Control), A.6 (People Controls) — ISO