Runbook — Onboard Team Member

SOC 2-grade onboarding checklist. Use for every new team member (founder, employee, contractor, advisor with system access).

Pre-arrival

Owner	Action
Hiring manager (Taha or Asad)	Open a Linear / GitHub onboarding issue with role, start date, scope of access, and supervisor. Title: [Onboarding] <name> — <start-date>
Hiring manager	Decide what level of access the role requires. Default to the smallest viable set; expand by request.
Hiring manager	Confirm BAA-coverage scope. If the role will see PHI, confirm Asad-signed Workforce Confidentiality Agreement is in place before Day 0.
Compliance Liaison (Asad)	Confirm employee acknowledgment of: Code of Conduct, Acceptable Use Policy (when written), Privacy Policy, and HIPAA Workforce Awareness brief. Even informal acknowledgment via email goes into the onboarding issue thread.

Day 0 — identity provisioning

Identity domain	Action	Who	Verify
Google Workspace	Create <firstname>@askflorencehealth.com user; assign appropriate role / OU; require MFA enrollment within 24h	Taha (Cloud Identity admin)	User logs in successfully + MFA enrolled in admin console
AWS SSO	Assign appropriate permission set(s) per access-control policy at the right account(s)	Taha	User can aws sso login + assume the permission set
GitHub	Add to askflorencehealth org with appropriate team membership (Engineers, Comms, etc.)	Taha	User accepts invite + MFA enrolled (org requires it)
MongoDB Atlas	If role requires Atlas access: invite to Atlas org with Project Read Only or higher role per scope; explicit MFA required	Taha (Atlas org owner)	User accepts invite + MFA enrolled in Atlas
HubSpot	If role requires CRM access: assign appropriate role	Ian (HubSpot admin)	User logs in + MFA enrolled
Linear / GitHub Projects	Add to workspace + project boards relevant to role	Hiring manager	User can view + create issues
Local environments / dev shells	If engineering: pair on .env.local setup using the team password manager; never email credentials	Engineering Responder	User can run dev locally

MFA enrollment must complete before any access is granted. If hardware MFA is in place (post #67), enrolling the YubiKey is part of Day 0.

Day 1-7 — context + acknowledgment

Owner	Action
Hiring manager	Walk through CLAUDE.md + AGENTS.md + project board + active issues
Hiring manager	Tour the docs site — especially docs/security-compliance/ (this directory) so the new member knows where policies live
Compliance Liaison	Walk through Incident Response Plan — who pages whom, when, why
Compliance Liaison	Confirm BAA Workforce Awareness brief acknowledged: HIPAA = PHI handling rules; do not paste PHI into Claude, Slack, iMessage, etc.; secret-handling rules per CLAUDE.md Security rules section
Hiring manager	If role requires Atlas write access: walk through Atlas user provisioning runbook and the narrow-scoped-user pattern (ADR 0003)
Engineering Responder	If engineering: pair on first PR to validate the local dev + CI flow

Record-keeping

Update these files within 5 business days of Day 0:

1. docs/infrastructure/atlas-access-matrix.md — if Atlas user added (CI sync from infra/atlas/access-matrix.ts; edit the source TS file + push)
2. Quarterly access review file at docs/infrastructure/access-reviews/<year>-Q<n>-review.md — add row to the "Joiners this quarter" section
3. Vendor / subprocessor register — no change unless the role triggers a new vendor adoption
4. agent_audit_log collection — once Phase 5 lands, write a row per identity-domain grant. Until Phase 5: the Linear / GitHub onboarding issue + access-review row is the audit artifact.

Onboarding-issue closeout

The onboarding Linear / GitHub issue closes when:

• All Day-0 access provisioning verified
• All Day-1-7 acknowledgments captured in the issue thread
• All record-keeping updates committed
• The hiring manager confirms the new member is operating successfully

Special cases

Contractors

Same Day-0 procedure. Add:

• Time-bound access — Atlas + AWS SSO assignment specifies an expected end date. Quarterly access review confirms the assignment is still needed; revoke at end date if no extension.
• Contractor agreement on file before any production data flows.

Advisors with read-only access

Typically:

• AWS SSO security_audit permission set, 4h sessions
• Atlas: Project Read Only role on the relevant project
• GitHub: read-only org membership

No Atlas write access. No HubSpot access. No production secrets.

Founders / equity-holders

Standard procedure plus:

• Cap-table-related access (Carta, etc.) handled by Asad separately from this runbook
• Insurance enrollment per benefits onboarding

Reference

• Access Control Policy
• Offboard Team Member runbook
• Atlas user provisioning
• Vendor / Subprocessor Register
• Privacy Impact Assessment — what PII the new member will see + how to handle it