The IT Checklist Nobody Runs Until Someone Quits

Most small offices have some version of an onboarding routine. It might live in a spreadsheet or in the office manager’s head, but it exists, because a new person with no email address is an obvious problem. Everyone notices.

Offboarding is different. Nobody notices. A person’s last day comes, the laptop goes back in a closet, and their accounts keep working — sometimes for years. There is no error message, no complaint, no ticket. The gap only becomes visible when something bad happens: a former employee still receiving copies of every invoice, a competitor who knew about a bid, or a login from an account that should have been dead in 2024 turning up in a security investigation.

The fix is one checklist, written down, read in two directions. Onboarding is the list top to bottom. Offboarding is the same list bottom to top, plus a few items that only exist on the way out.

What a New Hire Actually Needs on Day One

Start with the request, not the setup. The single biggest cause of a rough first day is that IT found out about the new person the morning they arrived. Ordering a laptop, imaging it, encrypting it, enrolling it in management, and testing it is not a same-day task, and stock for a specific model is never guaranteed. Give at least two weeks for anything involving hardware and a few business days for accounts alone.

The request should come from the hiring manager or HR — not from the new employee, and not relayed by a coworker. Granting access is an authorization decision, so it needs to come from someone with the standing to authorize it. A good request contains six things:

• Full legal name, preferred name, and start date. The name determines the email address, and changing it later is more disruptive than people expect.
• Job title and department. This drives every permission decision that follows.
• Who they mirror. Naming an existing employee in the same role is the fastest accurate way to describe what access is needed — but see the warning below.
• Manager and location. Who approves future changes, and which office, site, or remote setup applies.
• Hardware needs. Laptop or desktop, monitors, docking station, headset, and whether they need a company mobile phone.
• Physical and phone requirements. Building key or badge, alarm code, and a phone extension if you run a phone system.

The warning about mirroring: copying an existing user is convenient and it is how permissions quietly sprawl. The person you copy has usually been there six years and has accumulated access to things they no longer need. Copy the role, not the person. The cleanest approach is to define a small number of role templates — front desk, billing, clinical, field tech, management — and grant access through groups tied to those roles rather than assigning permissions to individuals one at a time. When someone changes roles later, you swap a group instead of guessing.

The Day-One Build

With a complete request, the build itself is mechanical:

• Directory account in Microsoft Entra ID (or your equivalent), with the correct license assigned.
• Group membership per the role template, which in turn grants shared mailboxes, file shares, SharePoint sites, and Teams channels.
• Multi-factor authentication enrolled before the account is handed over, not “when they get a chance.” Enrollment during setup takes three minutes; chasing it later takes three weeks. If the role touches money, payroll, or email administration, use a phishing-resistant method — a passkey or hardware security key — because app codes and push prompts can be relayed by modern phishing kits.
• Device provisioned: encrypted, enrolled in management, endpoint protection installed and reporting, and patched current before it leaves the bench.
• Line-of-business applications — the EHR, the accounting system, the practice management or dispatch software. These almost always live outside the directory and need their own request to their own administrator.
• Phone extension, voicemail, and call routing, plus printer and scanner access.
• A password manager seat, issued on day one, so that shared logins never travel by text message or sticky note.

Record the result. Every account you create for this person goes on a list attached to their name — because that list is what you will need on the day they leave, and it is the one thing nobody writes down.

Offboarding Is the Half That Carries Real Risk

An incomplete onboarding produces a frustrated new hire. An incomplete offboarding produces a standing, unmonitored way into your business. The two are not comparable, and yet offboarding is almost always the one done from memory in a hurry.

Disable the account. Do not delete it.

This is the item that matters most, and it is the one most often done backwards. Disabling the account in the directory is what actually revokes access. Removing someone from a distribution list, taking their name off the website, or collecting their laptop does not. As long as the account is enabled, the credentials work from anywhere in the world.

Deleting the account, on the other hand, is the wrong kind of thorough. It destroys the audit history you may need if a question comes up later, it can orphan files and calendar items the person owned, and it removes the mailbox that still contains client correspondence. The sequence that works: disable the account, reset the password to something nobody knows, revoke active sessions and refresh tokens, convert the mailbox to shared so colleagues keep the history, and then delete or archive after a defined retention period once you are certain nothing was lost.

Revoke MFA and active sessions

A password reset alone does not log anyone out. Browser and mobile sessions can stay valid for a long time after the password changes, which means a person can continue reading email from a phone that was never handed back. Explicitly revoke sessions and sign the user out of all devices, remove their registered MFA methods, and wipe or retire the company data on any enrolled mobile device.

Mailbox delegation and forwarding rules

Two settings survive nearly everything else and both are invisible unless you look. Delegation means someone else has been granted access to the departing person’s mailbox — or, more dangerously, the departing person was granted access to somebody else’s, such as the owner’s or the billing mailbox. Disabling their own account does not touch that grant if it was made to a personal account or a second login. Forwarding rules are the classic one: a rule that quietly copies every incoming message to an outside address. Check both mailbox-level forwarding and inbox rules, on the departing mailbox and on any mailbox they had access to. This is the same mechanism attackers use after a compromise, which is why it belongs on any email security review as well as your offboarding list.

Shared credentials

Every small business has some. The bank’s secondary login, the domain registrar, the shipping account, the utility portal, the social media pages, the alarm company. If the departing person knew any of them, they still know them. Rotate them, and record which ones you rotated. If you have to guess at that list, the password manager you should have issued on day one would have answered it in ten seconds.

The SaaS app IT never knew about

This is the one that bites. Somebody signed up for a scheduling tool, a form builder, a design app, an e-signature service, or an AI writing assistant using their work email and a password they chose. It was never requested, never approved, and it does not appear in the directory — so disabling the main account does absolutely nothing to it. Worse, many of these tools were connected to Microsoft 365 or Google Workspace through a consent screen, which means they may still hold a token that reads company email or files.

You will not find these by asking. You find them by looking:

• Search the mailbox for “welcome to,” “verify your email,” and “your subscription” before you archive it.
• Review the last twelve months of expense reports and the company card statement for small recurring charges.
• Check the enterprise applications and third-party app consent list in your Microsoft 365 tenant, and remove consents tied to the departing user.
• Look at the saved logins in their browser profile before the laptop is wiped.
• Ask their manager what tools the team actually uses day to day, which is rarely the same list IT has.

Physical items and the things that are not accounts

Laptop, charger, docking station, monitors, company phone, mobile hotspot, hardware security key, building keys, badge, alarm code, gate remote, parking pass, corporate card, and any client-site keys or access cards. Change the alarm code if they had it. Note the serial numbers of returned equipment so the asset list stays honest.

The Sequence on the Last Day

Order matters more than speed. A reasonable sequence for a planned departure: confirm the exact effective time with HR; at that time, disable the account and revoke sessions; convert the mailbox and set up any needed delegation for the manager; remove the person from groups and distribution lists; rotate shared credentials; disable line-of-business application logins and SaaS accounts one at a time from your list; collect physical items; and finally, send a written confirmation back to HR listing every item completed and every item still outstanding.

For an involuntary departure, the same list runs in a different order — access is revoked at the moment the conversation begins, not after it, and the physical collection happens in person. That is a decision for management, not IT, but IT needs to know which scenario it is before the day arrives.

Make It a Standing Process, Not a Favor

Three things turn this from a checklist into a process that actually runs. First, one named owner — a person, not a department — who is responsible for the list being completed. Second, an automatic trigger: HR entering a start date or a last day is what kicks off the request, so it never depends on somebody remembering to send an email. Third, a quarterly access review, where a manager looks at the list of active accounts for their team and confirms every one belongs to a current employee doing that job. That review is where you catch the account that was disabled but not the SaaS login, and the contractor whose project ended in March.

None of this requires new software. It requires the list to exist, to be current, and to be somebody’s job. If you are already at the point where nobody is quite sure who owns it, that is usually one of the signs a business has outgrown ad-hoc IT support and needs a defined process behind it.

Related Questions