Former Employee Accounts Still Active: What to Check First

When former employee accounts are still active, the first job is not to panic or make a broad claim. The first job is to build a dated, reviewable list: which former employee, which system, which account identifier, what the account status appears to be, who can verify it, what action is needed, and where the source-system evidence will live. The account change itself happens in each underlying system. The register is where you make the risk visible and track the follow-up.

This situation is common in lean IT. Jordan receives a customer security questionnaire asking whether leaver access is removed promptly. He believes the process usually works. Then he checks a project-management tool and finds a contractor account from last year. A finance portal has a former manager as billing admin. A support desk has a shared login nobody owns. The company directory looks clean, but local SaaS accounts tell a different story.

That is the key lesson: a clean primary directory does not prove every account is gone. Many teams have SaaS tools, vendor portals, local admin accounts, service accounts, shared mailboxes, emergency accounts, and department-owned tools outside the neat identity view. This checklist helps you triage those accounts without claiming automatic discovery, directory sync, or deprovisioning.

If you are building the register from scratch, start with what to track in a manual accounts register. If you need the broader leaver evidence process, use the employee offboarding evidence checklist. This article focuses on the specific “former employee accounts may still be active” problem.

Quick answer: what to check first

Check these eight areas first:

1. People status: confirm the person is marked left, inactive, or no longer assigned.
2. Known accounts: list every known account tied to that person.
3. High-risk systems: review identity, finance, payroll, production, customer data, support, code, and admin portals first.
4. Local SaaS accounts: check systems that may not sync from SSO or directory tools.
5. Shared and service accounts: confirm the former employee is not the only owner or recovery contact.
6. Vendor and support portals: check billing, procurement, registrar, hosting, support, and client portals.
7. Access review evidence: record what was reviewed, who reviewed it, and what action is required.
8. Open exceptions: keep unresolved items visible with owner and date.

Do not store passwords, private tokens, recovery codes, or secret hints in the account record. The register should describe the account and evidence, not expose credentials.

Why former employee accounts remain active

Former employee accounts remain active for ordinary reasons.

A tool was bought by a department before IT managed renewals. A contractor used a personal email because onboarding was rushed. A SaaS platform has local accounts even though most systems use SSO. A vendor portal sends billing notices to the original buyer. A service account was created under a person's name. A support portal did not appear in the standard offboarding checklist. A shared login was treated as harmless because everyone used it.

None of those are exotic failures. They are what happens when systems, people, accounts, and renewals live in different lists.

The fix is not to pretend the team can discover everything automatically. The fix is to maintain a small, consistent account record and run a focused review whenever a leaver, former contractor, vendor transition, or access question appears.

Step 1: confirm the person record

Start with the person. You need one row that anchors the account review.

Record:

• full name;
• work email or known account identifier;
• department or role;
• person type, such as employee, contractor, vendor, or service owner;
• status, such as left, inactive, offboarded, or needs review;
• end date;
• last reviewed date;
• owner of follow-up;
• notes that explain context without storing HR-sensitive detail.

The person record gives every account record a human anchor. Without it, the review becomes a pile of usernames and guesses.

Be careful with HR details. The account register does not need reasons for departure, performance notes, personal data beyond what is necessary for access evidence, or private employment context. It needs operational facts.

Step 2: list known accounts before hunting unknowns

Start with accounts you already know about. Do not begin by chasing every possible system. Build a base list first.

Use sources such as:

• People & Accounts register;
• previous offboarding checklist;
• access review exports;
• system admin pages;
• SaaS user exports;
• renewal and vendor records;
• systems catalog;
• finance or billing portal records;
• manager notes;
• old handover records.

For each account, record:

• system name;
• account identifier;
• account type;
• status seen in the source system;
• source of the observation;
• date checked;
• reviewer;
• action required;
• evidence note.

This should map cleanly to your manual accounts register. If account names and system names are inconsistent, fix those before pretending the review is complete.

Step 3: review the highest-risk systems first

Do not review systems alphabetically. Review by risk and impact.

Start with:

• identity and email administration;
• finance, payroll, and billing portals;
• code hosting and production admin tools;
• customer data systems;
• CRM and support tools;
• HR and recruiting systems;
• cloud hosting and infrastructure consoles;
• vendor portals with admin or billing authority;
• systems marked critical or high in the systems catalog.

A former employee account in a low-risk survey tool is still worth cleaning up, but it should not delay review of payroll, production, customer data, or finance access.

Step 4: check local accounts outside the main directory

SSO and directory records are useful, but they are not the whole story. A former employee can be removed from the main directory while local accounts remain in SaaS tools.

Look for:

• tools that support local users;
• vendor portals where accounts are created manually;
• older tools added before SSO;
• free or department-owned SaaS products;
• support portals;
• registrar, hosting, and billing accounts;
• apps used by contractors;
• systems that were retired but not fully closed.

Do not write “all accounts removed” because the primary directory looks clean. Write what was actually checked. For example: “Microsoft 365 account disabled; payroll portal, support desk, CRM, and code hosting checked separately on 2026-07-31.”

That difference is evidence quality.

Step 5: handle shared accounts and service accounts carefully

Shared and service accounts create special problems. A former employee may not own the account personally, but may still know how it works, have access to it, or be the only named owner.

Check:

• shared mailboxes;
• team logins;
• service accounts;
• API users;
• billing accounts;
• emergency access accounts;
• vendor admin accounts;
• accounts where the former employee is listed as recovery contact;
• accounts where the former employee is the named owner but other people use it.

The action may not be “delete account.” It may be:

• assign a new owner;
• rotate credentials in the proper secret-management system;
• remove recovery access;
• downgrade permissions;
• confirm no human login exists;
• split a shared login into named accounts;
• record a temporary exception.

CertPilot should not be used to store the credential or secret. It can record the ownership and evidence note.

Step 6: decide the action state

Each account should end in a clear action state.

Use values such as:

• confirmed removed in source system;
• disabled in source system;
• no access found;
• access still required temporarily;
• owner changed;
• credential rotation required;
• system owner review required;
• business owner decision required;
• unknown, needs investigation.

The worst status is blank. A blank status makes the account disappear from attention. “Unknown, needs investigation” is much better because it creates a real follow-up.

Step 7: preserve evidence without faking certainty

Evidence should say what happened. It should not overclaim.

Good evidence notes:

• “Account disabled in payroll portal by Finance Ops on 2026-07-31; screenshot stored in offboarding folder.”
• “No account found in CRM export checked by RevOps on 2026-07-31.”
• “Support portal user existed; access removed by Support Ops; ticket SUP-1842.”
• “Shared mailbox owner updated from former employee to Support Manager.”
• “Old reporting system has archive account; business owner approved temporary access until data export completes.”

Bad evidence notes:

• “All access removed” when only one system was checked.
• “Compliant” without a defined standard or review.
• “Auditor approved” without actual auditor involvement.
• “Probably removed” because the user no longer appears in the main directory.

The evidence record must be humble. Humble evidence is useful because it survives questions.

Step 8: connect the review to the access matrix

If the former employee had access to important systems, add the review to the access matrix or access-review process.

A row should make clear:

• person;
• system;
• access level or account status;
• reviewer;
• decision;
• action required;
• action owner;
• completion date;
• evidence note.

This gives you a review trail. It also prevents the former employee account problem from being handled as a one-off cleanup that nobody can prove later. For the full matrix pattern, use the user-system access matrix guide.

Worked example: the leaver hidden in SaaS tools

Jordan checks the People & Accounts register and finds a former marketing manager marked left. The main email account is disabled. The offboarding note says “access removed.” That looks fine until a renewal review shows the same person as billing contact for a design tool and admin user for a webinar platform.

Jordan creates a focused review. The design tool has no active login for the person, but billing contact still points to their old address. Finance updates the billing contact and records the change. The webinar platform has a local admin account. Marketing confirms the account is no longer needed. The technical owner disables it in the source system and records the action. A shared social tool lists the former manager as recovery owner. The team assigns a new owner and schedules credential rotation in the approved password-management workflow.

The final evidence does not say “everything was always fine.” It says what was found, what changed, what remains open, and who owns it. That is far stronger.

What to report to management

Keep the management note short:

• “We reviewed former employee accounts for high-risk systems first.”
• “Three account exceptions were found: one billing contact, one local SaaS admin, one shared-account owner.”
• “Two were remediated in source systems; one credential-rotation task remains assigned to IT.”
• “The People & Accounts register and access review record were updated.”
• “No automatic connector or monitoring claim is being made; this was a manual review.”

Management does not need every screenshot. It needs a clear evidence trail and an owner for remaining risk.

Former employee account exception packet

When a former employee account is found, create a small exception packet. This avoids two weak outcomes: a panicked chat thread with no evidence, or a broad “fixed” statement nobody can prove later.

The packet should include:

Person context

Record the person’s working name, work email or account identifier, person type, department or role, status, end date, and review owner. Keep it operational. Do not add private HR details, reasons for departure, performance notes, personal disputes, or anything the access review does not need.

Account context

Record the system name, account identifier, account type, source-system status, last observed date, reviewer, and source of observation. If the account appeared in a vendor export, say that. If it appeared in a screenshot, ticket, admin console, or billing portal, record that source.

Risk context

Describe why the account matters:

• administrator access;
• billing or finance access;
• customer data access;
• production or code access;
• support portal access;
• shared mailbox or recovery ownership;
• service account ownership;
• low-risk account but stale ownership.

Do not inflate the risk. A low-risk stale account is still worth cleaning up, but it should not be described as a breach unless there is evidence.

Decision context

Record the review decision:

• remove access;
• disable account;
• confirm no access;
• reassign ownership;
• rotate credential through approved process;
• keep temporarily with business approval;
• escalate to system owner;
• unknown, needs investigation.

The decision should have an owner and date. “Needs review” without a due date is another hiding place.

Action context

Record where the actual action happened. If access was disabled, say which source system. If a credential was rotated, reference the correct ticket or secret-management process without exposing the secret. If ownership changed, name the new role or owner.

Evidence context

Record where proof lives:

• offboarding checklist;
• access-review completion note;
• source-system ticket;
• vendor confirmation;
• screenshot location;
• register export;
• management report summary.

The point is not to collect every artifact forever. The point is to make the evidence retrievable when someone asks what happened.

Open-item context

If the account cannot be closed immediately, record why:

• data export pending;
• business owner needs archive access;
• replacement owner not assigned;
• vendor support ticket open;
• credential rotation scheduled;
• system owner unavailable;
• legal or HR hold requiring approved handling.

Open exceptions are acceptable when they are owned, dated, and reviewed. Silent exceptions are not.

A first-week cleanup sprint

If the team suspects former employee accounts exist across several systems, run a one-week cleanup sprint instead of trying to solve the entire company at once.

Day 1: define the leaver population

Create a list of former employees, contractors, and vendor users in scope. Start with the last 90 days if the backlog is large. If that is clean, extend to the last year. For each person, confirm status and end date in the People & Accounts register.

Day 2: choose high-risk systems

Pick a realistic first scope: identity, finance, payroll, CRM, support, production admin, code hosting, and any system marked critical in the systems catalog. Do not spend the first sprint on every low-risk tool.

Day 3: export or observe account lists

For each system, have the authorized system owner check account lists. Record the observation source and date. Do not claim discovery beyond the systems actually checked.

Day 4: classify exceptions

Group findings by action: remove, disable, reassign owner, confirm no access, rotate credential, temporary exception, unknown. Assign an owner to every unresolved row.

Day 5: close what can be closed

Make approved changes in the source systems. Update account records and access-review notes. Do not use the register as a substitute for the actual access change.

Day 6: write management summary

Report count and quality, not drama: systems reviewed, former users checked, exceptions found, actions completed, open items, owners, and next review scope.

Day 7: decide the next scope

If high-risk systems produced many exceptions, continue with the same control family. If they were clean, extend to vendor portals, retired systems, department SaaS, and shared/service accounts.

This sprint creates momentum without pretending a week of manual work equals complete automatic discovery.

Where CertPilot fits

CertPilot’s People & Accounts register can track people, statuses, account identifiers, account status, status dates, and notes. Access Reviews can record person-system review decisions, actions required, completion evidence, and reports.

CertPilot does not sync from Google Workspace or Microsoft 365 today. It does not automatically discover accounts, disable access, remove users, rotate credentials, monitor employee activity, or read emails, documents, chats, files, prompts, or responses. It records the manual evidence your team maintains.

Frequently Asked Questions

What should I do first if I find a former employee account still active?

Confirm the source system, account identifier, account status, reviewer, and business or technical owner. Then decide the required action in the source system and record the evidence note after the action happens.

Does a disabled Google Workspace or Microsoft 365 account prove all access is gone?

No. It proves that account state in that directory. Local SaaS accounts, vendor portals, shared accounts, support portals, service accounts, and retired systems may still need separate review.

Should I delete old account records after offboarding?

Usually no. Keep a record that the account existed, what status it reached, when it was reviewed, and where evidence lives. Deleting the record can remove useful proof.

Can CertPilot remove former employee access automatically?

No. CertPilot records people, accounts, access-review decisions, and evidence. It does not remove access from source systems.

How often should former employee accounts be reviewed?

Review them during offboarding, after major system changes, during access reviews, and whenever a renewal, handover, or customer evidence request exposes uncertain account ownership.