Former employee may have taken customer data: what to check first

TL;DR — If you think a former employee took customer data, treat it as a live data-protection incident: first remove their access everywhere, preserve audit logs, and check for exports, mass downloads, mailbox forwarding, and API token use. The most common real-world issue is that access was never fully offboarded, so start by disabling accounts, revoking sessions, and rotating shared credentials before you investigate deeper. Reading time: ~6 min

The scenario

It is a normal Tuesday afternoon and someone in sales mentions that a former account manager has contacted one of your customers from a personal email address with details they should only know from your system. You check your app and realize that person left two weeks ago, but nobody is fully sure which tools they still had access to. Your agency manages the website, CRM, analytics, shared inbox, and cloud storage, and now you need to answer two urgent questions: did they still have access, and did data leave your systems? You do not need perfect forensics in the first hour; you need fast containment, evidence preservation, and a clear path to the most likely sources.

Symptoms

• A customer reports that a former employee referenced private account details, order history, or contact lists.
• You find recent logins for a deactivated or supposedly unused account.
• Audit logs show events such as:

User export completed
CSV export generated
API token used
File downloaded
Mailbox forwarding rule created
Login successful from new device

• Shared systems still show the user as active, for example:

Status: Active
Last login: 2026-10-29 14:12 UTC
MFA: Not enrolled

• Large download or export activity appears shortly before departure, such as many files accessed in a short period or a spike in bandwidth.
• Customers receive emails from a personal address that include internal-only information.

Likely causes

Step-by-step diagnosis

1. Contain first: disable the person everywhere you can identify in your provider dashboards. Start with your identity provider (central login system, if you have one) or each major tool: Users/Team/People → search their email → Disable/Suspend user → Revoke sessions. This is your problem if you find the account still active or sessions still open. Then jump to Fixes → Incomplete offboarding.

2. Preserve evidence before logs roll over. In each critical system, export the audit log for the last 30 days: Security/Audit log → filter by user email → Export CSV/Download. This is your problem if the system only keeps short log history or if you see recent access events. Then jump to Fixes → Data exported from business systems or the matching cause below.

3. Check for obvious export activity in customer-data systems. Open your CRM, admin panel, billing system, support desk, and marketing platform. Use Audit log/Security log and filter by the employee email and actions like Export, Download, Report, API, Login. This is your problem if you see entries such as "CSV export generated" or unusually large report downloads. Jump to Fixes → Data exported from business systems.

4. Check email for forwarding and hidden exfiltration paths. In your mail provider's admin dashboard, open the former employee's mailbox or shared mailbox access: Mailboxes/Users → select user → Forwarding, Inbox rules, Delegates, Connected apps. This is your problem if mail is forwarding to a personal address or a rule moves copies externally. Jump to Fixes → Mailbox forwarding or rules.

5. Check cloud storage and shared drives for bulk download or sync. In your storage provider dashboard (e.g. drive, file share, object storage admin), open Activity/Audit → filter by user and actions Download, Sync, Export, Share. This is your problem if you see many downloads, a new sync device, or link sharing to personal accounts. Jump to Fixes → Cloud storage bulk download or sync.

6. Check tokens, keys, and surviving sessions. In each major system, open Security/API/Access Tokens/SSH Keys/Sessions and filter by user or service account they used. This is your problem if a token remains active after the account was disabled, or if a shared service account is still in use from an unknown IP address. Jump to Fixes → Tokens, keys, or surviving sessions.

7. Check shared secrets and service accounts. Open your password manager or secrets store and search for shared admin accounts, SMTP credentials, database users, cloud access keys, and deployment tokens the person knew. This is your problem if credentials are shared by multiple people or not tied to a named user. Jump to Fixes → Shared passwords or API keys not rotated.

[Report from customer]
          |
          v
[Disable user + revoke sessions]
          |
          v
[Export audit logs]
          |
          v
[Check exports] ---- yes ----> [Rotate creds + assess scope]
          |
          no
          v
[Check mail forwarding]
          |
          v
[Check storage downloads]
          |
          v
[Check tokens/keys]

Fixes

Incomplete offboarding

Use the admin dashboard for every system that can hold customer data: identity provider, CRM, support desk, billing, analytics, cloud storage, email, hosting, and code repository.

Menu path: Users/Team/People → select user → Disable/Suspend → Revoke sessions/Sign out of all devices.

If your provider supports role review, also remove group membership and delegated mailbox access.

If you have command-line access for a Linux host and the person had server access, lock the account and remove SSH keys:

sudo usermod -L formeruser
sudo passwd -l formeruser
sudo rm -f /home/formeruser/.ssh/authorized_keys

Verify it worked: the user should show Disabled/Suspended, and new login attempts should fail in the audit log.

Shared passwords or API keys not rotated

⚠️ Rotating shared credentials can break integrations, websites, email sending, backups, or deployments. Do this in a planned order and update every system that uses the credential.

Change all shared credentials the person knew: admin passwords, database users, SMTP passwords, cloud access keys, deployment tokens, and VPN credentials.

Examples:

Rotate a PostgreSQL password:

ALTER USER app_user WITH PASSWORD 'use-a-new-random-password-here';

Update an app environment variable:

DATABASE_URL=postgres://app_user:new-password@db.example.com:5432/appdb

Rotate an AWS-style access key by creating a new key in the cloud dashboard, updating the app, then deleting the old key.

Verify it worked: old credentials fail, and the app/integration works with the new credentials only.

Data exported from business systems

If logs show exports or report generation, preserve the evidence and reduce further spread.

1. Export the audit log as CSV from the relevant dashboard.
2. Record the exact timestamps, user, IP address, and object names exported.
3. Disable export permissions for non-admin roles: Settings → Roles/Permissions → remove Export/Download customer data.
4. If your app has no granular export control, temporarily reduce the user's role to the minimum or disable the account entirely.

If your own application stores audit events in a database, pull the relevant rows:

SELECT created_at, actor_email, action, ip_address, target
FROM audit_logs
WHERE actor_email = 'former.employee@example.com'
AND created_at > NOW() - INTERVAL '30 days'
ORDER BY created_at DESC;

Verify it worked: no further export events appear after access removal, and export permission is absent from non-admin roles.

Mailbox forwarding or rules

Remove forwarding, inbox rules, delegates, and connected apps from the mailbox and from any shared inboxes the person managed.

Menu path: Mail admin → Users/Mailboxes → select mailbox → Forwarding/Rules/Delegates/Connected apps.

Delete any rule that forwards externally or copies messages to a personal address. Then reset the mailbox password and revoke active sessions if the mailbox is still enabled.

If you manage a mail server directly, inspect aliases and forwarding files:

sudo grep -R "personal@example.com" /etc/aliases /etc/postfix /home/*/.forward

Verify it worked: sending a test email to the mailbox no longer forwards externally, and audit logs show the rule was removed.

Cloud storage bulk download or sync

Remove the user's device sessions, unlink sync clients, and review externally shared links.

Menu path: Storage admin → Activity/Audit → filter by user → Devices/Sessions → Sign out/Unlink device and Sharing → External links → disable suspicious links.

If files contain especially sensitive customer data, move them to a restricted folder and re-share only with current staff.

Verify it worked: the user has no active device sessions, and new downloads or sync events stop appearing.

Tokens, keys, or surviving sessions

Revoke all API tokens, personal access tokens, OAuth app grants (third-party app permissions), SSH keys, and long-lived sessions associated with the person.

Menu path: Security/API/Access Tokens/Sessions/SSH Keys → Revoke/Delete.

On Linux servers, remove SSH keys from shared accounts too:

sudo sed -i '/former.employee@example.com/d' /home/deploy/.ssh/authorized_keys
sudo systemctl reload sshd

If you suspect a service account was used, create a new token for the application, update the app, then delete the old token.

Verify it worked: the revoked token or key can no longer authenticate, and no new requests appear from its identifier or IP.

Prevention

• Use single sign-on and automatic offboarding. Connect business tools to one identity provider so disabling one account cuts access broadly. In each provider, enable SCIM (automatic user provisioning/deprovisioning) if available: Admin → Security/Identity → SCIM/Provisioning.
• Turn on audit logging and export retention. For every customer-data system, enable Security/Audit logs and schedule monthly exports to secure storage. Keep a simple checklist with columns for system, log path, retention days, and export owner.
• Remove export rights from default roles. In your app and third-party tools, edit roles so only a small admin group can export customer lists. Example policy shape:

{
  "role": "support-agent",
  "permissions": ["customers.read", "tickets.read", "tickets.write"],
  "denied": ["customers.export", "reports.download"]
}

• Ban shared accounts where possible. Replace "marketing@", "admin@", or shared cloud users for admin actions with named accounts plus role-based access. If a shared mailbox must exist, grant access through delegates, not shared passwords.
• Add offboarding checks to your exit process. Use a copyable checklist: disable identity account, revoke sessions, rotate shared secrets, remove mailbox delegates, remove drive access, remove code repo access, remove VPN, review audit logs for last 30 days.
• Alert on suspicious bulk access. In systems that support alerts, create notifications for mass export, many downloads in a short period, new mailbox forwarding rules, and logins from new countries or devices. Even a basic daily review of audit events for actions containing export, download, forward, and token catches a lot.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.