SOC 2 People Management: Onboarding, Offboarding, and Access Lifecycle
How to build people management processes that satisfy SOC 2 CC6.2, CC6.3, and CC6.4 — from new hire access provisioning to offboarding checklists and access revocation SLAs.
People Are Your Largest SOC 2 Attack Surface
CC6.2, CC6.3, and CC6.4 together address the human side of access control: how access is provisioned when someone joins, how it's updated when their role changes, and how it's revoked when they leave. These three criteria generate more SOC 2 findings than almost any other area — not because companies don't care, but because people processes are harder to automate and monitor than infrastructure configuration.
The typical finding: access was provisioned broadly at hire and never narrowed as the role evolved; a departed employee had active access 60 days after their last day; no offboarding checklist was followed, leaving orphaned accounts across 12 different SaaS tools.
CC6.2 — Access Provisioning at Hire
Before granting access to any system, access should be formally requested and approved.
Minimum process:
What auditors check: They sample onboarding access grants and verify that each access grant was preceded by an approval. They also check for over-provisioning — did the new hire receive AdministratorAccess on AWS when they only needed EC2 instance access?
New hire access baseline (least privilege):
- GitHub: repository-level Read on the repos relevant to their team
- AWS: Role-specific IAM permissions, not AdministratorAccess
- Google Workspace: standard user account (not admin)
- All tools: individual credentials, not shared accounts
CC6.3 — Access Changes on Role Changes
When an employee is promoted, transfers to a new team, or changes responsibilities, their access needs to change — both gaining new access appropriate to their new role and losing access no longer appropriate.
This is the access change that teams most often neglect. Onboarding and offboarding are triggered by clear events. Role changes are continuous and easy to miss.
Process to document:
- Manager submits a role change request that lists access to add AND access to remove
- IT/DevOps updates access within defined SLA (7 days is typical)
- Old access is confirmed removed, new access confirmed provisioned
The quarterly access review (CC6.1) is the backstop — it catches role changes that slipped through without triggering an access update. But the policy should require updates at the time of the role change, not wait for the quarterly review.
CC6.4 — Offboarding and Access Revocation
Access revocation on departure is the highest-risk access lifecycle event. A terminated employee with active access is a clear SOC 2 finding — and a real security risk.
Offboarding checklist:
Within 2 hours of termination notification:
- [ ] Suspend Google Workspace / Microsoft Entra ID SSO account (blocks all SSO-protected apps)
- [ ] Disable AWS IAM console access and access keys
- [ ] Remove from GitHub organization
- [ ] Revoke Slack access
- [ ] Remove from all shared password manager vaults
Within 24 hours:
- [ ] Revoke all remaining application accounts not covered by SSO
- [ ] Recover company-issued equipment (if applicable)
- [ ] Transfer ownership of files, tickets, code repositories
Within 7 days:
- [ ] Full audit to confirm no remaining access across all systems
- [ ] Document offboarding completion with checklist signed by IT/HR
What auditors do: For a sample of employees who departed during the observation period, they check the IAM Credential Report, GitHub organization member list, and your offboarding records to verify that access was revoked within the stated SLA.
Connecting HR Systems to Access Revocation
The most reliable offboarding process is automated: when HR marks an employee as terminated in your HRIS (Rippling, Gusto, Workday), an automated workflow triggers access revocation in Google Workspace and downstream SSO-protected tools.
If full automation isn't in place, at minimum: the HRIS termination event should automatically notify the IT/DevOps lead, who owns the offboarding checklist.
SecureSpect People Module
SecureSpect's People module tracks employees and contractors with access to in-scope systems — their access provisioning records, role change history, and offboarding completion status. When an employee is marked as offboarded, SecureSpect's access review checks will surface any remaining active accounts, creating an automated catch for incomplete offboarding. The module links directly to the quarterly access review workflow, so reviewing access per-person is built into the same process as reviewing access per-system.
