NIS2 Access Control Policy: What CIR 11.1 and 11.2 Actually Require

What a defensible NIS2 access control policy must contain — least privilege, RBAC, SoD, remote access, non-human identities, and the evidence auditors will ask for.

← Back to hub · Prev: Context & governance · Next: Identity lifecycle →

Legal basis: NIS2 Art. 21(2)(i) (access control policies) and (j) (authentication) · CIR (EU) 2024/2690 Annex 11.1 (access control policy) and 11.2 (management of access rights).

TL;DR (🔧 Engineering / 📋 GRC): You need a written, management-approved access control policy covering people and systems, built on least privilege and need-to-know, with access granted by role, segregation of duties enforced, all access rights tracked, and the whole thing reviewed regularly. Authentication, lifecycle, and privileged access are deep enough to have their own pages (04, 03, 05); this page is the policy and the rights-management engine that ties them together.

1. What the law requires

CIR 11.1 — Access control policy

The Implementing Regulation requires relevant entities to establish, document and implement a topic-specific access control policy that governs access by persons and by network and information systems (e.g., applications and services), in order to prevent unauthorised access to assets (CIR Annex 11.1; recital 21). Like every CIR policy, it must be approved, communicated, and reviewed at planned intervals and after significant incidents or changes.

CIR 11.2 — Management of access rights

Entities must manage the full lifecycle of access rights — granting, modifying, reviewing and revoking rights on the basis of the access control policy, the principle of least privilege, and business need. This is the operational engine: identities get exactly the access their role needs, no more, and lose it promptly when the need ends. (The "leaver/mover" mechanics live in 03 — Identity lifecycle; this clause is the control that makes them mandatory.)

The Art. 21(2) hook

Point (i) names "access control policies" explicitly. The all-hazards, proportionate standard of Art. 21(1) applies: a 60-person important entity and a 5,000-person essential entity both need these controls, but the depth scales with risk, size, and exposure.

2. The principles your policy must encode 🔧

Least privilege

Every identity (human, service, machine) gets the minimum access required to do its job, for the minimum time. This is the single most-cited expectation across the CIR access-control clauses. Practically:

• Default-deny: new accounts start with no standing access beyond a baseline.
• Entitlements are additive and justified, never "copy this user's access."
• Time-bound elevation for anything sensitive (see 05 — Privileged access).

Need-to-know

Access to information is scoped to those who require it for a defined purpose, aligned to the asset classification (CIR 12.1 — see 03). Classification and access control are linked: you can't apply "need-to-know" to data you haven't classified.

Role-based access control (RBAC) — and where ABAC helps

Grant access through roles mapped to job functions, not to individuals. RBAC gives you reviewable, repeatable entitlements and is the pragmatic default. Use attribute-based access control (ABAC) — decisions based on attributes such as department, location, device posture, data classification — where RBAC role explosion becomes unmanageable or where context (e.g., "only from a managed device") must drive the decision. Most mature environments run RBAC for the baseline + ABAC/policy conditions for context.

Segregation of duties (SoD)

No single identity should be able to execute and conceal a sensitive end-to-end action (e.g., create a vendor and approve its payment; write code and deploy to production unreviewed). The CIR requires conflicting duties and areas of responsibility to be segregated where applicable (CIR 1.2). Define SoD conflict pairs, prevent them at provisioning, and detect violations in access reviews.

Unique identity & accountability

Every actor maps to a unique, attributable identity — no shared logins. This is formally required under identification (CIR 11.5 — see 04) and is the precondition for meaningful logging (CIR 3.2 logs "all privileged access … and activities performed by administrative accounts").

3. Coverage your policy must address 🔧

A defensible access control policy is explicit about all of these access surfaces:

Remote & network access — the CIR's stated expectations

The recitals are unusually concrete here: limit connections and access to only what is needed, use VPNs for remote access, and allow service-provider connections only after an authorisation request and for a set time period (recital 18). Modern equivalents — Zero Trust Network Access (ZTNA), per-app brokered access, device-posture checks — satisfy and exceed this. Zero-trust is explicitly named as a basic-hygiene practice in recital 20.

4. Zero Trust alignment 🔧

NIS2/CIR do not mandate a named "Zero Trust" architecture, but the access-control clauses describe one in substance: verify explicitly (strong auth, every request), least privilege (just-enough/just-in-time), assume breach (segmentation, continuous monitoring). If you are modernising, a zero-trust roadmap is the most efficient way to satisfy CIR 11.1, 11.2, 11.5–11.7, and 6.8 together. Map each zero-trust pillar back to the CIR clause it satisfies so the architecture doubles as compliance evidence.

5. Implementation notes (vendor-neutral) 🔧

These are examples, not endorsements — the obligations are platform-agnostic.

Design rules that keep you audit-ready regardless of tooling:

1. One authoritative identity source, federated to apps via SSO — fewer local accounts, fewer orphans.
2. Roles defined as data (in the IGA/IdP), so entitlements are exportable for reviews.
3. Every grant has a request, approver, justification, and timestamp — that record is your evidence.
4. Non-human identities are first-class: inventoried, owned, scoped, and rotated.

6. Evidence an auditor will ask for 📋

• The access control policy itself, with the management-approval record and date and last-review date.
• The role/entitlement model export (roles → permissions → who holds them).
• SoD conflict matrix and evidence it is enforced/monitored.
• Sample access grants showing request → approval → justification.
• Service/non-human account inventory with owners and scopes.
• Remote/third-party access records showing authorisation and time-boxing.
• Evidence of the most recent access review (links to 03 and 06).

Common gaps that become findings

• Policy exists but was never formally approved by the management body, or hasn't been reviewed in >12 months.
• "Least privilege" asserted but entitlements were cloned from peers; standing admin everywhere.
• Service accounts with broad rights, no owner, shared secrets, never rotated.
• Third-party/VPN access permanent rather than time-boxed.
• No SoD definition, so violations are invisible.

Sources

• NIS2 Art. 21 — risk-management measures
• Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex (Annex §11.1, §11.2; recitals 18, 20, 21)

FAQ

What must a NIS2 access control policy include? Under CIR 11.1, the policy must be a documented, management-approved topic-specific document covering access by both persons and systems. It must be built on least privilege and need-to-know, define how access is granted by role, address segregation of duties, cover all access surfaces (workforce, application, non-human, remote, third-party, and privileged), and be reviewed at planned intervals and after significant incidents or changes.

Does NIS2 require role-based access control? NIS2 and the CIR do not mandate a specific named model, but CIR 11.2 requires access to be granted on the basis of business need and least privilege — which in practice means role-based grants rather than individual entitlement assignment. RBAC is the standard approach; ABAC is used where context-dependent decisions (device posture, location, data classification) are needed alongside the role baseline.

What is segregation of duties under NIS2? Segregation of duties (SoD) means that no single identity can execute and conceal a sensitive end-to-end process — for example, both creating a vendor record and approving its payment, or writing and unilaterally deploying code to production. CIR 1.2 requires conflicting duties to be separated where applicable. Organisations should define SoD conflict pairs, prevent them at provisioning, and detect violations during access reviews.

How often must access rights be reviewed under NIS2? The CIR requires access rights to be reviewed at planned intervals and after significant changes or incidents; it does not fix specific frequencies. A risk-based baseline would be quarterly reviews for privileged and admin accounts, quarterly to semi-annual for high-classification data access, and annual for standard application access. Reviews must be decision-forcing — explicit approve or revoke for each entitlement — and the records retained.

Are non-human identities covered by NIS2 access control requirements? Yes. CIR 11.1 covers access by persons and systems. Service accounts, API keys, workload identities, and tokens must be inventoried, owned, scoped to the minimum necessary access, and have secrets rotated. Non-human accounts are frequently the weakest area in access-control audits because they are often granted broad rights at creation and never revisited.

How KINT helps: KINT automates the joiner, mover, and leaver access lifecycle across your SaaS apps and produces signed, timestamped access-review evidence mapped to SOC 2 CC6 — the kind of evidence NIS2 Article 21 expects you to be able to show. It is early-stage and self-serve, and runs without an identity provider. See how KINT handles the lifecycle or book a 15-minute walkthrough.