DisasterLab
PlaybooksFormer team member still has access
Peoplecritical35 minutes to prepare

Former team member still has access

Someone who no longer works with the business can still reach accounts, code, data, devices, or customer systems.

01DetectConfirm the signal
02ContainStop more damage
03RecoverRestore control
04VerifyProve it works

What do you need right now?

Prepare before it happensRecover from this now

Your preparation

0 of 0 safeguards ready
0%
Continue the prevention checklist
Incident worksheet

Make the next decision with evidence

Remove the person's actual access paths, including shared and indirect credentials, then prove no business system still trusts their identity or devices.

EvidenceDecisionActionProof

Capture before evidence disappears

  • Build an identity map from the IdP, email, password manager, Git, cloud, hosting, registrar, payments, support, analytics, devices, VPN, and physical access.
  • Export sign-ins, token use, repository actions, downloads, configuration changes, and admin events from the departure date onward.
  • Record groups, inherited roles, shared accounts, API keys, SSH keys, OAuth grants, service accounts, recovery contacts, and customer-side invitations.
  • Preserve the employment or contract end time, approved exceptions, device return status, and data-transfer record.

Decisions that change the response

QuestionAct whenAction
Routine offboarding or incident?Access continued unexpectedly, was used after departure, or the exit was hostile.Open an incident, preserve logs, revoke sessions first, and scope actions before deleting the identity.
Rotate shared secrets?The person could view or export them, even if their named account is disabled.Replace the secrets at each issuer and update legitimate consumers.
Contact the person?Devices, customer data, credentials, or business records remain in their control.Coordinate through the authorized business or legal contact; do not improvise accusations.

Proof that recovery worked

  • The identity cannot sign in, recover accounts, use tokens or keys, receive forwarded mail, or access customer workspaces.
  • Every shared secret they could know has a replacement and the old value fails.
  • Owned files, repositories, automations, domains, and billing relationships have accountable new owners.
  • Post-departure logs contain no unexplained access or actions after a defined monitoring period.

Controls to put in place

  • Use a central IdP and named accounts; prohibit shared administrator logins.
  • Maintain a joiner-mover-leaver inventory that includes vendors and customer-owned systems.
  • Make departures trigger same-day session revocation, key rotation, ownership transfer, and device handling.
  • Review dormant accounts, external collaborators, recovery contacts, and shared secrets every quarter.
Tabletop drill

Choose a synthetic contractor identity. A second operator must find and remove every direct, group, token, SSH, OAuth, customer-workspace, and recovery path, then prove a shared test key was rotated.

Escalate when

Involve counsel, HR, customers, and security specialists when access was used, data or intellectual property may have been retained, the person controls an account, or contractual evidence must be preserved.

What this means

The access may be accidental or malicious. Either way, the business cannot prove that only authorized people control its systems.

Warning signs

  • Their account, token, key, forwarding rule, or shared password still works.
  • Audit logs show activity after their departure.
  • Services are owned by their personal account.
  • Nobody can list every system they used.

Recover now

First 15 minutes

  1. Preserve identity, email, code, cloud, and device logs.
  2. Disable named accounts and revoke sessions, tokens, SSH keys, and app passwords.
  3. Change shared credentials they knew. Do not rotate unrelated credentials blindly.
  4. Transfer ownership of domains, repositories, stores, documents, and billing accounts.

Today

  1. Review activity since the final authorized work date.
  2. Remove access from vendors, customer systems, support tools, backups, and physical devices.
  3. Recover business data and return or remotely wipe managed devices.
  4. Get legal or security help if suspicious access or data removal occurred.

Verify recovery

  • The person has no active identity, session, key, token, or shared password.
  • Every critical service has a current business owner.
  • Post-departure activity has been reviewed.
  • Business operations continue without their personal account.

Prepare now

Access

  • Everyone has named accounts; shared access is exceptional and inventoried.
  • Roles grant only the access required for current work.

Backups and evidence

  • Audit logs outlive the normal departure review period.

Contacts and ownership

  • An offboarding checklist covers every service, key, device, and customer account.

Practice

  • A test user can be fully disabled from a single inventory.

Common mistakes

  • Disabling email only. Tokens and external services may remain active.
  • Deleting the identity before preserving logs.
  • Leaving assets under a personal owner.

Sources

Last reviewed July 19, 2026Guidance changes. Confirm provider-specific actions in the linked official sources.