An employee does not need to leave Wire Finance for their access requirements to change.
They might move to another department.
Receive a promotion.
Take on a temporary assignment.
Change responsibilities.
Gain or lose privileged duties.
Or move into a role that requires completely different systems and information.
These changes create one of the easiest ways for unnecessary access to accumulate.
Imagine someone moves from Sales to Operations.
The simplest approach would be:
Existing Sales Access
+
New Operations Access
The employee can now perform their new job.
But they may also still have access to systems and information from a job they no longer perform.
That is exactly what the Mover process is designed to prevent.
The Mover Process
The purpose of the Mover process is to keep an existing employee’s identity and access aligned with their current business responsibilities.
A role change should not simply add new access.
It should also remove access that is no longer justified.
Conceptually, the process looks like this:
Approved Business Change
│
▼
Current Identity Reviewed
│
▼
New Department / Role / Responsibility Confirmed
│
▼
Identity Attributes Updated
│
▼
Normal Access Recalculated
│
▼
Exceptions + Privileged Access Reassessed
│
▼
Assigned Access Reviewed
│
▼
New Access State Validated
The goal is not:
give the employee more access.
It is:
recalculate what their access should now be.
The Change Must Start With the Business
Just like the Joiner process, a Mover event should begin with an approved business change.
The technical identity should not change simply because somebody asks IT to move an account into another group.
Wire Finance should first understand what has actually changed.
Examples include:
- department change
- job-role change
- promotion
- demotion
- temporary assignment
- responsibility change
- employment-type change
- location change where relevant to access requirements
- manager change where responsibilities or approvals are affected
- gain or loss of privileged duties
Not every change will require the same technical response.
A manager change, for example, may have little effect on access if the employee’s responsibilities remain unchanged.
A move from Sales to Operations may change much more.
The important question is:
does this business change affect what the employee should be able to access?
Trusted Attributes Drive Normal Access
Wire Finance uses trusted identity attributes to represent predictable organisational relationships.
Important examples include:
- company
- department
- job title
- user type
- account status
These attributes are security-relevant because they can influence dynamic group membership.
For example:
department = Sales
↓
SG-DEPT-SALES-USERS
jobTitle = Sales Representative
↓
SG-ROLE-SALES-REPRESENTATIVE
If the employee moves into Operations, the approved business change should result in the corresponding attributes being updated.
department = Operations
↓
SG-DEPT-OPERATIONS-USERS
jobTitle = Operations Specialist
↓
SG-ROLE-OPERATIONS-SPECIALIST
The important principle is:
change the trusted business attributes that describe the employee, then allow the access model to respond.
We should not manually maintain organisational group membership if those relationships are intended to be attribute-driven.
Recalculating Effective Access
The access-baseline model becomes particularly useful during a Mover event.
Normal access can be recalculated as:
New Effective Access
=
Company Baseline
+
New Department Baseline
+
New Role Baseline
+
Re-approved Exceptions
-
Obsolete Access
The final part matters:
minus obsolete access.
Without removal, every promotion, department change, or temporary responsibility risks becoming another layer of permanent entitlement.
A successful Mover process therefore asks two questions at the same time:
What must be added?
+
What must be removed?
Noah Moves From Sales to Operations
Consider Noah Williams.
Noah currently works as a Sales Representative.
His organisational attributes might conceptually look like:
Noah Williams
companyName = Wire Finance
department = Sales
jobTitle = Sales Representative
Those attributes establish relationships such as:
SG-BASE-ALL-STAFF
+
SG-DEPT-SALES-USERS
+
SG-ROLE-SALES-REPRESENTATIVE
Now Noah is approved to move into Operations as an Operations Specialist.
The wrong approach would be to keep everything he already has and simply add:
SG-DEPT-OPERATIONS-USERS
+
SG-ROLE-OPERATIONS-SPECIALIST
That would create access accumulation.
Instead, Wire Finance updates the trusted attributes that describe Noah’s new position:
OLD
department = Sales
jobTitle = Sales Representative
↓
Approved Mover Event
↓
NEW
department = Operations
jobTitle = Operations Specialist
The expected group relationships then change with him.
REMOVE / FALL OUT OF
SG-DEPT-SALES-USERS
SG-ROLE-SALES-REPRESENTATIVE
↓
RETAIN
SG-BASE-ALL-STAFF
↓
ADD / ENTER
SG-DEPT-OPERATIONS-USERS
SG-ROLE-OPERATIONS-SPECIALIST
The company-wide baseline remains because Noah still works for Wire Finance.
His department and role relationships change because his responsibilities have changed.
Dynamic Membership Helps Remove Old Access
This is one of the reasons Wire Finance uses dynamic membership for predictable organisational relationships.
When an approved attribute changes, the relevant group memberships can be reevaluated.
Conceptually:
department = Sales
↓
Sales Group
changes to
department = Operations
↓
Operations Group
The old relationship no longer matches.
The new one does.
This makes the access model much safer than continuously adding groups by hand and hoping somebody remembers to remove the previous ones.
But dynamic membership does not solve everything.
Some access exists because of an explicit decision rather than an employee attribute.
That access must be reviewed separately.
Assigned Access Must Be Reviewed Deliberately
Wire Finance also uses Assigned membership where automatic membership would not be appropriate.
Examples include:
- pilot membership
- licence assignment during the current pilot
- approved exception access
- privileged administrative assignments
A Mover event therefore needs to distinguish between:
Attribute-driven access
↓
Recalculate automatically where appropriate
Assigned access
↓
Review deliberately
For example, Noah’s membership in the Microsoft 365 E5 licensing group may still be required after moving departments.
That relationship may be classified as:
Retain.
An old Sales-specific exception may no longer be justified.
That relationship may be:
Remove.
Privileged access may require:
Reapprove.
The important point is that these assignments should not silently follow the employee into a new role simply because they already exist.
The Access Review Decision
During a Mover review, Wire Finance can classify existing and required access according to what should happen next.
| Classification | Meaning | Action |
|---|---|---|
| Retain | Still required in the new position | Keep |
| Remove | No longer justified | Remove |
| Add | Required for the new responsibility | Add |
| Review | Business need is uncertain | Obtain clarification or approval |
| Expire | Temporary access has reached its end | Remove |
| Reapprove | Sensitive or privileged access may still be required | Require fresh approval |
This gives the review more precision than simply asking whether access exists.
For each important relationship, the question becomes:
Keep it?
Remove it?
Add something new?
Review it?
Let it expire?
Require fresh approval?
Exception Access Does Not Automatically Follow
Exception access exists precisely because the capability sits outside the employee’s normal baseline.
That means a Mover event should trigger a fresh look at whether the exception still makes sense.
Suppose Noah had received temporary access to a Sales-specific resource.
Sales Role
+
Approved Sales Exception
After moving into Operations, the organisation should not assume:
New Operations Role
+
Old Sales Exception
Instead:
Existing Exception
│
▼
Mover Event
│
▼
Business Need Reassessed
/ \
/ \
Still No Longer
Needed Needed
│ │
▼ ▼
Reapprove Remove
Sensitive access should survive a role change because it is still justified, not because it already exists.
Privileged Access Requires Its Own Review
The same principle applies even more strongly to privileged access.
A job change may affect:
- whether a privileged identity is still required
- which
PAG-*groups remain appropriate - which administrative roles are still justified
- whether elevated access should be removed completely
- whether different privileged capability is required
For example:
Old Job Responsibility
↓
Existing Privileged Access
↓
Mover Event
↓
Reassess Administrative Need
The privileged identity should not simply carry every old administrative permission into the employee’s next role.
If a privileged capability no longer has a business justification, it should be removed.
If a different administrative capability is needed, that should follow the appropriate approval path.
A Mover Can Also Reduce Access
Not every Mover event is a promotion or expansion of responsibility.
Someone may:
- move into a less privileged role
- stop performing administrative work
- leave a temporary project
- lose responsibility for a sensitive dataset
- return from a temporary assignment
The Mover process therefore needs to work in both directions.
More Responsibility
↓
Possible New Access
Less Responsibility
↓
Access Removal
A mature identity model does not assume career movement always means more permissions.
Sometimes the correct security outcome is fewer permissions.
Devices and Applications May Also Change
A change in responsibility may affect more than directory access.
Depending on the role, Wire Finance may need to review:
- required applications
- application assignments
- device requirements
- endpoint configuration
- licence requirements
- access to departmental collaboration resources
For example, moving into a role that requires privileged administration may eventually change the type of device or workstation the employee should use.
Those endpoint decisions are handled through the Device Provisioning Model and Intune implementation.
The lifecycle process simply provides the business trigger for reviewing them.
Validate the New Access State
Changing the identity is not the end of the Mover process.
The new state needs to be validated.
Wire Finance should be able to answer:
Are the employee's attributes correct?
↓
Did obsolete dynamic memberships disappear?
↓
Did new expected memberships appear?
↓
Were assigned groups reviewed?
↓
Was obsolete exception access removed?
↓
Was privileged access reassessed?
↓
Are licences and applications still appropriate?
↓
Can the employee perform the new job?
↓
Can they still access anything they should no longer have?
That final question is particularly important.
Mover validation should test both:
what the employee gained
and:
what the employee lost.
An employee being able to perform their new responsibilities does not prove that the Mover process succeeded if old access remains behind.
The Mover Process Is Complete
The full Mover journey can now be expressed as:
Approved Business Change
↓
Current Access Reviewed
↓
Trusted Attributes Updated
↓
Dynamic Membership Recalculated
↓
Obsolete Access Removed
↓
New Normal Access Added
↓
Assigned Access Reviewed
↓
Exceptions Reapproved or Removed
↓
Privileged Access Reassessed
↓
Applications / Licence / Device Reviewed
↓
New Access State Validated
The principle behind all of this is simple:
access should follow the employee’s current responsibility, not accumulate from every responsibility they have ever held.
A Mover event is therefore not merely an opportunity to grant access.
It is an opportunity to recalculate access from a clean business position.
Eventually, however, the relationship itself comes to an end.
When someone leaves Wire Finance, the problem changes again.
We are no longer asking what access should change.
We need to determine what should be removed, revoked, recovered, transferred, or preserved.
That is the Leaver process.