Access offboarding should identify the person or engagement leaving, the accounts and permissions affected, the work requiring transfer and the owner who verifies removal. Review shared connections as well as direct user access. Record what was revoked, transferred or left unresolved so a closed project does not conceal an active access path.
- Identify departureName the person or engagement ending.
- Map access pathsList accounts, folders, connections and sessions.
- Transfer dependenciesAssign usable work to a new owner.
- Remove and verifyRecord removal evidence and unresolved paths.
A closed project can still leave separate access paths active.
Define the event and scope
An employee leaving, a contractor finishing and a client engagement ending are different events. Identify the person, accounts, responsibilities and timing affected. Coordinate the change with the authorized account owners.
Do not assume that closing a project removes access. Project records, vendor accounts, shared folders and integration connections may have separate controls. Build the register from what the person or engagement actually used.
Prepare an access closeout register
| Access path | What to check | Completion evidence |
|---|---|---|
| Direct user account | Membership, role and required transfer | Authorized change verified |
| Client platform invitation | Client account owner and removal route | Client or agency confirmation |
| Shared file access | Person, groups and inherited access | Relevant permissions reviewed |
| Workflow connection | Owner and continued business need | Connection transferred or removed safely |
| Shared credentials | Who can still use them | Approved credential process completed |
| Devices or sessions | Applicable account controls | Required checks recorded |
Available controls vary by system. Confirm how the current platform handles users, sessions and connections instead of assuming one action closes every path.
- Direct accessCheck membership, role and transfer needs.
- Client-owned accessTrack the client owner and confirmation.
- Shared accessReview groups, credentials and inherited permissions.
- Active connectionsTransfer or remove supported workflow connections safely.
Available controls vary by system, so confirm current platform behavior.
Transfer work before removing dependencies
Identify workflows, files and client responsibilities that depend on the departing person. Name a new owner and confirm that the transfer is usable. Avoid leaving a necessary workflow connected to an account nobody is responsible for maintaining.
- Find dependent workIdentify workflows, files and responsibilities affected.
- Name next ownerAssign accountable maintenance before removal.
- Transfer is usableConfirm the owner can continue approved work.
- Hold uncertain removalPlan with the account owner when impact is unclear.
A broad record copy does not decide what a new owner may receive.
For an illustrative contractor engagement, a scheduled report may use a connection the contractor created. Removing the user could affect the report, or the connection might remain active. Verify the actual dependency and plan the change with the account owner.
Transfer only appropriate responsibilities and information. A broad copy of someone’s records is not a substitute for deciding what the next owner needs and is permitted to receive.
Remove access through authorized controls
Carry out the agreed removal or role change in the relevant system. If the client owns the account, request the action from the appropriate client owner and track it as unresolved until confirmed.
Review shared access separately. Removing an individual account may leave another credential or group membership usable. Use your approved credential and permission process to resolve those paths without placing secrets in the closeout register.
Verify the result
Record what was changed, who performed it and the evidence used to confirm the intended result. Do not rely only on a submitted removal request. If verification is limited by a client-owned system, show that limitation and keep the follow-up owner visible.
- Verified removalEvidence confirms the intended access result.
- Removal request onlyKeep pending until the result is confirmed.
- Client limitationShow limitation and visible follow-up owner.
- Work continuesCheck reporting or delivery still has an owner.
A submitted removal request alone is not verification.
Check the business work that should continue. A successful access removal can still leave a reporting or delivery process without a working owner. Connect those failures to the exception handling process.
Use the closeout to improve the access register
Unexpected accounts and ownerless connections reveal gaps in onboarding and change tracking. Update the access request checklist so future work records the recipient, purpose and review owner from the start.
Access closeout is one part of engagement offboarding. The client offboarding guide covers deliverables, outstanding decisions and final handoffs. Keep those tasks connected while retaining clear responsibility for permission changes.
Questions and answers
Does deleting a user close every access path?
Not necessarily. Other paths may include groups, shared credentials, sessions or workflow connections, depending on the system. Review the actual access register and current platform controls. Verify the required result rather than assuming one user action resolves everything.
What if the client must remove agency access?
Send the specific request to the authorized client account owner, track it and seek confirmation. Keep the item unresolved if you cannot verify it. Identify what the agency can remove directly and what remains dependent on the client.
Should workflow connections be removed immediately?
Assess ownership, authorization and the work they support before acting. A connection may need an approved transfer or a controlled shutdown. Keep a named owner and verify the result so access closeout does not silently break a continuing client process.