Microsoft 365 risk
Access should change when a person's role changes.
A practical joiner, mover and leaver process prevents old permissions from quietly accumulating.
Offboarding is only one part of the problem
Organizations often remember to create accounts and disable departing employees, but overlook internal role changes. Someone moving from finance to sales may keep access to both departments. Over time, these leftover permissions make the identity more powerful than the person's current job requires.
Treat access as a lifecycle with an accountable business owner. Joining, moving and leaving should trigger a review of permissions, devices, shared resources and application ownership. The process must include applications outside the main identity platform where they remain in use.
Automate a defined process, not an assumption
Automation depends on reliable information about employment status, effective dates and role ownership. If that information is wrong or delayed, an automated task can remove access too early or preserve it too long. Establish the authoritative source and a way to handle exceptions before expanding automation.
Differentiate revoking access from deleting business records. Mailboxes, documents and audit records may need retention or transfer under approved policies. A departure checklist should preserve appropriate business continuity without allowing continued unauthorized sign-in.
Verify completion beyond the directory
A completed directory task does not prove that every independent SaaS account, shared credential or device session has been addressed. Require evidence for each relevant system and review failures. Sensitive departure timing and records should only be visible to authorized people. Confirm licensing before choosing a vendor workflow feature.
In practice
A project manager transfers to another department
Illustrative scenario, not a client case study.
Consider an employee who moves from client delivery to internal operations. The old role included access to sensitive client folders and a vendor portal. The new role requires different systems, but nobody has explicitly removed the old assignments.
- The business owner confirms the effective role-change date and identifies required new access. The old department reviews which permissions are no longer justified.
- IT applies the approved changes and checks the separate vendor portal, rather than assuming a directory-group update covers it. Necessary project ownership is transferred to the replacement manager.
- A review confirms that the employee can complete the new role's tasks and no longer retains unapproved old access. Exceptions have a named approver and a review date.
A mover process prevents accumulated permissions while preserving legitimate work. It is a business coordination problem supported by identity technology, not merely an account-creation task.
What to put in place
- Use a reliable source for role changes and effective dates.
- Review removed access as carefully as newly granted access.
- Include independent applications, shared resources and ownership transfers.
- Verify completion and retain appropriate evidence without exposing sensitive personnel information.
The takeaway
The right question is whether today's access matches today's responsibility. A documented lifecycle makes that question answerable throughout employment, not only on the last day.