Treat a role move as two decisions
When a sales colleague becomes an operations manager, the obvious task is granting the tools needed for the new job. The less visible task is removing access that belonged only to the old job. Both decisions matter. A person can have a valid login and multi-factor authentication yet still hold permissions to records they no longer need. OWASP distinguishes authentication from authorization and recommends least privilege, including periodic checks for privilege creep. For a small business, the practical starting point is a dated change request that names the person, old duties, new duties, effective time and approving owner. Avoid a vague request to make the person an admin. Specify the actions the new role actually requires, such as viewing a shipment queue or changing a supplier order, because those operations carry different exposure and accountability.
Inventory access by system and action
List the applications the person can reach, including identity provider groups, ecommerce console, customer support, accounting, shared drives, analytics, cloud hosting and vendor portals. For each, record the account identity, current role or group, resource scope and permitted actions. Separate read, export, create, approve, edit and delete. A role label such as Manager can hide a wide range of powers, and a group inherited from an old project may add access outside the main console. OWASP advises enumerating user types, resources and operations when defining authorization. Apply that same grid to the role move. This is an access inventory, not a collection of passwords or secret tokens. If the person uses a shared account, identify it as a separate remediation problem: individual decisions and audit trails become difficult when several people use one identity.
Set the new baseline with an owner
Ask the receiving manager to confirm necessary tasks and the data needed to perform them; ask the owner of sensitive systems to approve exceptions. Start from a standard role if it truly fits, then narrow or extend only the documented differences. OWASP recommends denying access by default unless a permission has an explicit basis. This is especially useful when a product offers an overly broad preset administrator role. For instance, an operations lead may need to view order addresses and adjust fulfilment status, but not export the full customer database or alter payment settlement settings. The example is a decision framework, not a universal job description; each business must define its own separation of duties. Give temporary project access an owner and expiry date so it does not silently become permanent when the employee changes teams again.
Remove old access deliberately
Compare the old-role inventory with the approved new baseline and mark each entitlement keep, change or remove. Revoking an old group is not enough if a direct grant, delegated mailbox, vendor account or API tool grants the same power. Check both the application and any identity provider that provisions it; a local change may be overwritten by automatic group synchronisation. Schedule the effective time with the manager, particularly if the person is finishing a handover. Do not leave elevated access open indefinitely for convenience. Where a genuine handover needs short overlap, specify exactly which records and actions remain available, when that access ends and who will verify removal. Keep operational continuity through a named replacement owner, not through an unreviewed permission that anyone might reuse later.
Check the protected operation itself
A menu item disappearing is a useful interface signal, but it does not prove that the underlying action is blocked. OWASP says permissions should be validated on every request, and its authorization patterns guidance places enforcement close to the protected resource so the action, object and tenant can be checked. For the role change, test the actual read, export, edit and approval routes the employee formerly had. Confirm that removed access is denied even through a saved bookmark, direct API request or alternate workflow, while the new legitimate task still works. Test with a controlled account or approved test records; do not browse real customer data merely to demonstrate a denial. Where a system has organisation or branch boundaries, verify the new role is limited to the intended records, not every record bearing the same object type.
Work through one transfer
Imagine a support agent moving into warehouse coordination on Monday. On Friday, the manager lists new needs: see paid orders and delivery addresses, update dispatch state, and raise stock exceptions. The agent no longer needs the support mailbox, refund approval or the ability to export complaint histories. The system owner maps those needs to actual roles, checks whether any group also grants refund rights, and records a short overlap for unfinished tickets ending at a defined time. After the move, a controlled test confirms warehouse functions work and old refund and export routes reject the account. The owner checks that a shared support mailbox delegate was removed and that the ticket handover has a named successor. No arbitrary number of hours is prescribed; the timetable is an operational decision, while the evidence is the approved scope and test result.
Keep approval separate from self-approval
The staff member can explain the work they need to perform, but an accountable manager or system owner should approve consequential access. That is a practical separation of duties, especially for refunds, payouts, price changes, customer export and user administration. If a small team has only one administrator, write down who reviewed the request and how an exception will be revisited; limited staffing does not turn an undocumented blanket grant into a sound control. Record the reason for any privileged access and the approving person without exposing secret credentials in the ticket. Review whether the new role can approve its own changes or create another privileged account. The key question is not whether the role sounds senior, but whether each sensitive action has a legitimate task, an owner and a meaningful boundary.
Preserve a reviewable record
Close the request with the old and new entitlement list, effective time, approver, exceptions, test cases and person who confirmed removal. Keep enough detail to reconstruct the decision without copying customer files into the record. OWASP recommends periodic permission reviews for privilege creep, so the role-change record should feed the next scheduled review rather than sit in an inbox. Flag temporary grants for a date-based check. If a system cannot show who has a direct grant or cannot test denial safely, record that limitation and prioritise a compensating manual review or product change. Do not write “access reviewed” when only the new group was added. A useful completion statement names the systems checked, the capabilities granted and revoked, and the remaining exceptions.
Make the process repeatable
A small business does not need a complex governance platform to start. Keep a simple role matrix for important systems, assign each system an owner, and make a role-change request trigger the same review every time. Update the matrix when a real business task changes; do not treat it as a frozen diagram detached from work. For new tools, define who can read, export, modify and approve before distributing accounts. For existing tools, start with the highest-impact actions and the staff who recently changed roles. Revisit access after temporary projects end, and check that automation has not restored old groups. This process gives managers a concrete decision and gives technical staff an exact change to implement. It also gives the employee a clear route to request a missing permission without asking for broad administrator access.
Handle the awkward exceptions
Some tools expose only a broad built-in role, while others leave direct grants hidden in a project or folder. Record the constraint and the exact sensitive actions it exposes. A manager can then decide whether to defer that access, split the task with another person, or grant a time-limited exception with closer review. Do not mark the role change complete by inventing a narrower permission that the product does not provide. If an old account is needed for an unfinished handover, attach a dated owner and list the specific work remaining. At the end of that period, confirm removal in both the identity provider and the application. The record should distinguish a completed safe change from a documented residual risk, so the next reviewer knows what was actually tested and what still needs a product or process fix.
Before you release the change
- Compare old access with the new task by action and resource.
- Have a system owner approve sensitive exceptions and expiry dates.
- Test that removed routes deny access and required routes work.
