SOC 2 people controls: HR's part of the audit, in plain English

SOC 2 readiness panic usually arrives the week before kickoff. The CISO forwards the auditor's request list, HR scrolls down, and there it is — 'sample 25 hires from the audit period and provide background check results, signed code of conduct, security training completion, and provisioning ticket per system.' By then it's too late to retroactively run a background check on someone who started seven months ago. The trick is not to memorise the framework. The trick is to know which controls land on HR, wire the evidence collection into the workflow itself, and run the audit on autopilot for years. This guide is the long version of that playbook — written for a People Ops lead, an HR Business Partner supporting engineering, or a founder doing it themselves for the first time.

What SOC 2 actually is (and isn't)

SOC 2 stands for 'Service Organization Control 2.' It is an attestation report — not a certification — issued by an independent CPA firm under the AICPA's SSAE 18 attestation standards. The CPA evaluates a service organisation's controls against the Trust Services Criteria (TSC), a framework published by the AICPA's Assurance Services Executive Committee and last substantively revised in 2017 (with the 2022 'points of focus' update). The five TSC categories are Security (mandatory, often called the 'Common Criteria' or CC), Availability, Processing Integrity, Confidentiality, and Privacy. The vast majority of B2B SaaS SOC 2 reports cover Security only, sometimes Availability and Confidentiality as well.

There are two report types and the difference matters. A Type I report is a point-in-time snapshot: on date X, were the controls designed appropriately? A Type II report covers an observation window, typically 6 or 12 months, and asks: did the controls operate effectively across that window? Type I can be issued after 30-60 days of readiness work. Type II requires you to actually live the controls — run access reviews on cadence, complete training on time, offboard within SLA — for the full window. Enterprise buyers (anyone with a real procurement function, anyone in financial services or healthcare, anyone whose data you touch in a regulated jurisdiction) will ask for Type II. Type I is a useful waypoint, not a destination.

Why a third of the audit lands on HR

Security people sometimes assume SOC 2 is a firewall, encryption, and pen-test affair. It is not. The TSC framework is built on the COSO Internal Control — Integrated Framework (Committee of Sponsoring Organizations, 2013), and COSO opens with 'Control Environment' — the tone, integrity, ethics, competence, accountability, and structure of the people who run the company. Every one of those is an HR artefact. That's why CC1 (control environment) is almost entirely HR-owned, CC2 (communication and information) leans heavily on HR for the internal communication portion, and CC6 (logical and physical access controls) cannot operate without HR feeding the identity provider every joiner, mover, and leaver event in real time.

In practice, when an auditor samples 100 controls across a SOC 2 Type II engagement, roughly 25-35 of them require HR-produced evidence — signed acknowledgements, training completion logs, background check records, provisioning approvals, termination timestamps, access review sign-offs. The audit fails or passes on HR's evidence discipline as much as on the security team's tooling.

The HR-owned controls, mapped to TSC

There is no canonical 'HR control list' — each auditor scopes slightly differently — but the table below is the working set you should expect in any reasonable SOC 2 Security engagement. The references (CC1.1, CC6.2, etc.) follow the 2017 TSC numbering, which is what every Big 4 and reputable boutique still uses.

What 'evidence' really means to an auditor

This is the single most misunderstood part of SOC 2 readiness for HR teams. 'We do this' is not evidence. 'Here is our policy' is not evidence. Evidence has three components, and the auditor will reject anything that lacks one of them.

Auditors work by sampling. For most controls the sample size is around 25 items if the population is over 250, scaled down for smaller populations (typically 10 for 50-249, 5 for under 50, 100% for under 10). They pick the sample — you don't get to choose. If even one item in the sample fails, the control is qualified or excepted, and that exception lands in the final report your buyers will read.

Joiner-Mover-Leaver: the spine of the audit

If you do nothing else this year, automate Joiner-Mover-Leaver (JML). It is the single highest-leverage SOC 2 investment HR can make. JML is the discipline of treating every employment-status change as a trigger that fans out into provisioning, training, access changes, and de-provisioning actions across every system that holds company data. Done well, JML produces an unbroken audit trail without anyone manually generating evidence.

The Joiner flow

1. Recruiter marks candidate 'offer accepted' in the ATS. This is the upstream signal — everything downstream depends on it being accurate.
2. ATS pushes the new hire record to the HRIS (Rippling, Deel, BambooHR, Workday) with start date, role, manager, location, and employment type. If you don't have an ATS→HRIS integration, you have a SOC 2 problem disguised as a productivity problem.
3. HRIS triggers the background check via integrated provider (Checkr, HireRight, Sterling, Veremark). Result is filed against the employee record before the start date. No clean check, no start.
4. On Day -7, IT provisioning ticket auto-opens in the IdP (Okta, JumpCloud, Entra ID) listing the standard role-based access bundle. Manager approves in one click.
5. On Day 0, IdP provisions accounts via SCIM to every downstream SaaS app. Provisioning timestamps are logged in the IdP — those logs are your evidence.
6. On Day 1, the LMS (Lessonly, Workramp, KnowBe4, Vanta Training) assigns mandatory security awareness, code of conduct acknowledgement, and acceptable use policy. Completion deadline: Day 14.
7. On Day 14, if any item is incomplete, the IdP suspends the user until completion. This is the 'enforce or it's just a suggestion' rule.

The Mover flow

Movers are where audits quietly fall apart. Someone moves from Support to Engineering, gets the new access they need, but nobody removes their old Zendesk admin role. Six months later the auditor pulls the Zendesk admin list, sees a name that no longer belongs to a Support employee, and you have an exception. The fix: every role change in the HRIS triggers a 'mover review' ticket that asks the new and old manager to confirm what access should be added and what should be removed. The IdP then enforces the delta.

The Leaver flow

1. Manager submits resignation acceptance or termination decision in HRIS. Last working day field is mandatory.
2. For voluntary leavers: scheduled de-provisioning at end of last working day. For involuntary terminations: immediate de-provisioning, ideally before the conversation ends.
3. HRIS termination event fires a webhook to the IdP. IdP suspends primary account and triggers SCIM de-provisioning across every connected app.
4. For non-SCIM apps (still common — Notion, Figma, Linear if not on enterprise plans, GitHub Enterprise without SAML, niche SaaS), a runbook ticket auto-generates listing every app to revoke manually, with a 24-hour SLA and a checkbox per app.
5. On Day +1, an exception report runs: any account belonging to a terminated employee that is still active. The report should be empty. If it isn't, that's a CC6.5 exception waiting to happen.

Background checks done audit-proof

Background checks (BGC) are deceptively simple to get wrong. The control is not 'we run background checks.' The control is 'we run a documented, role-appropriate, jurisdiction-compliant background check before access to systems is granted, and we retain evidence of the result for the audit window.' Each clause hides a failure mode.

• Use an integrated BGC vendor (Checkr, HireRight, Sterling, Veremark, Zinc) that posts results back to the HRIS — no PDFs in someone's inbox.
• Get candidate consent in writing before initiating. In the US, FCRA requires a stand-alone disclosure plus written authorisation; in the UK/EU, you need a lawful basis under GDPR Art. 6 and explicit safeguards for criminal data under Art. 10.
• Treat the start date as conditional on a clean check. If a check returns adverse information, run the FCRA 'pre-adverse / adverse action' two-letter sequence (US) or equivalent in your jurisdiction. Document the decision.
• Never grant production system access before the check clears. The auditor will sample provisioning timestamps against BGC clearance timestamps.
• Apply the same standard to contractors who will touch production data. SOC 2 does not distinguish between W-2 and 1099 — the control follows the access, not the tax form.
• Retain results for the legal retention period (varies — typically minimum 1 year post-employment under FCRA; longer under most EU regimes; check with employment counsel).

Security awareness training that survives sampling

Auditors will sample training completion. They'll pick 25 employees, ask for their training completion records covering the audit window, and expect to see (a) onboarding security training completed within X days of start, (b) annual refresher completed within the calendar year, (c) records of any phishing simulation or role-specific add-on. The killer is the long tail — five out of 25 will be missing if you didn't enforce.

Quarterly access reviews without the spreadsheet pain

Quarterly user access reviews (UAR) are the most operationally painful SOC 2 control to run by hand and the easiest to automate badly. The intent: every quarter, every manager confirms that every direct report's access to every in-scope system is still appropriate. Done in spreadsheets, this is a soul-destroying exercise that produces low-quality sign-offs. Done in a UAR tool (Vanta, Drata, Sprinto, Secureframe, Conductor One, Lumos, or a workflow built on your IdP's certification feature) it takes each manager 10-20 minutes a quarter.

1. Define the in-scope systems list. Start with anything that holds customer data, production infrastructure, or financial data. Typically 8-15 systems for a Series A-C SaaS company.
2. Tag each entitlement with risk: read-only / standard / admin. Admin entitlements get extra scrutiny and named approval.
3. On the first day of each quarter, the tool snapshots access per user per system and routes a review task to each user's manager.
4. Manager confirms 'keep' or 'revoke' per entitlement. Revokes generate a ticket to the IdP/system owner with a 5 business-day SLA.
5. On Day 14 of the quarter, any incomplete reviews escalate to the manager's manager. On Day 21, to the CISO and the Head of People.
6. On Day 30, the review is closed. The tool produces a tamper-evident report with sign-offs, revocations, and exceptions. That report is your audit evidence.

Contractors, interns, and the scope trap

'They're not full-time, so SOC 2 doesn't apply' is one of the most reliable ways to fail an audit. SOC 2 scope follows access, not employment classification. If a contractor, intern, agency worker, or vendor employee can log into a system in scope, every HR-owned control applies to them: BGC before access, signed confidentiality and acceptable use, security training within the same window, provisioning under approval, quarterly access review, termination de-provisioning under SLA. The HRIS often doesn't manage contractors, which is the root cause of most contractor-related findings — the JML pipeline depends on the HRIS as the source of truth, so contractors fall through the gap.

The eight findings that kill audits

1. Termination access removal >24 hours after last day — CC6.5 exception. Fix: HRIS → IdP webhook, no human in the loop.
2. Background check missing for a sampled employee — CC1.4 exception. Fix: pre-start BGC as a hard gate; integrate the BGC vendor to HRIS.
3. Training completion below 95% in the sample — CC2.2 exception. Fix: enforce via IdP suspension at deadline + 7 days.
4. Quarterly access review with no evidence of remediation — CC6.3 exception. Fix: the review must produce a ticket per revocation with an owner and a close date.
5. Provisioning before manager approval (access granted, ticket back-filled) — CC6.2 exception. Fix: IdP cannot grant without an approved ticket. Make the workflow refuse.
6. Contractor on production access with no BGC and no signed AUP — CC1.4 / CC6.2 exception. Fix: contractor pipeline above.
7. Code of conduct acknowledgement missing for sampled hires — CC1.1 exception. Fix: HRIS task on Day 1 with hard deadline; status visible to the manager.
8. Privileged access list contains a name that left the company — CC6.6 / CC7.2 exception. Fix: quarterly privileged review separate from the standard UAR; exception report runs daily.

A 90-day readiness plan

Tooling: what to buy, what to build

How SOC 2 overlaps with ISO 27001 and GDPR

If you're going to be audited against more than one framework, the HR controls overlap heavily. ISO 27001:2022 Annex A includes the 'People controls' (A.6) — screening (A.6.1), terms and conditions of employment (A.6.2), disciplinary process (A.6.4), responsibilities after termination (A.6.5), confidentiality agreements (A.6.6), and information security awareness, education, and training (A.6.3). Build the SOC 2 evidence pipeline correctly and you have ~80% of ISO 27001's people controls covered.

GDPR overlap is more nuanced. GDPR (and DPDP, CCPA, UK GDPR, LGPD) governs lawful basis, transparency, data subject rights, cross-border transfer, and processor relationships — none of which is SOC 2's concern unless you scope in the Privacy TSC. But the BGC, training, and HRIS data flows you build for SOC 2 are also processing activities under GDPR, which means each needs a lawful basis (Art. 6), a retention period, a record in your Article 30 register, and (for BGC criminal data in the EU) Article 10 safeguards. Build the data map once; serve both frameworks.

FAQ

References & further reading