Think of the last person in your company who changed roles. They probably kept the same laptop, and that's fine. What else came with the old job is most likely still there too: access to systems they no longer work in, admin rights in a tool someone else now runs, and a licence they no longer open, quite possibly still charged to the old team's cost centre. 

That's one of three moments where what someone holds at work is supposed to change. 

The other two get more attention: a joiner needs a working setup on their first  day at work, and a leaver's laptop, licences and phone subscription have to be closed out. Each of the three goes wrong in a different way, which is why a single fix for "onboarding and offboarding" is not bulletproof. Under NIS2 that matters more than it used to. One organisation we spoke to described the change as going from something they did for convenience to something they're now required to do.

Our earlier piece covered NIS2 asset management and why evidence is the hard part. This one is about access control and the joiners, movers and leavers (JML) process behind it: where each stage breaks, and what it looks like when access follows the role.

TL;DR

• NIS2 Article 21(2)(i) lists human resources security, access control policies and asset management together, as one of ten areas of security measures.
• Operationally, the three meet in the employee lifecycle: joiners, movers and leavers, with access and IT assets that match the person's current role.
• Each stage has different challenges. Joiners are set up against the clock, movers often get no process at all, and leavers get a process that's marked done before it's finished.
• When the HR system triggers all three, access and IT assets follow the role, and the record of every step builds up as it happens.

What are the NIS2 access control requirements?

Article 21(2)(i) of Directive (EU) 2022/2555 requires organisations in scope to take appropriate and proportionate measures covering "human resources security, access control policies and asset management". It is one of ten areas of security measures listed in Article 21(2), and under Article 20, management has to approve those measures and take training on them.

The directive itself doesn't say how to meet that. Commission Implementing Regulation (EU) 2024/2690 fills in part of it for digital infrastructure providers: an up-to-date asset inventory, and procedures to make sure assets held by staff are returned or deleted when employment ends, with the return documented. It only binds that group directly, but it's the clearest reference available for what "appropriate" is likely to look like for everyone else.

In Sweden, cybersäkerhetslagen has applied since January 2026, and the regulator's more detailed rules on security measures and management training start applying on 1 October 2026.

What does NIS2 say about onboarding and offboarding?

NIS2 covers onboarding and offboarding indirectly, through that line in Article 21(2)(i), and never uses either word. Turning that into a process is up to you.

Operationally, the three meet in the employee lifecycle. Human resources security covers who works here, in which role, from when to when. Access control covers what those people can reach, and asset management covers what they hold: the laptop, the phone and its subscription, the software licences. In practice the employment record ties them together, so when it changes, access and assets should change with it. Onboarding and offboarding are the two ends of that flow, and every role change sits somewhere in between.

Where does the JML process break?

In three different places, one per stage. That's worth knowing before you fix anything, because a fix built for one stage usually does little for the other two.

Joiners: set up against the clock

Joiners are the stage that gets noticed. A new hire who can't log in on their first day is a visible problem, and it's usually fixed that morning. The weak point is the input. The start date is often in the calendar weeks ahead, but what the person needs reaches IT through a manager, and that's where things go missing. 

Under that pressure, the aim is a working setup by the first morning. Whether it matches the role is a question that gets asked later, if at all, and under NIS2 it's the question that counts.

Movers: no process at all

Nothing in the usual process prompts anyone to act on a role change. Someone moves from customer support into customer success, or gets promoted to lead the team they were part of, and arrives in the new role with everything from the old one still attached. Nothing breaks, and nobody has a reason to raise it.

Where there is a process, it tends to be the same manager's form that's meant to cover joiners and leavers too. One company we talked to said the form for onboarding, offboarding and changes often arrives incomplete, so IT ends up chasing what's actually needed. After a few role changes, what a person holds describes their career history better than their current job, and that's the gap an access review exists to find.

Leavers: a process that stops too early

Leavers usually do have a process, which is what makes this stage easy to overlook. The checklist exists, and it gets ticked, but the loop doesn't always close. One company we talked to rated their own offboarding at zero and said it was harder than onboarding, in systems and in process. Another said access rights and equipment collection aren't consistently carried out when people leave. A third reclaims licences by hand, from a weekly email listing everyone who has left.

Under NIS2, leavers are where the gap between a ticked task and the actual state shows most clearly.

Why doesn't a better checklist fix it?

A checklist records a task and when someone ticks "remove helpdesk admin rights", the box says so. What you'll want to show under NIS2 is the state the task was meant to produce: whether the access is actually gone, whether the licence went to someone else, whether the laptop is back. In other words: you need proof. A ticked box gives you the first record and says nothing about the second.

For movers there's usually no checklist at all, because the list only starts once someone tells IT the role changed. That's the case for running the flow off the HR system instead of adding more steps to a list.

What does a JML process look like when access follows the role?

A JML process holds up when the HR system is the trigger. When a hire, a role change or a departure is registered there, everything on the IT side follows from that event, instead of from a ticket, a manager's email or someone in IT happening to notice.

Joiners: The employee record exists before the start date, synced from the HR system and/or Directory. Role attributes such as title, department and cost centre decide which hardware, which licences and which budget come with the job, so the setup is ready on the new joiner’s first day, and matches the role from the start.

Movers: A change of title or department in the HR system becomes something IT can see when it happens, instead of noticing weeks later. Everything the person holds sits on one record, so "what should they still have?" gets answered in one place, with the hardware, licences and subscription laid out next to the new role.

Leavers: The departure date triggers the offboarding. Devices stay flagged until someone confirms they're physically back (or bought out), licences are revoked or reassigned, the mobile subscription is closed or scheduled to close, and each step is logged. We went through the device side of this in what happens to company laptops when employees leave.

That also covers the evidence problem from our earlier NIS2 article: each step is recorded as it happens, so there's nothing to piece together before an audit.

How do you know if access follows the role?

Pick one recent example of each: someone who joined, someone who changed role and someone who left. For the joiner, check whether what they got matches the role or just matches what was ready. For the mover, check when IT found out and what they lost. For the leaver, check whether everything is actually back, closed or reassigned, and whether you could show it.

If any of those answers is "we'd have to check", the fix starts upstream, with hires, role changes and departures registered in the HR system on time and reaching IT when they happen. There's more on that in our piece on HR data and the IT lifecycle. The rest of the flow can follow from there.