Role Change Processing

Role change processing updates a staff member’s IT access to match their new position within the organisation. You perform this task when someone transfers between departments, receives a promotion, moves to a different project, or otherwise changes their job function in a way that affects what systems and data they should access. The outcome is access that precisely matches the new role’s requirements, with previous access removed to prevent privilege creep, the accumulation of access rights that occurs when permissions granted for previous roles persist after those roles end.

Prerequisites

Verify you have the role change request documentation before proceeding. A complete request includes the staff member’s current role, new role, effective date, and both manager approvals. Incomplete requests cause delays and create audit gaps.

Procedure

1. Document current access state

   Export the staff member’s current access before making changes. This creates a baseline for comparison and provides rollback information if problems occur.

   In Microsoft Entra ID:

   # Export user's group memberships
   $user = Get-MgUser -UserId "jane.smith@example.org"
   $groups = Get-MgUserMemberOf -UserId $user.Id
   $groups | Select-Object Id, DisplayName | Export-Csv -Path "jane.smith_groups_$(Get-Date -Format 'yyyy-MM-dd').csv"

   # Export application role assignments
   $appRoles = Get-MgUserAppRoleAssignment -UserId $user.Id
   $appRoles | Select-Object AppRoleId, ResourceDisplayName, CreatedDateTime | Export-Csv -Path "jane.smith_apps_$(Get-Date -Format 'yyyy-MM-dd').csv"

In Okta:

   # List user's group memberships
   okta users groups list --user-id jane.smith@example.org --output json > jane.smith_groups_$(date +%Y-%m-%d).json

   # List application assignments
   okta users apps list --user-id jane.smith@example.org --output json > jane.smith_apps_$(date +%Y-%m-%d).json

Store these exports in the IT service management system attached to the role change ticket. Retain for 12 months for audit purposes.

2. Compare current access against new role requirements

   Create an access comparison that identifies three categories: access to retain (required in both roles), access to add (required in new role only), and access to remove (required in old role only).

   For a staff member moving from Programme Officer in the Health team to Programme Manager in the WASH team, the comparison might identify:

   Access item	Current role	New role	Action
   All Staff group	Required	Required	Retain
   Health Programme group	Required	Not required	Remove
   WASH Programme group	Not required	Required	Add
   Programme Data (read)	Required	Required	Retain
   Programme Data (write)	Not required	Required	Add
   Health M&E system	Required	Not required	Remove
   WASH M&E system	Not required	Required	Add
   Budget approval (up to £5,000)	Not required	Required	Add
   Grants management system	Read only	Read/write	Modify

   Document this comparison in the change ticket. The new manager must confirm that the “Add” items are correct for the role. The current manager must confirm that the “Remove” items are no longer needed.

3. Remove access no longer required

   Remove old access before adding new access. This ordering prevents a window where the staff member has elevated combined privileges and ensures that access removal happens even if the process is interrupted.

   In Microsoft Entra ID, remove group memberships:

   # Remove from old department group
   Remove-MgGroupMember -GroupId "health-programme-group-id" -DirectoryObjectId $user.Id

   # Remove from application-specific groups
   Remove-MgGroupMember -GroupId "health-me-system-users" -DirectoryObjectId $user.Id

For applications with direct role assignments rather than group-based access:

   # Remove application role assignment
   Remove-MgUserAppRoleAssignment -UserId $user.Id -AppRoleAssignmentId "assignment-id"

In application-specific admin consoles, remove any access that is not controlled through your identity provider. Document each removal in the change ticket.

4. Add access for the new role

   Add group memberships and application access required for the new role.

   In Microsoft Entra ID:

   # Add to new department group
   New-MgGroupMember -GroupId "wash-programme-group-id" -DirectoryObjectId $user.Id

   # Add to application groups
   New-MgGroupMember -GroupId "wash-me-system-users" -DirectoryObjectId $user.Id
   New-MgGroupMember -GroupId "budget-approvers-5000" -DirectoryObjectId $user.Id

For applications requiring direct provisioning:

   # Assign application role
   $params = @{
       PrincipalId = $user.Id
       ResourceId = "grants-management-app-id"
       AppRoleId = "readwrite-role-id"
   }
   New-MgUserAppRoleAssignment -UserId $user.Id -BodyParameter $params

Some applications require manual provisioning through their admin interfaces. Complete these in order of operational priority: email and collaboration access first, then programme systems, then supporting applications.

5. Update distribution lists and shared resources

   Transfer membership in distribution lists, shared mailboxes, and collaborative spaces from old team to new team.

   Distribution lists:

   # Remove from old distribution lists
   Remove-DistributionGroupMember -Identity "health-team@example.org" -Member "jane.smith@example.org"

   # Add to new distribution lists
   Add-DistributionGroupMember -Identity "wash-team@example.org" -Member "jane.smith@example.org"
   Add-DistributionGroupMember -Identity "programme-managers@example.org" -Member "jane.smith@example.org"

Shared mailboxes and calendars:

   # Remove access to old shared mailbox
   Remove-MailboxPermission -Identity "health-inbox@example.org" -User "jane.smith@example.org" -AccessRights FullAccess

   # Grant access to new shared mailbox
   Add-MailboxPermission -Identity "wash-inbox@example.org" -User "jane.smith@example.org" -AccessRights FullAccess

Update SharePoint site permissions, Teams channel memberships, and shared drive access according to the new team’s collaboration structure.

6. Handle data and knowledge transition

   Coordinate the transfer of work-in-progress from the staff member’s old role. This is not about copying their personal files, but about ensuring continuity of organisational knowledge and work products.

   Work with the staff member to identify:

   • Active documents that should transfer to the old team’s shared storage
   • Pending items that need handover to colleagues
   • Institutional knowledge that should be documented before the transition

   Move completed work products to team shared storage:

   # Example: Moving project files to team location
   # Staff member should do this themselves; IT supports if needed
   Move-Item -Path "C:\Users\jane.smith\Documents\Health Projects\*" -Destination "\\fileserver\Health\Completed Projects\2024\"

The staff member retains their personal files and email history. Do not delete or transfer personal OneDrive content without explicit instruction.

7. Update identity attributes

   Modify directory attributes to reflect the new role. These attributes control access to conditional access policies, appear in the global address list, and feed into reporting systems.

   Update-MgUser -UserId $user.Id -Department "WASH" -JobTitle "Programme Manager" -Manager @{
       "@odata.id" = "https://graph.microsoft.com/v1.0/users/new-manager-id"
   }

Update custom attributes if your organisation uses them for access control:

   Update-MgUser -UserId $user.Id -AdditionalProperties @{
       "extension_CostCentre" = "WASH-001"
       "extension_AccessLevel" = "Manager"
   }

Allow 15-60 minutes for attribute changes to propagate through connected systems. Cloud applications using SCIM provisioning update automatically; on-premises applications using directory sync update on the next sync cycle.

8. Configure training requirements

   New access often requires additional training before use. Configure training assignments in your learning management system or track them manually.

   For access to sensitive systems, you may need to verify training completion before activating access. In this case, add the user to a “pending training” group rather than the full access group:

   # Grant provisional access pending training
   New-MgGroupMember -GroupId "wash-me-system-pending" -DirectoryObjectId $user.Id

   # After training completion, move to full access
   # (This step happens later, after training confirmation)
   Remove-MgGroupMember -GroupId "wash-me-system-pending" -DirectoryObjectId $user.Id
   New-MgGroupMember -GroupId "wash-me-system-users" -DirectoryObjectId $user.Id

Document training requirements in the change ticket and set a follow-up date to verify completion.

9. Notify the staff member and managers

   Send confirmation to all parties documenting the changes made.

   Subject: IT Access Updated - Role Change to Programme Manager, WASH

   Dear Jane,

   Your IT access has been updated to reflect your new role as Programme Manager
   in the WASH team, effective 15 January 2025.

   Access added:
   - WASH Programme SharePoint site and Teams channel
   - WASH M&E system (full access)
   - Grants management system (read/write, upgraded from read-only)
   - Budget approval workflow (up to £5,000)
   - WASH team distribution list and shared mailbox

   Access removed:
   - Health Programme SharePoint site and Teams channel
   - Health M&E system
   - Health team distribution list and shared mailbox

   Training required before use:
   - Budget approval system orientation (contact Finance)
   - Grants management write access training (contact Grants team)

   If you experience any access issues or believe this list is incorrect,
   please contact the IT Service Desk immediately.

   Regards,
   IT Team

Copy both the releasing and receiving managers. Retain this notification in the change ticket.

10. Schedule access review

    Set a follow-up review for 30 days after the role change to verify that access is appropriate and that the staff member has not retained access from their previous role through alternative paths.

    Create a calendar reminder or service desk ticket:

    Subject: 30-day Access Review - Jane Smith Role Change
    Due: 14 February 2025

    Verify:
    - No residual Health team access remains
    - WASH team access is functioning correctly
    - Training requirements completed
    - No privilege creep from interim workarounds

This review catches cases where the staff member was added back to old groups due to operational pressures or where indirect access paths were missed in the initial change.

Handling transition periods

Role changes do not always happen cleanly on a single day. A staff member may need to wrap up responsibilities in their old role while beginning work in their new role. This transition period requires temporary dual access.

When a transition period is necessary, document it explicitly in the change ticket with a defined end date. Configure calendar reminders for yourself to remove the old role access on that date. Transition periods should not exceed 30 days; if longer is requested, require director-level approval and document the business justification.

During the transition period:

# Add new role access
New-MgGroupMember -GroupId "wash-programme-group-id" -DirectoryObjectId $user.Id

# Retain old role access temporarily - document this exception
# Set reminder to remove on transition end date

On the transition end date, complete the access removal steps even if the staff member requests an extension. Extensions require fresh approval and create their own audit trail.

Privilege creep detection

Privilege creep occurs when staff members accumulate access from successive role changes without corresponding removals. Each role change should result in a net-neutral or net-negative change in total access count, not a net increase. The access comparison step in the procedure addresses this directly, but additional mechanisms help detect creep that bypasses normal procedures.

Review the staff member’s total access count during role changes:

$user = Get-MgUser -UserId "jane.smith@example.org"
$totalGroups = (Get-MgUserMemberOf -UserId $user.Id -All).Count
$totalApps = (Get-MgUserAppRoleAssignment -UserId $user.Id -All).Count

Write-Host "Total group memberships: $totalGroups"
Write-Host "Total application assignments: $totalApps"

Compare against typical values for the new role. A Programme Manager role might typically have 15-25 group memberships. If the staff member has 40+ after the role change, investigate the excess.

The access comparison matrix from step 2 provides visibility into creep:

+-------------------------------------------------------------------+
|                    PRIVILEGE CREEP INDICATOR                      |
+-------------------------------------------------------------------+
|                                                                   |
|  Access count before role change:     18 groups, 12 apps          |
|  Expected for new role:               20 groups, 14 apps          |
|  Access count after role change:      35 groups, 22 apps          |
|                                                                   |
|  +-------------------------------------------------------------+  |
|  |  WARNING: Net increase of 17 groups and 10 apps             |  |
|  |  Review for residual access from previous roles             |  |
|  +-------------------------------------------------------------+  |
|                                                                   |
+-------------------------------------------------------------------+

When you detect potential creep, review each access item against the current role’s documented requirements. Remove any access that cannot be justified by the current role, regardless of how it was originally granted.

Verification

After completing the role change, verify that access is correct using both technical checks and functional confirmation.

Technical verification:

Export post-change access and compare against the expected state:

$postGroups = Get-MgUserMemberOf -UserId $user.Id
$postApps = Get-MgUserAppRoleAssignment -UserId $user.Id

# Verify old role groups removed
$oldRoleGroups = @("health-programme-group-id", "health-me-system-users")
foreach ($groupId in $oldRoleGroups) {
    if ($postGroups.Id -contains $groupId) {
        Write-Warning "FAIL: User still member of $groupId"
    } else {
        Write-Host "PASS: User removed from $groupId"
    }
}

# Verify new role groups added
$newRoleGroups = @("wash-programme-group-id", "wash-me-system-users")
foreach ($groupId in $newRoleGroups) {
    if ($postGroups.Id -contains $groupId) {
        Write-Host "PASS: User added to $groupId"
    } else {
        Write-Warning "FAIL: User not member of $groupId"
    }
}

Functional verification:

Request that the staff member confirm they can access required systems and cannot access old systems. Provide a simple checklist:

Please verify your access and reply confirming each item:

Can access (should work):
[ ] WASH team SharePoint site
[ ] WASH M&E system
[ ] Grants management system (can edit, not just view)
[ ] WASH team shared mailbox

Cannot access (should be denied):
[ ] Health team SharePoint site
[ ] Health M&E system
[ ] Health team shared mailbox

Any issues? Describe:
_______________________

Verification passes when all technical checks pass and the staff member confirms both positive access (can reach new systems) and negative access (cannot reach old systems).

Troubleshooting

See also

• User Onboarding for new access provisioning procedures
• User Offboarding for access removal procedures
• Access Recertification for periodic access review procedures
• Access Reviews and Recertification for access review concepts
• Identity and Access Management for identity lifecycle concepts
• Access Control Standard for access control requirements