Catch departed employees who still have system access

Every weekday at 6am, audit for departed employees who still have live access, and report what you find without changing anything.

Start in Workday. Use WQL – Run Query to list workers whose termination date falls within the last 30 days, returning at minimum full name, work email, termination date, manager, and business unit or department. If we already maintain a terminations report in Workday, use Report-as-a-Service – Run Custom Report against that report instead, since it already reflects the filters our HR team cares about. Note that Workday has no dedicated list-terminated-workers REST operation, so WQL is the sanctioned way to query termination dates.

For each terminated worker, look them up in Okta with Retrieve User, using their Workday work email as the login. If that returns nothing, fall back to List Users with a search filter on the profile email address, because a work email in Workday does not always match the Okta login exactly. If there is genuinely no matching Okta account, record that person as clean and move on.

Flag anyone whose Okta account is not fully deprovisioned as of a date later than their termination date. Interpret status like this: ACTIVE, LOCKED_OUT, PASSWORD_EXPIRED, or RECOVERY all mean the account is still live and are the highest concern. SUSPENDED means sign-in is blocked but application assignments and group memberships are still attached, so it is still an outstanding finding, just at lower severity, and say so explicitly in the report. DEPROVISIONED is clean, exclude it.

For each flagged person, gather the blast radius. Use List User App Links to get the applications still assigned to them, and List User Groups to get their group memberships. If a particular application looks especially sensitive and you want to confirm the assignment or see who else is on it, use List Application Users for that specific app.

Rank the findings worst case first. Score each person on two factors: how many days have elapsed since their termination date, and how sensitive the applications they can still reach are. Treat these as high sensitivity: finance and payroll systems, cloud infrastructure and code repositories, administrative consoles, CRM and customer data systems, email and file storage, and security tooling. Group names that imply elevated privilege, anything containing admin, superuser, prod, or owner, should also raise severity.

Post one prioritized alert to our security Slack channel using Send a Message. Lead with a one-line summary giving the number of people still holding access out of the number of departures checked. Then list each person worst case first with: full name, work email, termination date, days elapsed, current Okta status, the applications still assigned with the sensitive ones called out, group memberships, and the Okta user ID so a human can go straight to the account. Include enough detail that a reviewer can act without opening Workday themselves.

Do not deactivate, suspend, or unassign anything. This workflow is report-only by design. Never call Deactivate User, Suspend User, or Unassign User from Application. Automatically revoking access on an HRIS data mismatch is how people get locked out on their first day back from leave, and security teams want to review before revoking.

Stay silent on clean days. If every terminated worker is either fully deprovisioned or has no Okta account at all, post nothing. The channel should only light up when something is actually outstanding, otherwise the alert loses its signal value.

Watch for false positives rather than suppressing them. Rehires, workers holding a second active job, and contingent-to-permanent conversions all produce a termination record alongside legitimate ongoing access. If Workday shows a later active record for the same person, keep them in the report but note the likely explanation inline so the reviewer can dismiss it quickly.