Practical guide
Offboarding access removal as an employment record
An offboarding control that ties the separation date, the access inventory, the removal confirmation, and the owner to one reviewable record.
Published

Table of contents
Start with the separation date and the access inventory
An offboarding access record should begin with the separation date and the list of systems the employee can use. The list should include the identity account, email, file storage, business applications, shared mailboxes, and any physical access record. A generic note that access was removed is not enough. The inventory should come from the identity system and the application owners, not from memory.
If the team does not have a complete list, record the systems that were checked and the systems that could not be verified. A gap in the inventory is a finding, not a reason to close the case. Record the employee's role and the access that was required for that role. This helps the reviewer distinguish access that should have been removed from access that was never granted. A former employee may appear in a system for a legitimate record-retention reason, but the login should not remain active.
Assign one removal owner per system
Each system should have a named owner who confirms removal. The identity team may own the central account, while the application owner owns the application role. A shared ticket queue can coordinate the work, but it cannot replace the named owner. The owner should record the removal date, the method, and any exception.
If the account cannot be removed immediately because of a legal hold or a records requirement, record the reason and the compensating control. The reviewer should see why the access remains and who approved it. A backup owner should be named for each critical system. If the primary owner is unavailable, the backup should be able to confirm the removal without waiting for the next business day.
Separate disabling from deleting
Disabling an account and deleting an account are different actions. Disabling prevents sign-in while preserving the record; deleting removes the account and may affect mail, files, or audit history. The offboarding procedure should state which action applies to each system. If the account is disabled, record the date and the person who disabled it.
If the account is deleted, record the retention decision and the owner who approved it. Do not delete a mailbox or a file store without confirming the records requirement. A shared mailbox needs special handling. Removing the employee's personal account may not remove access to a shared mailbox. The owner should check the membership and the delegate list, not only the primary account.
Confirm the removal with evidence
A removal is complete when the system shows the account disabled or the access removed, and the owner records the confirmation. A message that says done is not evidence. The record should show the system, the account identifier, the date, and the reviewer. For critical systems, a second reviewer should confirm the result.
The second reviewer can be from the identity team or the application owner, but should not be the same person who performed the removal. Record the second check. If a system cannot be checked, mark the item unverifiable and escalate. Do not close the offboarding record because the ticket was marked complete. The ticket status and the system status are different facts.
Handle the first day after separation
The first business day after separation is a useful checkpoint. Confirm that the account is disabled, the mailbox rule is active if required, the manager has the open work, and the backup owner has the files. A delayed discovery can leave client work stranded. The manager should confirm which work is still open and who owns it.
The offboarding record can reference the handoff note rather than reproducing the work. If the employee had access to sensitive client or patient information, the access owner should confirm the removal first. Do not contact the former employee through the disabled company account. Use the approved personal contact and the HR process. An operational question should go through the manager or the HR owner.
Review privileged and shared access
Privileged accounts, shared passwords, and group memberships are common gaps. A central account may be disabled while a shared application password remains unchanged. The offboarding review should check the privileged access list and the shared credential inventory. If a shared credential was known to the employee, the owner should rotate it and record the change.
A password change that is not recorded cannot be verified later. The rotation should follow the system's approved procedure. Group membership should be checked even when the individual account is disabled. A group may grant access through a different path. The identity owner should confirm the membership removal or document why it remains.
Keep the record with the separation file
The access removal record belongs with the separation file, subject to the retention rule. It should show the systems, the owners, the removal dates, the exceptions, and the final confirmation. A later reviewer should not need to reconstruct the process from tickets. Do not include passwords, authentication codes, or unnecessary personal information.
A system reference and an account identifier are enough. If a record contains sensitive information, store it in the approved location and restrict access. The record should be available to the identity, HR, and legal owners when they need it. A record that exists only in a former manager's inbox is not a control.
Sample the offboarding record each quarter
A quarterly sample should compare the separation date, the access inventory, the removal confirmation, and the owner sign-off. Include a voluntary separation, an involuntary separation, and a case with a legal hold. The sample should show whether the process works across different paths. Record the number of records sampled, the number with an unverified system, and the number with a late removal.
A late removal is not automatically a control failure, but it needs a reason and an owner. A pattern of late removals may point to a notification or capacity problem. Choose one change for the next quarter. It might be an earlier notification, a required system inventory, or a second-review rule for privileged access. Name the owner and the next sample date.
Close the loop with the manager
The manager should confirm that the open work was transferred and the team knows whom to contact. The access record can be complete while the operational handoff is not. A short manager confirmation closes that gap. If the manager reports a missing file or an open client question, record it and route it to the owner.
Do not reopen the access removal unless the system evidence shows a problem. The two issues are related but distinct. Keep the manager confirmation with the separation record. A later reviewer can see that the access was removed and the work was handed off. That combination is the practical meaning of a completed offboarding.
Sources
References supplied with this guide.
| Source | Publisher | Context |
|---|---|---|
| NIST Cybersecurity Framework 2.0 | nist.gov | Primary reference supplied with this article. |
| NIST SP 800-207, Zero Trust Architecture | csrc.nist.gov | Primary reference supplied with this article. |
| Cybersecurity and Infrastructure Security Agency | cisa.gov | Primary reference supplied with this article. |
| U.S. Department of Labor, Wage and Hour Division | dol.gov | Primary reference supplied with this article. |
