[Blog]()Access control # Employee offboarding: accounts, sessions and integrations to review Disabling email is one step. Review open sessions, independently authenticated apps and tasks that relied on the departing person. **[Jonathan Perez]()**Co-founder · Design, product and sales October 8, 2026 · 7 min read **Short answer** Access offboarding needs a per-person inventory, an authorized time and checks in every relevant system. Block access through each provider's procedure, review sessions and app credentials, and transfer ownership of tasks and documents. Suspending an account is different from deleting its data or automatically revoking every independent access path. ## Test worksheet: Employee offboarding: accounts, sessions and access Disabling email is one step. Review open sessions, independently authenticated apps and tasks that relied on the departing person. Record inputs, expected outcome, evidence, owner and observed result. [Download CSV worksheet]() In this guide - [Start with where the person works]() - [Fictional example: ANA-07 leaves coordination]() - [Verify both access and continuity]() - [Separate the person from shared identities]() - [Close with explicit remaining tasks and owners]() ## Start with where the person works At a service company, a coordinator may use email, calendars, an ERP, evidence storage and a routing provider's application. Some tools use corporate sign-in; others have independent accounts. List each owner, access method and offboarding check. Include groups, pending invitations and administrative recovery, without storing passwords in the worksheet. [Microsoft 365]() documents access blocking, content retention or transfer and deletion separately. [Google Workspace]() explains that suspension preserves data and some effects depend on the service and session. Follow each product's procedure; changing an email account does not prove immediate revocation in every connected application. ## Fictional example: ANA-07 leaves coordination The business authorizes ANA-07's departure access change at 17:00. There are three known working sessions, a separate routing-portal account and a nightly task using her credential to download orders. This is a synthetic scenario. The intended result is to block her future access, retain authorized documents and keep the task under an appropriate identity and owner. The nightly task should not retain a personal credential merely because it still works. It also should not be interrupted without notice if operations depend on it. Identify who can change it, which permission it needs and how they will test a controlled run. An offline device remains a recorded dependency: revoking server access does not demonstrate immediate removal of its local copy. | Action |Purpose |Verification | | --- | --- | --- | | Block access |Prevent new authorized sign-ins |Controlled attempt rejected | | Revoke sessions or tokens |Close existing paths according to the product |Test and documented limitations | | Transfer documents and tasks |Continue work under authorized custody |New owner completes the task | | Delete account |Apply the agreed retention decision |Owner checks data and dependencies | ## Verify both access and continuity Use authorization, test accounts or a documented administrative procedure for checks. Record time, system, result and limitation. You do not need to inspect private information to establish that an identity is blocked. If an external application cannot be verified, leave it pending with an owner; the number of checked boxes does not determine completion. | Case |Expected result |Evidence | | --- | --- | --- | | New sign-in after 17:00 |Corporate access blocked |Administrative event and controlled test | | Previously open session |Behavior confirmed for that provider |Time, session and outcome | | Routing portal account |Independent revocation verified |Portal administrator record | | Nightly task credential |New custody with sufficient bounded permissions |Identity and rehearsal run | | Task retry |Downloaded orders not duplicated |Batch reference and count | | Offline device |Visible pending state and recovery procedure |Owner and local limitation | ## Separate the person from shared identities If someone knew a shared credential, disabling their user does not change that credential. Review secrets or keys other devices could use, then plan rotation with affected dependencies. A legitimate integration must have a business owner even when using a technical identity. Do not distribute a replacement key through the same channel or file the departed person can still access. Review delegated app permissions, emergency access and recovery methods too. Distinguish personal credentials, delegated authorizations and service identities: each may require different actions. Scope depends on the contract, available administrator and product features; do not promise that a single command revokes every mechanism. ## Close with explicit remaining tasks and owners Retain evidence of verified actions and a list of pending ones. Agree who receives operational email and locates relevant files under the applicable policy. Deleting data is not proof of complete offboarding. Review [digital keys](), [internal roles and permissions]() and a [restore test]() when continuity depends on one person. The downloadable worksheet contains no secrets or approved results. Bring an anonymized inventory of applications, dependent tasks and owners to a [free consultation]() for [cybersecurity](). We can review gaps and ways to verify them without assuming that all access belongs to one provider. ## Review access and tasks before offboarding Identify applications, sessions and tasks that depend on one person. In a free consultation, decide who blocks each access method, transfers the work, and verifies what remains unresolved. - Anonymized application and access-method inventory - Tasks and documents dependent on a personal identity - Owners authorized to block, transfer and verify [Book a free consultation]()[Ask on WhatsApp]() Related - [Cybersecurity for businesses]() - [Hosting, backups and maintenance]() ## Frequently asked questions ### Is changing a password enough? Do not assume so. Existing sessions, application tokens and independent accounts may behave differently. Follow product documentation and test relevant access paths. A changed password also does not prove that a local file has disappeared. ### Should we delete the account immediately? Separate access blocking from information retention first. Documents, tasks and administrative recovery may depend on the identity. Deletion should follow the authorized decision and product procedure, considering the applicable retention policy. ### What about an integration using that account? Identify its owner, permission and queued work. Transfer or replace the credential through a controlled test before closing the dependency. Test a retry too, so reconnecting does not duplicate work. ### How should we record something we cannot verify? Mark it pending with a reason, owner and next action. A third-party-managed application or offline device may need additional evidence. Requesting removal is not the same as verifying revocation. ## Sources 1. [Remove a former employee]()Microsoft 2. [Suspend a user temporarily]()Google Last updated: October 8, 2026 ## Keep reading [Internal permissionsOct 8, 2026 ### Roles and permissions: who views, changes and approves in your system]()[SecurityOct 2, 2026 ### Who holds the digital keys to your business? How to check your access]()[Change auditingOct 8, 2026 ### Change audit logs: who changed what and how to investigate a difference]() --- Canonical: https://nightlysoftware.com/en/blog/employee-offboarding-access Updated: 2026-10-08 Description: Review access after a departure without losing documents or stopping scheduled work. Includes an account, session and integration checklist.