Before day one
Decide before the calendar forces it
Confirm the role, manager, start date, and exactly which accounts, devices, and applications that role requires - decided ahead of time, not improvised on the first morning.
New hire and departure
A first day and a last day both need a checklist, not a memory.
A new hire who waits on access nobody prepared, and a departed employee whose account stays open for months, are the same failure: a list that only ever lived in someone's head. Here is the version that gets written down.
The checklist, in order
Five stages, one visible owner at each.
Day one
Provision to the role, not to habit
Create the account, assign the device, and grant access scoped to what the role actually needs - enough to be productive immediately, not broad access granted just to feel safe.
Role change
A move is not just an addition
Update access when someone changes teams or gets promoted, removing what the old role needed as deliberately as adding what the new one requires.
Last day
Executed on the date given
Disable the account, revoke device and application access, and redirect email or shared files to the right owner - on the date HR confirms, not whenever IT gets to it.
After departure
Confirm it rather than assume it
Check that access is actually gone across every connected application, not only the primary email account, and retire or reassign the returned device.
Whose list is this
The checklist needs two owners, not one.
What the business confirms
The role, the start or end date, the manager, and which systems that specific role should touch. Nobody in IT can safely guess this on their own.
What managed IT executes
Account creation or disablement, device assignment or return, and access changes across every connected application - carried out from an authorized business request, on the date given, not before and not much after.
Honest limit: this checklist reduces how often an access step gets forgotten. It does not replace an authorized business request - managed IT does not decide who joins, changes role, or leaves; it executes that decision once someone with the authority to make it does.
Before it becomes urgent
Questions worth answering before the next start date or exit.
- Who tells IT that someone is starting, changing roles, or leaving - and how much advance notice does that actually give?
- Is there a written list of exactly which accounts and applications a given role needs, or does it get reinvented every time?
- What happens to a departing employee's email, files, and shared access on their last day, and who actually confirms it happened?
- If a shared mailbox or Team has more than one owner, who decides who keeps it once one of them leaves?
Evaluating a new IT provider instead of a new employee? See managed IT onboarding for that transition - a different checklist for a different kind of start.
Connect the work
See how the checklist connects to identity and responsibility.
Reach the team
Tell us what needs an owner
Share your team size, current support setup, and the responsibilities you want clarified. We will use that to figure out whether an MSP introduction makes sense.
Online requests are not available right now. No message is sent from this page.