Employee offboarding is a control problem, not just an administrative one. When a person leaves, every software credential tied to that worker should be identified, reviewed, and revoked in a consistent sequence. The checklist has to work across email, cloud applications, internal systems, shared accounts, and any connected tools that may not be obvious at first glance. The practical goal is to reduce the time between separation and access removal while keeping a defensible record of what was disabled, when, and by whom. A reliable offboarding process also needs clear ownership, because gaps usually appear when HR, IT, and business managers assume someone else already handled a credential.
Sourced factual references
Title: Employee offboarding: Guide to secure access revocation in 2026 ([source](https://passwork.pro/blog/employee-offboarding-secure-access-revocation/)).
Title: Employee Offboarding Checklist: 10 Steps to Revoke Access ([source](https://axipro.co/employee-offboarding-checklist/)).
Title: Terminated Employee Offboarding: 7 Steps to Close Every Data Security Gap ([source](https://www.docontrol.io/blog/terminated-employee-offboarding)).
> **Key points** > > - Build the checklist around every place a credential can exist, not only the primary account. > - Separate urgent revocation steps from follow-up tasks that require review or transfer. > - Treat offboarding as a repeatable control process with named owners and documented completion.
Start with a complete credential inventory
The checklist cannot revoke what it does not list. Before an employee leaves, the organization needs a complete inventory of accounts, authentication methods, and access paths associated with that person. In practice, this means more than the main login used for work. It includes direct accounts, delegated access, shared credentials where allowed, service portals, administrative privileges, and any application that relies on single sign-on or cached authentication.
A useful checklist should ask a simple question for each system: does this person have access, can that access be inherited or re-granted, and who is responsible for removal? That review is especially important where access spans several teams, because offboarding often fails in the handoff between managers and technical administrators. If a system is not in the inventory, it should be treated as a gap until someone confirms otherwise.
The inventory also needs a practical scope. For example, some credentials may be temporary, some may be tied to a project, and some may exist only because of a role change made months earlier. The point is not to build a perfect catalog on day one. The point is to make offboarding decisions against a known list rather than a memory-based guess.
Separate immediate revocation from follow-up cleanup
A strong checklist distinguishes between actions that should happen immediately and actions that can follow after access is cut off. Immediate revocation usually covers the credentials that can still be used right away: primary sign-in, remote access methods, privileged accounts, and any path that lets the former employee reach corporate systems from outside the standard environment. Follow-up cleanup handles items such as access transfers, account ownership changes, and review of shared folders or delegated permissions.
This distinction matters because offboarding has two risks that move in opposite directions. If access stays active too long, the organization keeps an exposed path open. If access is removed too broadly or too early without checking dependencies, business continuity can suffer. A checklist should therefore sequence the work so that the most sensitive credentials are disabled first, while the remaining steps are checked for downstream impact.
The best way to express this in a business process is to group tasks by urgency. For example:
- Disable direct sign-in and privileged access first. - Revoke access to messaging, file storage, and collaboration tools next. - Transfer business-owned accounts and shared credentials after access has been cut off. - Confirm that any delegated permissions, tokens, or linked sessions are also addressed.
That order is not a universal rule, but it is a practical one when the objective is to reduce exposure quickly without losing operational continuity.
Cover every place credentials can persist
Credential revocation is broader than account deletion. A former employee may remain able to reach systems through active sessions, remembered devices, linked mobile apps, application passwords, API tokens, or third-party authorizations. A checklist that focuses only on username and password changes can leave those paths open.
That is why each system should be reviewed for the specific form of access it uses. Some tools rely on standard logins. Others use delegated permissions. Others may be connected through a central identity layer, while some may sit outside it entirely. The checklist should prompt the reviewer to confirm whether the employee had direct access, whether the account was part of a group, and whether access had been extended through a connected application or approval workflow.
This is also where the checklist should avoid assumptions. A person may no longer know a password, but an active session could still exist. A person may not own an account, but may still have authorization through a shared mailbox, folder, or application role. A person may not have administrative rights, but may still have an access path through a device or login token that was never cleared.
The practical test is simple: if the system can continue to authenticate or authorize the person after separation, the checklist is incomplete.
Assign ownership and evidence for each step
A revocation checklist works only when each task has a named owner and a completion record. Without clear assignment, offboarding becomes a series of informal requests that may or may not be followed through. The checklist should say who initiates the request, who approves it, who executes revocation, and who confirms closure. In larger organizations, those roles are often split across HR, IT, security, and the business unit.
Evidence should be built into the process, not added later. The record does not need to be complicated, but it should answer the same basic questions every time: which credential was removed, when the action occurred, and whether any exception was approved. This helps if a dispute arises later or if an audit needs to show that the organization had a repeatable process.
A useful checklist format includes checkboxes, owner fields, timestamps, and a place for exception notes. If an access path cannot be removed immediately, the checklist should note why, who accepted the risk, and when the follow-up will occur. That keeps the process factual instead of informal.
The point is not paperwork for its own sake. The point is to make revocation visible enough that missed steps can be found before they become incidents.
Manage business continuity while removing access
Revoking every credential does not mean deleting every account without review. Some access must be transferred, not merely removed. That is especially true where the departing employee owned a process, maintained a shared resource, or managed an account used by a team rather than one person. If the checklist does not distinguish between personal access and business-owned access, it can interrupt operations unnecessarily.
A practical offboarding process asks whether the credential should be revoked, reassigned, or archived. Reassignment may be appropriate for shared resources that need a new owner. Archiving may be useful when the account needs to be retained for recordkeeping but no longer used for login. Revocation remains the default for direct access tied to the individual, but the checklist should make room for exceptions where business continuity requires a different action.
This trade-off is why managers and technical owners should review the list together. The manager can identify business dependencies. The technical owner can confirm what can be disabled safely and what needs a transfer step first. When those judgments happen in sequence rather than in isolation, the organization is less likely to either leave access open or break an important workflow.
A strong checklist therefore includes both security and continuity questions:
- Is this access personally assigned or business-owned? - Does anyone else depend on this account or credential? - Can the account be disabled now, or must ownership move first? - If a delay is needed, what is the documented reason and deadline?
Close the process with verification and exception handling
The final stage of offboarding is verification. It is not enough to send a revocation request and assume completion. The checklist should require confirmation that the targeted accounts, credentials, and access paths were actually disabled. If there are systems outside centralized control, those should be confirmed separately rather than grouped into a general assumption that “IT took care of it.”
Verification should also look for exceptions. Sometimes an account must stay active for a limited purpose, or an access path cannot be removed immediately because it supports a business function. In those cases, the checklist should record the exception, identify the approver, and set a follow-up action. If no follow-up is needed, the record should still show why the exception ended.
This closing step turns the checklist from a task list into a control. It confirms that the organization did not merely intend to revoke access but actually did so. It also creates a consistent place to detect recurring issues, such as systems that were forgotten, dependencies that were not documented, or owners who were unclear about their role.
For practical use, the checklist should end with a final review question: does the former employee still have any software credential, session, token, delegated right, or inherited access path that can be used to reach company data or systems? If the answer is not clearly no, the process is not finished.
A complete offboarding checklist is most effective when it is specific, repeatable, and owned by the people who can actually disable access. It should identify every account path, separate urgent revocation from later cleanup, require evidence for completion, and preserve business continuity where access must be transferred rather than removed outright. The result is a process that is easier to execute, easier to audit, and harder to bypass.