When someone changes role, when do they lose their old access?

Start

HR records a move, with its date

Movers are where access builds up: new access is asked for at once, and old access is rarely given back. The pack's mover rule therefore removes the old role by default, and anything still needed is asked for again. A new job, a new department or a new line manager is a move, and so is a return from long absence to a different job.

• Then: List everything the person holds now, in every system

Step

List everything the person holds now, in every system

Take the list from the provisioning log and from each system itself, including non-standard rights and anything left from earlier roles. Local accounts outside single sign-on count. This list is the starting point for the conflict check and for knowing what has to be removed.

• Then: Has the old line manager recorded a handover?

Decision

Has the old line manager recorded a handover?

A handover is recorded by the old line manager before the move date. It names which old access is still needed and until when. Without one, there is no overlap: the old access goes on the move date. A handover someone mentions but nobody recorded does not count.

• Yes, recorded before the move date: Note which old rights stay, and the end of the handover
• No, or not known: Plan the old access to go on the move date

Step

Plan the old access to go on the move date

With no recorded handover, the mover window closes on the move date itself. Make the mover request replace the old profile with the new one, so removal happens with the grant. A request that only adds access leaves the old role in place unless someone remembers to remove it.

• Then: Would the resulting access hold both sides of a conflict?

Step

Note which old rights stay, and the end of the handover

Only the old access the handover names may stay, and only until the date it gives. That date is no later than 5 working days after the move date by the pack's default. The handover lists which old access is needed, so old access it does not name has no reason to stay: the safer reading is to remove it on the move date.

• Then: Would the resulting access hold both sides of a conflict?

Decision

Would the resulting access hold both sides of a conflict?

Resulting access is everything the person will hold after the change: the base profile, the new profile, non-standard rights and any old access they keep, even for a handover. Check every pair against the conflict matrix. Checking only the new profile is the mistake that lets a mover hold both sides of a conflict, as when an accounts payable clerk who keeps supplier bank details becomes the person who approves payments.

• Yes, or not known: Can one of the two rights be removed?
• No: Grant the new role's profile from the move date

Decision

Can one of the two rights be removed?

A conflict that can be separated is separated, and that needs no exception. Ask first whether the old right is still needed at all: in the pack's example, handover work did not need the bank details right, so it went. Only a conflict that cannot be separated, usually because the team is too small, goes to the exception process.

• Yes: Remove the conflicting right before the new profile goes on
• No: Grant nothing until it is accepted as an exception

Step

Remove the conflicting right before the new profile goes on

The line manager and the system owner decide which of the two rights goes. Remove it and confirm the removal in the system before anything is granted. If the right was named in the handover, the handover loses it.

• Then: Grant the new role's profile from the move date

Outcome

Grant nothing until it is accepted as an exception

A conflict that cannot be separated is scored as an exception, protected by a compensating control run by someone without the conflict, and approved at the level its band sets. At High that is the Head of Information Security with the accountable executive, for no more than 90 days by the pack's default. At Critical it is the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, executive management.

Step

Grant the new role's profile from the move date

The new line manager confirms which profile the new job needs. Profile access needs no further approval, because the profile was approved in advance by its owner and each system owner. Anything the new job needs outside the profile is a separate non-standard request.

• Then: Does the person hold privileged access the new role doesn't need?

Decision

Does the person hold privileged access the new role doesn't need?

Administrator, emergency and service account access follows the privileged access rules, which are stricter here. Check the privileged account inventory and each system, not only the old profile: privileged access is never in a role profile. If you cannot tell, take the yes branch and list it.

• Yes, or not known: Remove it on the move date and change what they could read
• No: Is any old access still needed after the window closes?

Step

Remove it on the move date and change what they could read

Privileged access the new role does not need is removed on the day the move takes effect. The handover window never applies to it. Every shared, service and break-glass credential the person could read is changed within 1 working day by the pack's default, and they come off the on-call approver list and the safe list the same day.

• Then: Is any old access still needed after the window closes?

Decision

Is any old access still needed after the window closes?

The question is whether the new job cannot be done without it. Access is not needed because the person used to need it, or because removing it might cause a support call. Leaving old access in place until someone has settled in is exactly what the mover rule rules out.

• Yes: Request it as non-standard access before the window closes
• No: Remove the old role's access when the window closes

Step

Request it as non-standard access before the window closes

The line manager asks on the access request form, with a business reason and an expiry no more than 6 months ahead by the pack's default. The line manager and the owner of the system or data both approve it, and the conflict check runs again. Old access not requested before the window closes is removed.

• Then: Remove the old role's access when the window closes

Step

Remove the old role's access when the window closes

Remove every old right the new profile does not include, on the move date or at the end of the recorded handover. The service desk removes access in systems on single sign-on; the named administrator of each system with local accounts removes those. Send each task to a named person: the pack's late leaver removal came from a task sent to a shared mailbox.

• Then: Is every removal confirmed in its system?

Decision

Is every removal confirmed in its system?

A removal is complete only when it is confirmed in the system, from its user list, audit log or account status. A closed ticket is not confirmation. Record each confirmed removal in the provisioning log the same day.

• No, or not known: Escalate now: residual access is a finding
• Yes: Old access gone; the month-end check confirms it

Outcome

Escalate now: residual access is a finding

Call the named administrator, then the system owner. If the access cannot be removed, block sign-in at the gateway where possible and record the removal as late. Access a mover still holds after the window is residual access: it is raised with the access review as a finding, and a repeated cause goes to the process owner as a process weakness.

Outcome

Old access gone; the month-end check confirms it

At each month end the reconciliation checks every mover whose window closed in the month and confirms the old role's access is gone from every system. A clean result for movers is the evidence that the mover rule works.