Runbook — Offboard Team Member

SOC 2-grade offboarding checklist. Use for every leaving member (founder, employee, contractor end-of-engagement, advisor end-of-relationship).

Day 0 — immediate revocation

Triggered the same day the team member departs (last day of employment / end-of-engagement). For involuntary departure, revocation precedes the announcement.

Identity domain	Action	Who	Verify
Google Workspace	Suspend account (do not delete — preserves mail + Drive for retention period per data retention policy); transfer ownership of any team-owned Drive folders; disable forwarding rules	Taha (Cloud Identity admin)	Login disabled; mailbox preserved per Vault retention rule
AWS SSO	Remove all permission set assignments; if applicable, revoke active SSO sessions via aws sso-admin delete-account-assignment	Taha	Cannot aws sso login
GitHub	Remove from askflorencehealth org; revoke any personal access tokens that were granted to AskFlorence repos; remove from any teams	Taha	Cannot access repos
MongoDB Atlas	Remove from Atlas org (all projects, all roles)	Taha (Atlas org owner)	Cannot log in to Atlas
HubSpot	Remove user account	Ian (HubSpot admin)	Cannot log in
Linear / GitHub Projects	Remove from workspace; reassign open issues	Hiring manager	Cannot create or modify
Local environments	Member confirms .env.local removed; revoke any local Atlas API keys they had	Hiring manager	Member confirms by email
Hardware (if applicable)	Recover company-issued laptop / YubiKey / any other physical device; confirm FileVault encryption was on (Day 0 onboarding state); wipe the device per encryption policy	Hiring manager	Device wiped; YubiKey deregistered from all identity domains

Day 0 — credential rotation

For every credential the offboarding member had direct access to:

Credential	Action	Who
Atlas user passwords (app_writer_*, app_admin_*, audit_reader)	Rotate any passwords the member had access to (via .env.local shared secrets)	Taha
AWS Secrets Manager — any secret value the member can recall (CMS API key, etc.)	Rotate via aws secretsmanager update-secret + deploy task-def update	Taha
GitHub repo secrets (gh secret set)	Rotate any secrets the member had access to (ATLAS_DRIFT_CHECK_*, etc.)	Taha
Founder password manager — any shared vault entries	Rotate per item or move to a fresh vault	Hiring manager
Team SaaS shared logins (avoid these; if any exist, rotate password)	Rotate via the SaaS UI	Hiring manager

Rotation is defensive — assume compromise even when departure is amicable. The cost of rotation is low; the cost of post-departure leak is high.

Day 0 — write audit-log row

Once Phase 5 lands agent_audit_log-side admin actions:

db.agent_audit_log.insertOne({
  timestamp: new Date(),
  actor_id: "taha@askflorence.health",
  actor_role: "admin",
  action: "offboard_team_member",
  resource_type: "user",
  resource_id: "<departing-member-email>",
  ip_address: "<current-IP>",
  user_agent: "<browser-UA>",
  result: "success",
  metadata: {
    departure_reason: "voluntary | involuntary | contract_end",
    revocations: ["google_workspace", "aws_sso", "github", "atlas", "hubspot", "linear"],
    credentials_rotated: ["atlas_app_writer_*", "cms_api_key", "..."],
    hardware_recovered: true|false,
  },
});

Until Phase 5: the offboarding Linear / GitHub issue + the quarterly access review entry is the audit artifact.

Day 1-7 — finalize

Owner	Action
Hiring manager	Reassign all open issues, in-progress PRs, and ownership rows in CLAUDE.md / docs/* / scripts/* (look for @<departing-handle>, "Owner: <name>", etc.)
Compliance Liaison	Update vendor-register if the departing member was a designated point-of-contact (insurance, vendor relationships, etc.)
Hiring manager	Walk through the next quarterly access-review file and add an entry under "Leavers this quarter"
Hiring manager	Final-pay + benefits offboarding per HR (out of scope for this runbook)

Record-keeping

Update these files within 5 business days of Day 0:

1. docs/infrastructure/atlas-access-matrix.md — remove the offboarding member's row (via infra/atlas/access-matrix.ts)
2. Quarterly access review file at docs/infrastructure/access-reviews/<year>-Q<n>-review.md — add row to "Leavers this quarter"
3. CLAUDE.md — if the departing member was named in the Team section or any ownership rows, update to current state

Post-departure period

For 90 days after departure:

• The Compliance Liaison + Hiring Manager monitor for any login attempts to the offboarded accounts (CloudTrail + Atlas audit + Google Workspace login audit). Any post-departure attempt triggers the Incident Response Plan.
• At the next quarterly access review, confirm zero post-departure activity.

After 90 days:

• Google Workspace mailbox can be archived to Vault retention (per data retention policy) and the user account deleted (NOT before; deleting before transfers can lose Drive ownership).

Special cases

Involuntary departure (security-relevant)

Revocation precedes the announcement. Specifically:

1. Hiring manager triggers Day-0 revocations + rotations in advance (typically 1-2 hours before the conversation with the departing member).
2. The Incident Commander is on standby in case the departing member retaliates / exfiltrates / etc.
3. Treat any post-departure access attempt as SEV-1 Incident Response until confirmed otherwise.

Contractor end-of-engagement

Same procedure. Contractor access was time-bound at Day-0; offboarding ensures the time-bound assignment is revoked even if the end-date passed without an explicit revocation step.

Founder departure

In addition to the standard procedure:

• Cap-table-related actions (vesting acceleration, share repurchase, etc.) handled by Asad separately
• Pre-existing board / advisor representations updated per agreement
• The departing founder may need read-only AWS / Atlas access for a transition period; assign security_audit permission set with explicit end-date

Reference

• Access Control Policy
• Onboard Team Member runbook
• Atlas user provisioning
• Incident Response Plan
• Data Retention Policy — mailbox + Drive retention after suspend
• Risk Assessment R-001 — single-cofounder admin risk informs urgency of second-principal provisioning