River
Y CombinatorBacked by Y Combinator

Free template

Employee Offboarding Checklist Template

Every account a role uses and how each one is shut off, plus a last-day log for confirming a leaver's access is really gone.

Free download · No account needed

What you get

Pack of 6 files: 3 documents, 3 spreadsheets

Employee Offboarding Checklist Template
  • Why a Remembered Checklist FailsDocument
  • Provisioning StandardDocument
  • Offboarding ProcedureDocument
  • Access MatrixSpreadsheet
  • Provisioning ChecklistSpreadsheet
  • Revocation LogSpreadsheet

How to build an employee offboarding checklist

An employee offboarding checklist is the list of tasks a company finishes when someone leaves. It covers their access, company equipment, final pay and benefits, and the handover of their work. Access needs the most care, because an account you miss keeps working. A good checklist lists every account the person had, says how each one is shut off, and names who confirmed it's closed.

One principle matters most: switching off someone's main login closes only the apps that sign in through it. Every other account needs its own step, and its own check.

An access badge reader with a red light on a concrete wall, near a closed door in an empty stairwell
An account is only closed when someone tries it and it fails. Photo: Jakub Żerdzicki on Unsplash

Agree who owns each part of offboarding

Offboarding crosses HR, payroll, the manager, IT and facilities, so write one procedure with a named owner for each part. The Federal Trade Commission tells businesses to have a procedure that makes sure workers who leave or transfer no longer have access to sensitive information1.

Who usually owns each part

PartUsual ownerWhat it covers
TimingManager and HRWhen the person is told, and when access ends
Pay and benefitsHR or payrollThe final paycheck and benefits
HandoverManagerOpen work, recurring tasks and files the person owns
AccessITEvery account, session, phone token and shared login
EquipmentIT and facilitiesLaptop, phone, badge and keys
Exit interviewHRWhy the person is leaving

In the US, the Department of Labor notes that federal law doesn't require an immediate final paycheck, but some states may2. Check the rule in the state where the person works. The employee termination checklist template includes a final pay calculation, and a role handover document captures what the person owns and knows.

Timing isn't IT's call

When access ends, relative to telling the person, depends on the departure. Agree it with the manager and HR, and bring in an employment lawyer for a firing or a disputed exit. Then make the checklist work at whatever moment you choose.

List every account from records, not memory

A checklist written from memory lists the apps someone remembers granting, and an account nobody remembers is an account nobody closes. Build the list for each role from records instead:

  • Your identity provider's app list (Google Workspace, Microsoft Entra ID, Okta or similar)
  • 12 months of software charges on expense reports and company cards
  • Seat lists in the admin consoles of your main platforms
  • The person in the role, asked what they signed into last week, including on their phone

Treat every software charge as an app until you rule it out. That's how tools bought on a card turn up. Count the things nobody calls an app, too: a database login, a server key, an old wiki, a customer's own portal and any shared team login.

Include contractors. CISA, the US cybersecurity agency, says organizations should have a defined and enforced process to offboard staff, including contractors and vendors3.

Use the same list when people join

Record each account as you grant it, and the leaver's list already exists. The 30-60-90 day onboarding plan template includes an access and equipment register for new hires.

Sort each account by how access ends

For each account, ask what actually stops the person from getting in. There are three answers, and a line that says "remove access" hides the difference.

Three kinds of account, and what closes each

KindHow to spot itWhat closes it
Single sign-onIt opens with the company loginDisabling the main account, then ending open sessions
Own passwordIts own username and password, even if the sign-in page looks familiarRemoving the user inside that app
Shared loginSeveral people, or a scheduled job, use one usernameChanging the password or key, and sharing the new one with remaining users
Not sureYou can't tell from the recordsTreat it as own-password until you check

Next, count the accounts that need a person: own-password plus shared. That number, not the total, is the size of the last-day job. If an app offers single sign-on but still accepts a password, count it as own-password, because the password keeps working after the main account is gone.

ExampleChecking an old checklist against the real listAn illustrative example written for this guide. The company and app counts are made up.

Role: implementation consultant at a 240-person software company. Sources: identity provider export, 12 months of card statements. Apps found: 41.

Single sign-on: 23. Own password: 13. Shared: 5. Accounts needing a person on the last day: 18.

The checklist in use had 12 lines. Nine were single sign-on apps that close on their own. It covered 3 of the 18 accounts that needed a person.

  • Length wasn't the problem. Adding lines would not have helped. The missing accounts were a different kind.
  • The card statement found one. A $39-a-month analytics tool was on no list until someone read the statement.

Close access in order on the last day

About five months after resigning, a former Cisco employee got into the company's cloud infrastructure without permission and ran code that deleted 456 virtual machines. The Justice Department reports that more than 16,000 Webex Teams accounts were shut down for up to two weeks4, and Cisco refunded over $1 million to customers.

NIST, the US standards agency, covers the core in its personnel termination control5: disable access, revoke credentials, collect keys and badges, and keep access to what the person controlled. Work in this order:

  1. Disable the main account

    One step closes every single sign-on app. Give it its own line, and confirm it rather than assume it.

  2. End sessions and tokens

    Sign the person out everywhere and revoke app passwords and phone tokens. Disabling the account doesn't always do this.

  3. Remove own-password accounts

    One line per app, each with a named person. Left alone, these keep working.

  4. Change shared logins

    Change each password or key on the planned date, after telling the people who still use it.

  5. Keep their work

    Move their files, mailbox and shared documents to a new owner before you delete or wipe anything.

  6. Collect and wipe devices

    Get back the laptop, phone, badge and keys, then wipe the laptop rather than shelving it.

Sessions need their own step. Microsoft's documentation for Entra ID, its identity service, says access tokens last an hour by default6, and that Entra can't directly revoke a session an app issued itself. End sessions in your identity provider, then in any app that keeps its own.

Shared logins need a plan. Changing one locks out everyone else who uses it, which makes it easy to postpone. NIST also calls for a process to change shared account passwords when someone leaves the group5. Decide each one in advance: who changes it, on what date, and who gets the new one.

Confirm each account is really closed

Revoked and confirmed are different states. A console can show an account as disabled while a session, a phone token or a separate password still works. So test each line: try the old login where you can, check the person is gone from the member list (not just marked inactive), or see an empty token list. Record who checked.

Then keep checking. CISA recommends reviewing access and disabling accounts left inactive for a set period, such as 30 days3. Check your last six leavers too. Any account that doesn't close with the main login, or shared password they knew, may still work.

Before you close out a departure

  • Every account is marked single sign-on, own password or shared
  • The main account is disabled, and sessions and phone tokens are revoked
  • Each own-password account was removed by a named person
  • Each shared login was changed, or has an owner and a date
  • Files and mailbox have a new owner
  • Devices, badge and keys are back, and the laptop is wiped
  • Someone tried each closed account and saw it fail

To have River do the sorting, choose Edit with AI at the top of this page. It builds the access matrix from your identity provider export and card statements, then drafts the last-day log for you to check.

How to use this template

Use the files as they are, or open them in River. River asks for your identity provider's app list and a year of software charges, not a list from memory. It builds an access matrix for each role and marks how every app's access ends. Then it tells you how many accounts need a person on a last day, and how many of those your current checklist covers.

  1. Download it or open it in River

    Get the three Word documents and three CSV sheets free, or open the template in River to work with AI.

  2. Gather your app list and charges

    Export your identity provider's app list and 12 months of software charges from expense reports or company card statements.

  3. Sort every account

    Mark each app single sign-on, own password or shared in the Access Matrix, or let River do it and check its work.

  4. Close and confirm each account

    Work through the Revocation Log on the last day, and record who tried each account and saw it fail.

What's in the template

Why the checklist had twelve rowsThe matrix is built from the identity provider export plus twelve months of software expense lines. The column showing how each account is shut off is the one the whole template turns on, because disabling the main account closes the 23 single sign-on apps and does nothing for the other 18.
Employee Offboarding Checklist Template
RiverAccess Matrix

Access Matrix

Illustrative sample from a 41-row matrix. Marloe Logistics, fictional warehouse software company, Senior Implementation Consultant role.

ApplicationRevocation pathWhenSourceNeeds a human?
Identity provider directory accountSSO-federatedBefore Day 1Identity providerNo
Email, chat, document storage, project tracker, CRMSSO-federatedOn demandIdentity providerNo
Jump host to the customer sandbox estateLocal credentialBefore Day 1Admin consoleYes
Reporting replica, SQL roleLocal credentialFirst weekAdmin consoleYes
Legacy wiki that predates the current oneLocal credentialOn demandObservedYes
Slotting analytics tool, $39 a month on a company cardLocal credentialOn demandExpense lineYes
EDI transaction portal, customer-issuedLocal credentialOn demandObservedOnly the customer can
Warehouse integration service accountShared credentialOn demandObservedRotation, 4 users + 3 jobs
Shared customer FTP for data extractsShared credentialOn demandObservedRotation, 6 users

41 applications: 23 SSO-federated, 13 local credential, 5 shared credential. Only 18 need a human on a last day. The checklist Marloe had been using listed 12 rows and covered 3 of those 18, while 9 of its rows were federated applications that needed nothing.

Row 16 exists only because somebody read the card statement. Nine of the 13 local rows could be federated instead, which is the one change here that reduces work permanently.

RiverRevocation Log

Revocation Log

Tom Fairhurst, Senior Implementation Consultant, last working day 2026-01-30. None of the 23 federated rows has a line; line 1 resolves all of them.

LineActionStateHow it was confirmed
Identity provider accountDisable identityConfirmedPassword reset returned no such user
Live sessions across the estateEnd all sessionsConfirmedActive session list empty
OAuth grants on personal phoneRevoke all grantsConfirmedToken list empty. Disabling the identity had not revoked these
Jump hostRemove authorized keyConfirmedConnection attempt refused
Building badgeDeactivate and collectConfirmedBadge tried at the turnstile and rejected
Legacy wikiDelete accountConfirmedAbsent from member list. Was not on the old checklist
EDI portal, TrellochRequest revocation from the customerBlockedCustomer-issued. Request raised 2026-01-29, chase 2026-02-05
Warehouse integration service accountRotateRevoked, not confirmedWindow 2026-02-06. Affects 4 users and 3 scheduled jobs
LaptopReturn and wipeConfirmedWiped, not only returned. A cached session on a returned laptop is an open credential

23 lines in the full log: 20 confirmed, 1 blocked, 2 shared rotations with dated windows. Revoked-but-unconfirmed is reported after every departure and the target is zero, because it is the only figure that predicts whether an audit finds a live account.

RiverPast Departures

Audit of the six departures before this pack existed

Run first, deliberately. It answers the only question that matters: are there live accounts right now.

FindingCount
Departures audited6
Accounts still active after the last working day11
Oldest still-active account14 months
Of the 11, local credential7
Of the 11, shared credential4
Of the 11, SSO-federated0

The distribution is the argument for the whole pack. The instinct on reading eleven live accounts is that whoever ran offboarding was careless. The zero says otherwise: the same person handled every federated row correctly on every one of the six departures. They had no way to see the rest, because the checklist did not distinguish an account that dies on its own from one that does not.

A finding that blames a person changes nothing. A finding that names a category changes the process.

  • Offboarding ProcedureThe last-day sequence with an owner on every step, and what counts as proof an account is closed.
  • Why a Remembered Checklist FailsThe method in one read: three kinds of account, where hidden ones come from, and a worked example.
  • Provisioning StandardWhat a role gets before day one, in week one and on demand, and what it never gets.
  • Access Matrix sheetEvery app the role touches, with access level, owner, source and how its access ends.
  • Revocation Log sheetEvery last-day action that needs a person, with an owner, a state and how it was confirmed.
  • Provisioning Checklist sheetA new hire's access by due date, with granted and confirmed kept apart and a named confirmer.

Common questions

What should an employee offboarding checklist include?

An employee offboarding checklist should cover access, equipment, pay and the handover. List every account the person had and how each one is closed. Add the return of laptops, phones, badges and keys, final pay and benefits, an exit interview, and a new owner for their files. Then record who confirmed each account is closed.

When should a departing employee lose access?

At a moment the manager and HR agree in advance, with legal advice for a firing. NIST's security controls leave the deadline to each organization, and note that in some situations organizations consider disabling accounts before the person is told. Whatever moment you choose, close every account then, not just the main login.

Does disabling an employee's account remove all their access?

No. Disabling the main account closes every app that signs in through the company login. Apps with their own passwords and shared team logins keep working, and open sessions can outlast it for a while. Close those accounts one at a time, then try each one to make sure it fails.

Who is responsible for offboarding an employee?

HR usually runs the process, but each part needs one named owner. The manager owns the handover, payroll the final pay, IT the accounts and devices, and facilities the badges and keys. Name them before the last day, so no task waits on a team that thinks someone else has it.

Is this employee offboarding checklist template free?

Yes. Download the three Word documents and three CSV sheets with no signup. The files come filled in for a made-up company, so you can see how each one works before you clear it. Edit with AI opens the same template in River, which builds the lists from your own records.

What does Edit with AI do?

It opens the template in a free River workspace. River asks for your identity provider's app list, a year of software charges and the roles in scope, then builds an access matrix for each role. It counts the accounts that need a person on a last day and drafts the revocation log. You still close every account yourself.

Sources

  1. FTC. “Protecting Personal Information: A Guide for Business.” ftc.gov (opens in a new tab)

  2. U.S. Department of Labor. “Last Paycheck.” dol.gov (opens in a new tab)

  3. CISA. “Cybersecurity Performance Goals 2.0 (CPG 2.0).” cisa.gov (opens in a new tab)

  4. U.S. Department of Justice. “San Jose Man Sentenced To Two Years Imprisonment For Damaging Cisco’s Network.” justice.gov (opens in a new tab)

  5. NIST. “SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations.” csrc.nist.gov (opens in a new tab)

  6. Microsoft Learn. “Revoke user access in an emergency in Microsoft Entra ID.” learn.microsoft.com (opens in a new tab)

Written by

Chandler Supple

Co-founder & CEO, River

Chandler has spent the last six years working in AI, building tools for millions of users and Fortune 100 companies. In 2025, he co-founded River to build a new kind of operating system for AI agents.

Reviewed by

Brian Joseff, Co-founder, River