How does an IT support provider manage access when employees join or leave?
An IT support provider manages employee access through a documented joiner, mover and leaver process: creating approved accounts and permissions for new starters, adjusting access when responsibilities change, and promptly disabling accounts when employees leave. Access should follow least-privilege principles, with approvals, asset recovery and audit records providing evidence that permissions are controlled throughout the employee lifecycle.
An IT support provider manages employee access through an identity lifecycle process that connects people records, user accounts, devices and business applications. The aim is to ensure that access reflects a person’s current role, is removed when it is no longer required, and can be traced to an approved business decision.
Access begins with a defined source of authority. The provider should establish which system or person confirms that an individual has started, changed role or left the organisation. This is often an HR record, a nominated manager or a formal service request. Using a recognised source prevents informal messages from becoming the sole basis for changing access and creates a consistent process across the business.
For a new employee, the provider can use a role-based access model. Rather than selecting permissions individually each time, standard roles identify the applications, data areas and collaboration resources normally required for a particular job. Any additional access should have a clear business reason and an identifiable approver. This reduces inconsistent permission decisions and makes it easier to check whether access remains appropriate later.
Identity verification is an important control. User accounts should be linked to a unique individual rather than shared between employees. Multifactor authentication can add a second verification step for systems containing sensitive information, while single sign-on can centralise authentication and make account status easier to manage. The exact controls depend on the systems in use, the sensitivity of the data and the organisation’s risk requirements.
Role changes require particular care because permissions can accumulate over time. If an employee moves department, takes on management responsibilities or stops performing a previous function, the provider should assess both the new access required and the old access that is no longer justified. A change should not simply add another permission set without checking for conflicts, excessive privileges or separation-of-duties concerns.
Leaver management is more than deleting a single email account. A complete review may include:
- Business applications and line-of-business systems
- Cloud storage, collaboration spaces and shared mailboxes
- Virtual private network and remote access accounts
- Privileged, administrator and delegated accounts
- Mobile devices, laptops, tokens, keys and other authenticators
- Third-party services registered using the employee’s business identity
The order of actions matters. An organisation may need to preserve business records, transfer ownership of files or calendars, redirect operational information and retain relevant evidence before disabling or removing an account. At the same time, access should not remain active merely because data ownership has not yet been resolved. A documented offboarding workflow helps separate those two requirements.
Privileged access needs additional controls. Administrator rights should be limited to people who require them, used through identifiable accounts and reviewed separately from ordinary user permissions. Temporary elevation may be preferable to permanent administrator access where the technology allows it. The provider should also distinguish between human accounts, service accounts and application credentials, since disabling a service identity without understanding its purpose can interrupt an important business process.
Remote and personal devices add another layer to the process. Access should be linked to device-management and security controls where appropriate, allowing an organisation to remove corporate data, revoke tokens or block a device that is no longer trusted. Recovering equipment is useful, but it should not be treated as the only protection: credentials, sessions and application access must also be addressed.
Regular access reviews test whether the process is working in practice. A manager or system owner can confirm that users still need their assigned permissions, while the IT provider checks for dormant accounts, duplicate identities, inactive contractors, unused groups and unexplained privileged access. Review records should show what was checked, who approved the outcome and which corrective actions were completed.
Exceptions should be recorded rather than handled as permanent informal arrangements. For example, temporary project access can have an end date, an accountable owner and a reason for extension if it is still needed. This prevents emergency or short-term permissions from becoming overlooked parts of a user’s normal access profile.
A well-managed process also includes testing and reporting. Useful evidence may include access-change tickets, approval records, account status reports, device records, review outcomes and confirmation that leaver actions were completed. These records help an organisation investigate an incident, demonstrate internal control and identify weaknesses such as repeated manual work or applications that are not connected to the main identity process.
For a small or medium-sized organisation, an IT support provider can help bring these controls together by documenting responsibilities, standardising requests and identifying systems that are currently managed separately. The result should be a repeatable access process that supports normal staff changes without allowing outdated accounts or excessive permissions to remain unnoticed.

Employee access should also be controlled during extended leave, secondments and other temporary changes in status. An account that remains fully active while its user is absent may create unnecessary risk, but deleting it can disrupt records, workflows or future reactivation. The appropriate action depends on the organisation’s policies, the person’s role and the systems involved.
An IT support provider can apply a defined temporary-status procedure, such as suspending sign-in, removing higher-risk permissions and recording the date for review. Before access is restored, the organisation should confirm that the person’s role and required permissions have not changed. This prevents inactive accounts from being overlooked and avoids treating reactivation as an automatic return to the previous access profile.