NIS2 User Access Reviews: Three Duties, Three Cadences — ENISA’s Annual, Quarterly, and the One It Leaves to You

A NIS2 user access review is three reviews, not one. The Annex to Implementing Regulation (EU) 2024/2690 sets three separate review duties. Point 11.2.3 covers access rights, point 11.3.3 covers privileged and system administration accounts, and point 11.5.4 covers identities, including those of systems as well as people. The first two run “at planned intervals” and the results must be documented. The third must happen “regularly”, and any identity that’s no longer needed has to be deactivated “without delay”. The regulation sets no frequency for any of them. ENISA’s guidance gives a number for two: access rights “at least annually”, identities “as a minimum quarterly” (annually for micro-sized entities). Privileged accounts, the review most vendor guides quote as quarterly, get no number at all.

This guide treats each review as its own process with its own question, output and evidence. All three start from the same input: your register of access rights granted, required by point 11.2.2(e).

This article provides general information only and does not constitute legal advice. NIS2 implementation varies by member state and sector. Always check requirements against your national transposition law and applicable authority guidance.

Does This Apply to You?

In plain terms: eleven types of digital provider are bound by the Annex wording directly. Every other NIS2 entity needs “access control policies” under national law, and the Annex is the most detailed EU reference for what those policies should contain.

Who you are	What binds your access reviews	Practical effect
DNS provider, TLD registry, cloud, data centre, CDN, managed service provider, managed security service provider, online marketplace, search engine, social network or trust service provider	Implementing Regulation 2024/2690, Article 1 and Annex points 11.2.3, 11.3.3 and 11.5.4 (directly applicable)	All three reviews apply word for word. An auditor can test each one separately.
Any other essential or important entity	Article 21(2)(i) NIS2 (“human resources security, access control policies and asset management”), as transposed nationally	Your national law and authority set the detail. The three-review model is a strong reference, not a verbatim duty.
Supplier with accounts in an in-scope customer’s systems	Your customer’s point 11.2.2(d) controls and your contract	Expect your accounts to be limited “in scope and in duration” and to show up in their reviews.

Article 21(1) of the NIS2 Directive requires measures that are “appropriate and proportionate”, so a 30-person managed service provider and a hyperscaler can meet the same three duties with different tooling. Infringing Article 21 can bring administrative fines with a maximum of at least EUR 10 million or 2% of worldwide annual turnover for essential entities, and at least EUR 7 million or 1.4% for important entities, whichever is higher (Article 34(4) and (5)). The actual ceilings depend on national law and the authority’s discretion.

Note: national transposition laws and supervisory practice vary by Member State. Confirm the local rules with your competent authority.

Three Duties in the Text, Not One

In plain terms: the three points review different things, use different trigger words and end in different actions. Running them as one campaign usually skips at least one of them.

	Access rights review	Privileged account review	Identity review
Annex point	11.2.3	11.3.3	11.5.4
What is reviewed	Access rights granted (the entitlements)	Access rights of privileged and system administration accounts	Identities “for network and information systems and their users”
Timing wording	“at planned intervals”	“at planned intervals”	“regularly”
Required action	Modify rights “based on organisational changes”	Modify “based on organisational changes”	Deactivate identities no longer needed “without delay”
Documentation in the point	Results, “including the necessary changes”	Results, “including the necessary changes”	None in 11.5.4 itself; 11.5.2(d) requires logging of identity management
ENISA cadence	“at least annually”	None stated	“as a minimum quarterly”; annually for micro-sized entities
ENISA’s question	Are all privileges authorised?	Do the admins’ duties, roles, responsibilities and competences still qualify them?	Is every active identity still needed?
ISO/IEC 27001:2022 (ENISA mapping)	A.5.18, A.5.3	A.8.2, A.8.18	A.5.16

Legal rule: Annex to Implementing Regulation 2024/2690, points 11.2.3, 11.3.3, 11.5.4. ENISA rows: non-binding guidance and ENISA’s mapping table v1.2.

The difference is easiest to see on one employee. A manager asked “does Anna still need these 14 entitlements?” is running 11.2.3. Nobody in that campaign asks whether the backup service account Anna set up in the cloud console should still exist (11.5.4). Nor does anyone ask whether Anna’s current skills still justify her domain admin rights (11.3.3). Those are three different questions, put to three different people.

We counted the wording across the full Annex. “Planned intervals” appears 30 times. The Annex adds an “at least annually” floor in only three places: the security policy review by management bodies (1.1.2), the risk assessment results (2.1.4) and the assignment of personnel to security roles (10.1.3). None of the access reviews has a floor, so the interval is yours to set, and the auditor will test you against it. None of the three review points says “where appropriate” either. The Article 2(2) route of documenting why a requirement doesn’t fit you only exists for points with that kind of qualifier. These three have none, so they must all be done.

Review 1: Access Rights (Point 11.2.3)

In plain terms: once per cycle, every right in your register is checked against the holder’s current job, and the changes go on file.

The input is the register. Point 11.2.2(e) says “maintain a register of access rights granted” with no qualifier. ENISA attaches “where appropriate” only to keeping one central register. Its footnote explains why: “Implementing a unique centralised database would require major interfacing work with systems that, in many cases, were not designed for it.” Our reading (interpretation): the register is mandatory, but a single database is not. A set of per-system exports, reconciled against the HR roster and kept together, can serve as the register if it’s complete.

The reviewer is the owner, not the admin. ENISA’s guidance for 11.2.2 asks for authorisation “from the owner of the asset” and for segregation of “the roles of approval and implementation of the access rights”. An administrator certifying rights they granted themselves defeats both.

Step	What to do	Annex hook	Effort
1	Freeze a dated snapshot of the register and the HR roster	11.2.2(e)	Low
2	Reconcile accounts to people: leavers, movers, unknown owners	11.2.2(b)	Medium
3	Each asset owner marks every right keep, modify or remove	11.2.2(a), (c)	Medium to High
4	Flag combinations that break separation of duties	11.2.2(a)	Medium
5	Confirm third-party rights are still limited in scope and duration	11.2.2(d)	Low
6	Execute the changes, with the change logged	11.2.2(f)	Medium
7	Write the results record: date, scope, reviewers, rights reviewed, changes made, open exceptions	11.2.3	Low

Recommended internal practice, built on points 11.2.2 and 11.2.3.

A leaver turned up at step 2 should already have been caught. Point 11.2.2(b) requires rights to be modified “upon termination or change of employment”, and the review is the safety net, not the mechanism. Log each one as a joiner-mover-leaver failure with a root cause. Our employee offboarding access revocation checklist covers the leaver side step by step. ENISA’s floor for the full review is “at least annually”. The text also requires rights to be modified “based on organisational changes”, so a reorganisation or merger should prompt an extra review of the affected units rather than waiting for the cycle.

Review 2: Privileged and Administration Accounts (Point 11.3.3)

In plain terms: the wording and the documentation duty match 11.2.3, but the question changes. You’re no longer asking whether the right is needed. You’re asking whether this person is still the right one to hold it.

ENISA’s only guidance for 11.3.3 is a single sentence: “Verify whether the duties, roles, responsibilities and competences of system administrators still qualify them for working with privileged access rights.” That turns 11.3.3 into partly a people review. The reviewer needs to know what the admin does today, what they’re trained for, and whether a tier of access is still justified. A line manager clicking “approve” in an entitlement campaign can’t answer that.

The review is only as good as its population. Point 11.3.2(b) requires accounts “to be used for system administration operations exclusively”, and 11.6.2(f) requires separate credentials for privileged accounts. If your admins do their admin work from their everyday accounts, there’s no clean list to review, so fix that first. ENISA’s guidance on point 11.3.2 accepts one exception: in environments such as Microsoft 365, privileged users may keep a single identity if compensating measures are in place, such as MFA, just-in-time access and session logging. In that case, mark those identities as privileged in the register so the review can still find them. Our privileged access management guide covers the four admin-account rules in detail.

On cadence, neither the Annex nor ENISA gives a number for this review. Quarterly is a common choice among practitioners because a privileged account has the widest reach if it’s compromised. Treat that as a judgement you write into your policy and justify, not as a regulatory figure. PAM suites can generate the review campaign, but our CyberArk compliance mapping shows where the tool’s output still falls short of the evidence the Annex needs.

Review 3: Identities, Including Non-Human Ones (Point 11.5.4)

In plain terms: list every identity that exists, human or system, and switch off the ones nobody needs, straight away rather than at the next review.

This is the review most programmes underscope. Point 11.5.4 covers “the identities for network and information systems and their users”, and 11.5.2(a) requires unique identities for systems as well as users. Service accounts, scheduled-task accounts and integration identities are inside the population, even though no HR record points to them. Each needs a named human owner who can answer “still needed?”

Two more rules feed this review. Point 11.5.2(b) links each user identity “to a single person”. Point 11.5.3 allows identities shared by several people only where “necessary for business or operational reasons” and subject to “an explicit approval process and documentation”, and they must be considered in the risk management framework. In our reading, each review should re-test whether each shared identity is still justified, and record the result next to its original approval.

ENISA’s cadence is the most specific in this area: review all active identities “as a minimum quarterly, or more frequently”, with micro-sized entities allowed to do it annually. It also suggests disabling dormant identities “after a predefined period of days of inactivity, where supported”. That’s an automated rule you set once, not a review step. “Without delay” applies whenever an identity stops being needed, whether the review finds it or not. The Annex sets no hour limit for it, so define “without delay” in your own procedure.

Point 11.5.4 is the only one of the three without an explicit “document the results” clause. Document it anyway: 11.5.2(d) requires logging of identity management, and ENISA lists “records of reviews and updates” as the evidence it expects.

The Evidence an Auditor Will Ask For, Review by Review

In plain terms: keep a separate record for each of the three reviews, each pointing back to the same dated register snapshot.

Review	Keep as input	Output record	Signed off by
Access rights (11.2.3)	Register snapshot, HR roster, approved request forms	Per-owner attestations; list of changes made; exceptions with expiry dates	Asset or system owners; IT security lead
Privileged (11.3.3)	Inventory of admin and system administration accounts, role descriptions, training records	Per-admin decision (retain, reduce, remove) with the reason; changes made	CISO or IT security lead, not the admins themselves
Identities (11.5.4)	Directory and cloud-console account exports, dormant-account report, shared-identity approvals	Identities deactivated with dates; owners confirmed for every system identity	IT operations; identity owners

The logs behind the changes matter as much as the decisions. Point 11.2.2(f) requires logging of access rights management. ENISA’s examples of evidence include audit trails “including timestamps, user IDs and actions performed”, and it notes that disabling rather than deleting accounts “may be necessary to preserve audit trails”. If your review tool overwrites its own history, export the results before closing the campaign. Our logging and monitoring guide covers the log side.

Role	Owns	Watch for
CISO / IT security manager	Running all three reviews; the privileged review itself	Admins who review their own rights
SME owner	Approving the intervals; acting as owner for small systems	One annual “IT check” that produces no written record
Compliance officer	Interval in the policy, evidence file, exception register	Review dates drifting past the interval the policy states
Board / management body	Approving the access control policy and its review cycle	Signing a policy whose intervals nobody can meet

Setting the Cadence: What the Text, ENISA and NIST Each Say

In plain terms: no binding text gives you a number. Pick your intervals, write them into the access control policy, and keep to them.

The missing number isn’t an EU oversight. NIST SP 800-53, the US federal control catalogue, does the same: control AC-2(j) requires account reviews at an “organization-defined frequency”, and AC-6(7) requires privilege reviews at an organisation-defined frequency too. ENISA’s two figures are the closest thing to an EU benchmark, so they’re the safest starting point to depart from with a written reason.

Review	Micro-sized entity	Small or medium entity	Large or high-exposure entity
Identities (11.5.4)	Annual (ENISA allowance) + automated dormant-account rule	Quarterly (ENISA minimum) + automated dormant-account rule	Quarterly or more often; continuous reporting on dormant accounts
Privileged (11.3.3)	Annual, set out as a separate section of the record	Quarterly or semi-annual (your choice; justify it)	Quarterly, plus on every change to an admin’s role
Access rights (11.2.3)	Annual (ENISA floor)	Annual, with semi-annual for critical systems	Annual full cycle, critical systems more often, plus event-driven reviews after reorganisations

Practical framework (recommended internal practice). Only the annual floor for 11.2.3 and the quarterly minimum (annual for micro-sized entities) for 11.5.4 come from ENISA. Every other cell is a judgement call.

For a micro-sized company, ENISA’s figures allow all three reviews to share one annual sitting, as long as the output is three separate records. A single “access review done” entry doesn’t show that the privileged accounts and system identities were looked at. Whatever the size, the policy itself must be reviewed “at planned intervals” under point 11.1.3, which is when the intervals get revisited.

Five Ways an Access Review Fails Its Own Purpose

In plain terms: a review that never changes anything, or never looks at system accounts, produces paperwork without much assurance.

Symptom	Annex point at risk	Fix
Near-100% “keep” rate, no changes recorded, cycle after cycle	11.2.3 (results “including the necessary changes”)	Require a reason for “keep” on privileged and high-risk rights; sample-check a few attestations each cycle
Review population built from the HR system only	11.5.4, 11.5.2(a)	Add directory, cloud-console and application exports; assign an owner to every system identity
Admin rights reviewed inside the line-manager campaign	11.3.3	Separate privileged campaign that asks ENISA’s competence question
Leavers regularly found during reviews	11.2.2(b), 11.5.4	Treat each as a joiner-mover-leaver failure; fix the HR-to-IT trigger
Software-as-a-service apps outside single sign-on missing from the register	11.2.2(e)	Follow ENISA: keep an inventory of authentication and authorisation systems and “review and update” it regularly

For how these reviews sit within the rest of Article 21(2)(i), including HR security and asset management, see our NIS2 access control and HR security guide.

Frequently Asked Questions

How often must user access reviews be done under NIS2?

The Annex to Implementing Regulation 2024/2690 says “at planned intervals” for access rights and privileged accounts, and “regularly” for identities, and sets no number for any of them. ENISA’s guidance suggests access rights at least annually and identities at least quarterly (annually for micro-sized entities). Write your intervals into the access control policy.

Is a quarterly user access review mandatory?

No binding text requires it. Quarterly is ENISA’s suggested minimum for the identity review under point 11.5.4 only. For privileged accounts it’s a common practitioner choice, not a legal figure.

Do service accounts have to be reviewed?

For the entities bound by the Implementing Regulation, yes. Point 11.5.4 covers identities of network and information systems, not only people, and 11.5.2(a) requires unique identities for systems too. Give each one a human owner who confirms it’s still needed.

Can an identity governance tool run the review for us?

It can run the campaign, collect attestations and keep the logs. It can’t decide whether an administrator’s competences still justify their access, which is the question ENISA attaches to point 11.3.3. That decision and its reason still need a named human reviewer.

Does an ISO 27001 certificate cover these reviews?

It helps but doesn’t settle it. ENISA maps the three reviews to ISO 27001 controls A.5.18, A.8.2 and A.5.16, so one set of records can serve both. A NIS2 supervisor will still test against the Annex wording, including the documented “necessary changes” under 11.2.3 and 11.3.3.

How This Guide Was Verified

Every Annex point quoted above was checked against the official English text of Implementing Regulation 2024/2690 in the Official Journal. The word counts (“planned intervals” 30 times, “at least annually” in three points) come from searching that text directly. ENISA’s cadences and review questions were read in its full June 2025 Technical Implementation Guidance, and the ISO 27001 mapping comes from ENISA’s own mapping table, version 1.2. The NIST wording is quoted from SP 800-53 Revision 5. Where a step rests on guidance or practitioner judgement rather than binding text, the article says so.

Sources

1. Commission Implementing Regulation (EU) 2024/2690, Articles 1 and 2(2); Annex points 1.1.2, 2.1.4, 10.1.3, 11.1.3, 11.2.2, 11.2.3, 11.3.2, 11.3.3, 11.5.2–11.5.4, 11.6.2(f)
2. Directive (EU) 2022/2555 (NIS2), Articles 21(1), 21(2)(i) and 34(4)–(5)
3. ENISA, Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0, June 2025 (points 11.2.2, 11.2.3, 11.3.3, 11.5.4)
4. ENISA, Technical Implementation Guidance mapping table, version 1.2 (XLSX)
5. NIST Special Publication 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations (controls AC-2 and AC-6(7))