Security playbook · AI Employee: Sig

Employee Offboarding

Zero standing access within 1 hour of termination

Install this playbookBack to marketplace
The problem

Employee offboarding from a security perspective isn't just "disable the account." It's revoke every SSO session, invalidate every long-lived credential the person created, remove them from every access group, wipe the device, transfer file ownership, revoke API keys they generated, drop them from every shared secret vault, review their code contributions for embedded secrets, and audit their activity in the last 30 days for anything unusual. Miss any of these and either data walks out the door or an ex-employee retains access for weeks.

At a glance
Trigger
HRIS event
Approvals
Security reviews any account it cannot deprovision
What it does
Writes to your systems
Systems
Okta · Google · M365 · Slack · GitHub · AWS · Salesforce
How it feels in production

An hour-by-hour walkthrough.

HR marks John's termination in Workday, effective 2026-09-15 at 17:00. Sig picks up the event 30 minutes before, assembles the offboarding plan, and stages every action to fire in coordinated sequence at 17:00 sharp. At T-30 minutes: - Inventory of John's access: 47 SaaS apps via SSO, 12 direct API keys, 3 personal access tokens in GitHub, 2 AWS IAM users, ownership of 4 GitHub repos, admin on 6 Slack channels, member of 89 shared drives - Detect any recent anomalies: unusually high download volumes from Google Drive last 3 days? Unusual after-hours SSH sessions? Sig scores 0-1 and flags for security review if high - Prepare file-ownership transfer to designated successor (from manager's offboarding form) - Prepare device wipe command (queued, not yet executed) At T-0 (17:00): - Okta account suspended → cascades SSO to every connected app (revokes active sessions company-wide) - Long-lived credentials (API keys, PATs, service accounts he created) rotated or revoked - IAM access removed across AWS, GCP, Azure - GitHub org membership removed, personal fork detached - Ownership of shared documents transferred per policy (usually to manager) - Device MDM wipe command queued (executes on next check-in) - Password rotation on any shared vault entries John had access to - Code contribution scan for embedded secrets that could survive his departure Sig produces a full offboarding record: who lost access to what, when, and confirmation that each write succeeded. HR sees the completion; security sees the audit trail; auditor sees the evidence.
How it works

Step by step.

  1. 01

    Pre-offboarding inventory + anomaly check

    Inventory of every access surface, credential, and ownership relationship at T-30. Anomaly detection: unusual activity in the last 30 days (downloads, code exports, credential creation, unusual hour access).

    Okta · GitHub · AWS · Google Vault · Anomaly detection
  2. 02

    Stage the offboarding plan for the effective time

    Plan queued for the exact effective time (usually end-of-day or as-specified by HR). Actions in sequence: SSO first (blast radius contained), then per-system removals, then device wipe, then ownership transfer.

    Scheduler · Runbook · Coordination engine
  3. 03

    Execute at T-0 in coordinated sequence

    Okta suspend cascades most SSO apps in seconds. Direct writes for non-SSO systems (GitHub, AWS IAM, third-party APIs). Every action confirmed; failures retry then escalate.

    Okta · GitHub · AWS · Third-party APIs · MDM
  4. 04

    Handle credentials + shared secrets

    Every API key John personally created: rotated or revoked. Personal access tokens: revoked. Shared vault entries he could access: rotated. Code scan for hardcoded secrets that survive after departure.

    Vault · HashiCorp · Secret scanning · Credential registry
  5. 05

    Ownership transfer + audit record

    Files, projects, Slack channels transferred to designated successor (from HR form). Full audit record: what was revoked, what was transferred, timestamps, confirmations. Handoff to security for anomaly review.

    Google Drive · Notion · Slack · Audit log · Successor registry
Systems and wiring

What you connect to make this run.

Workday · BambooHR · HRIS

read

Termination event trigger. Effective time (exact minute), manager designation of successor for ownership transfer, termination reason (affects security-review depth for high-risk terminations).

Okta · Google Workspace · Microsoft Entra

read+write

Identity plane suspension cascades SSO removal to most apps. Session revocation active-first (kicks user out immediately) then account suspension.

GitHub · AWS · GCP · Azure · Third-party APIs

read+write

Systems without SSO integration require direct API removal. Per-system runbooks maintained. Credentials rotated where the departing employee could have exported.

MDM · Endpoint management

write

Device wipe queued at T-0, executes on next device check-in. Personal data preserved only if BYOD; corporate devices fully wiped per policy.

What changes

Before and after, honestly.

Time from effective time to full access revocation
Before
6 hours to 3 days
After
Under 15 minutes
Ex-employee accounts with residual access after 7 days
Before
8-25%
After
Under 0.5%
Long-lived credentials rotated on departure
Before
10-30% (only obvious ones)
After
98%+ (systematic inventory)
Post-departure security incidents (ex-employee)
Before
2-8 per year
After
0-1 per year
Related

Playbooks that pair with this one.

HR

Employee Offboarding

HR side of the same offboarding; joint coordination for the effective moment.

IT

Contractor Access Expiration

Same mechanism for contractors on engagement end.

Security

User Access Reviews (UAR)

Quarterly review catches residual access this daily flow may have missed.

Frequently asked

Answers about this playbook.

What about high-risk terminations (fired for cause)?

High-risk flag from HR triggers accelerated timeline (immediate revocation, not effective-time-scheduled), deeper anomaly review, and preservation-hold on all their data pending legal review.

How does it handle voluntary departures where the employee needs access to wrap up?

Configurable wind-down period per policy. Employee retains scoped access (read-only, no export) for a defined window. All actions logged in a separate audit view.

What about ownership of code contributions after departure?

Code stays; author history preserved. Repository access removed. Any personal forks of company repos detached (either transferred to successor or removed per policy).

What about ex-employees returning as contractors or rehires?

Return event triggers new-provisioning flow with the audit history intact. Prior access removed on original departure stays removed; new access granted per current role.

How does it handle service accounts the person owned?

Service accounts owned by the departing employee flag for ownership transfer. If no successor, escalates to security lead for reassignment. Rotation of any credentials the person had access to.

See it run on your data.

Free plan, no credit card. Connect the systems this playbook needs and run it against a past event first.

Book a demoMore Security playbooks