NIS2 Access Control Checklist for IT Teams

If your organisation falls under NIS2, access control is not a side note, it is one of the explicit risk-management measures in Article 21. This NIS2 access control checklist walks through what "essential" and "important" entities actually need to have in place, in plain IT terms rather than legal language, so you can turn a directive into a working setup.

NIS2 does not hand you a technical standard to implement. It sets outcomes: access to network and information systems must be managed, policies must exist, and you must be able to demonstrate that both hold up over time. That leaves a lot of interpretation to IT and security teams, which is exactly where a checklist earns its keep.

This article stays practical. It is not legal advice, and no tool makes you NIS2 compliant on its own. What follows is a checklist you can work through with your Microsoft environment, Entra ID and on-prem Active Directory, plus where automation removes the manual grind that usually breaks these controls within a year.

What NIS2 Article 21 actually expects from access control

Article 21 lists access control policy and asset management among the baseline cybersecurity risk-management measures. Translated into IT reality, entities need to show three things:

• Access is granted based on a defined policy, not ad hoc requests approved over chat.
• Access is reviewed and adjusted as roles, employment status, and risk change.
• There is a record of who had access to what, and when, that can be produced during an audit or after an incident.

None of this is new to security teams. What NIS2 changes is the stakes: for essential and important entities, supervisory authorities can now check and enforce it, and management can be held personally accountable for governance failures.

Essential vs important entities

The checklist below applies to both categories. The main practical difference is the level of supervisory scrutiny and the incident-reporting obligations, not the substance of what good access control looks like. If you are unsure which category your organisation falls into, that determination sits with legal and compliance, not IT, but the access-control work is the same either way.

The NIS2 access control checklist

Work through this in order. Each item maps to something an auditor or a national authority is likely to ask for.

1. Written access control policy. Define who can request access, who approves it, and on what basis (role, department, project). This does not need to be long, it needs to be followed.
2. Least privilege as the default. New accounts and role changes start with the minimum access needed, not a copy of a colleague's permissions "to be safe."
3. A single source of truth for identity attributes. Job title, department, location and employment status should live in one place, typically HR or your identity provider, and drive access decisions consistently.
4. Automated provisioning and deprovisioning. Joiners get access on day one, movers get access adjusted when their role changes, leavers lose access immediately, not at the next manual cleanup.
5. Periodic access reviews. Group and role memberships get checked against current attributes on a set cadence, and owners confirm or correct what they see.
6. Privileged and administrative access under extra scrutiny. Admin roles in Entra ID and AD should be smaller in number and reviewed more frequently than standard user access.
7. An audit trail of every access change. Grants, revocations, and the reason behind each one, retained long enough to reconstruct "who had access to what, and when" for an incident investigation or supervisory request.
8. Multi-factor authentication on privileged and remote access. NIS2 explicitly calls out MFA and secure authentication as a baseline measure.
9. Documented incident-response link to access. When something goes wrong, you need to be able to quickly answer which accounts and groups were involved, which requires the audit trail above to actually be queryable.

Where this typically breaks down

In practice, most mid-market IT teams do not fail this checklist because they lack the intent. They fail because items 3 through 7 depend on manual, repeated effort: someone has to remember to update a group when a person changes department, someone has to run the quarterly review, someone has to keep the spreadsheet of who approved what. That works for a few months after an audit and then quietly decays until the next one.

Turning the checklist into a repeatable process

The fix is not a bigger policy document, it is removing the manual steps that a policy depends on humans repeating correctly every time.

Attribute-based access instead of manual group management

If group and role membership in Entra ID and on-prem AD is driven by attributes such as department, location, and job title, item 4 (provisioning and deprovisioning) and item 3 (single source of truth) stop being separate manual tasks and become one automated rule. When HR updates a department field, the person's group memberships update with it, on the same day, without a ticket. This is the core of what ServiceChanger's access automation does: it evaluates your existing attributes and keeps Entra ID and AD group and role membership in line with them, using group mining to surface the patterns already implicit in your environment so you are not starting the rule-building from a blank page.

Access reviews that owners can actually complete

Item 5, periodic reviews, is where audit fatigue sets in fastest when reviewers are handed a raw export of every group member with no context. Reviews go faster and stay accurate when the reviewer sees who holds access, which attribute justifies it, and what is off-pattern, rather than a flat list they have to investigate manually.

An audit trail that answers "who had access when"

For item 7, the audit trail needs to record the attribute or approval that triggered each change, not just the change itself. "User X was added to Group Y on this date because department changed to Finance" is evidence. "User X is in Group Y" is not.

A self-service layer for exceptions

Not everything can or should be attribute-driven. Item 1's policy needs a path for requests that fall outside the standard rule set, project access, a temporary need, a one-off exception. A self-service portal where requests are evaluated against policy and routed to the right owner keeps those exceptions inside the same governed process instead of becoming an email thread nobody can reconstruct later.

A quick reference table

Checklist item	Manual approach	Automated approach
Provisioning on day one	Ticket + manual group add	Attribute triggers group membership
Deprovisioning on departure	Manual offboarding checklist	Access follows attribute change automatically
Periodic access review	Raw group export, reviewer investigates	Reviewer sees attribute justification per member
Audit trail	Scattered logs across systems	Single log of attribute, group, actor, timestamp

FAQ

Does NIS2 require a specific access control tool? No. NIS2 sets outcomes, not a mandated product or technical standard. You need a documented policy, least privilege, timely provisioning and deprovisioning, periodic reviews, and an audit trail. How you achieve that is up to your organisation, though manual processes tend to degrade faster than automated ones between audits.

Does ServiceChanger make us NIS2 compliant? No single tool does. ServiceChanger automates attribute-driven group and role membership in Entra ID and on-prem AD, and logs every change, which produces evidence for the access-control parts of Article 21. Compliance as a whole runs through your management system and your auditor.

Do essential and important entities need different access controls? The supervisory and reporting obligations differ between the two categories, but the substance of good access control, least privilege, timely joiner/mover/leaver handling, reviews, and an audit trail, is the same for both.

How does this relate to license management under NIS2? NIS2 does not mandate license tracking directly, but unused or over-privileged accounts often carry paid Microsoft licenses nobody is watching. Visibility into actual sign-in activity and seat usage is a useful side effect of good access hygiene, even if it sits outside Article 21 itself.

Next step

Checking your own environment against this list is a good starting point before an audit forces the issue. If you want to see how attribute-driven access and an audit trail look against your own Entra ID and on-prem AD, book a demo and we'll walk through it together. You can also read more on the access governance, digital security and compliance page, or browse related posts in compliance and access control.