SOC 2 HR Security Controls Without Automated Provisioning

TL;DR

• HR security maps to four Trust Services Criteria: CC1.4 (competence), CC1.5 (accountability), CC2.2 (internal communication), and CC6.2 (user provisioning)
• Manual onboarding and offboarding workflows satisfy SOC 2 when documented, named, and consistently followed; the absence of Workday, Okta, or SCIM automation is not a finding
• A ticket-and-checklist program with named owners, periodic access reviews, and signed acceptance of policies produces the evidence the auditor samples
• Background checks, security awareness training (KnowBe4, Hoxhunt, internal), and acceptable use acknowledgments belong in the program even when no HRIS automation is in place
• Same-day deprovisioning, asset recovery, and access revocation on departure are the controls auditors push hardest on for small teams

HR posts a Slack message announcing the new hire. IT creates an Active Directory account, an email mailbox, and the JIRA license. The new hire signs the acceptable use policy in DocuSign and gets a wiki page with their first-week reading list. The whole onboarding workflow is five steps run by three people across two days, and there is no Workday integration, no Okta SCIM connector, and no deprovisioning webhook anywhere in the chain.

That is the onboarding process at typical on-prem and hybrid SaaS shops, and SOC 2 says it can be enough. The Trust Services Criteria that govern HR security describe outcomes, not tool chains. A ticket-and-checklist program a small team actually follows will satisfy CC1.4, CC1.5, CC2.2, and CC6.2 every day of the week. What most guidance skips is what that program looks like when the automation chain is not there. This post covers the deliberate, manual version that auditors accept and small ops teams can sustain.

How HR Security Maps to Four Trust Services Criteria

HR security is one of the more spread-out SOC 2 topics. Four criteria intersect, and treating it as a single control is how teams end up with evidence gaps.

CC1.4 is the competence criterion. The entity commits to attracting, developing, and retaining competent people. Hiring standards, background checks, role definitions, technical competency assessment, and ongoing training all live here.

CC1.5 is the accountability criterion. The entity holds individuals accountable for their control responsibilities. Role clarity, named owners, performance expectations that reference control work, and the enforcement path when something slips all map to this one.

CC2.2 is the internal communication criterion. The entity communicates information internally, including objectives, responsibilities, and mechanisms to report incidents and concerns. Security awareness training, acceptable use policy acknowledgment, and incident reporting channels all sit here.

CC6.2 is the user access registration criterion. Before credentials are issued, users are registered and authorized. When access is no longer authorized, credentials are removed. This is where CC6.2 and the HR lifecycle meet in onboarding, role change, and termination.

What Auditors Actually Sample

Experienced SOC 2 auditors ask for a predictable set of artifacts during the HR walkthrough. Knowing what they will sample shapes how the program needs to run.

• A list of all hires and terminations during the observation period with start and end dates
• A sample of onboarding records showing the background check outcome, signed acceptable use and code of conduct acknowledgments, and the onboarding checklist with timestamps tied to the access provisioning tickets
• A sample of terminations showing the offboarding checklist, access removal evidence with timestamps across every in-scope system, return-of-asset confirmation, and the HR notification that triggered the workflow
• Security awareness training records for the full headcount with completion dates and the content delivered
• The acceptable use policy and code of conduct with annual re-acknowledgment records
• Role definitions and job descriptions that the access model maps to, with enough detail that the auditor can see what competence looks like for each role
• Evidence of internal communication channels for reporting security incidents and ethics concerns. A wiki page or a Slack channel is fine. Something has to exist and be known
• Quarterly or annual access reviews reconciled against an HR-sourced list of active employees

Everything that follows works backward from that sample list. If a control does not produce one of those artifacts continuously, it is not really running.

The Program That Works Without Automated Provisioning

The honest observation across teams that pass cleanly without a Workday and Okta chain is that the program is simple, written down, and genuinely followed. Three components carry most of the weight.

Onboarding as a ticket, not a process document

The failure mode of manual provisioning is not that it happens manually. It is that it happens inconsistently. One new hire gets the full laptop build, AUP acknowledgment, and training assignment on day one. The next gets a partial setup because the person who usually handles it was out. The auditor samples both and finds a gap.

The fix is the same fix that works for ticket-driven change management: put the process inside the ticketing system and make the ticket the evidence. An onboarding ticket template in JIRA, ServiceNow, or Linear, created automatically when HR signals a new hire, with a checklist of required subtasks: background check complete, signed offer, AUP acknowledged, code of conduct acknowledged, role defined and communicated, access tickets created per the role-based access model, equipment issued, training enrolled. Each item carries a named owner and a closing timestamp.

The auditor does not need to understand the business. They need to see the same fingerprint on every onboarding ticket in the sample. The ticket is the evidence for CC1.4 (background check, technical competency, training enrollment), CC2.2 (AUP and responsibilities communicated and acknowledged), and CC6.2 (access credentials created based on authorization).

Offboarding with a same-day deprovisioning commitment

Offboarding is the control auditors push hardest on and the one manual shops break most often. The risk model is obvious: the former employee has the means and often the motive, and every hour of delay is unmanaged exposure. SOC 2 does not require automation. It requires speed, completeness, and evidence.

A defensible offboarding control in a manual environment looks like this:

• A named trigger. HR notifies IT through a single documented channel the moment a termination is decided. For involuntary terminations the notification happens before the conversation with the employee, not after
• A same-day deprovisioning SLA for security-relevant departures and a 24-hour SLA for voluntary departures, mirroring the cadence used in the on-prem access control program. The SLA is documented in policy and measured against the actual timestamps on the offboarding ticket
• A per-system checklist covering every in-scope system the employee had access to. AD, VPN, bastion, production servers, databases, security tools, version control, SaaS apps. Each line is a separate closing timestamp
• A return-of-asset record for laptops, tokens, badges, and any other issued equipment
• A final access verification by a second person against the master employee list, so the offboarding ticket cannot close until somebody other than the original deprovisioner has confirmed

Training and policy acknowledgment as a cadence, not an event

Security awareness training is simple to deliver badly. A SOC 2-grade curriculum goes out through a legitimate training vendor, people click through, and completion lands in a spreadsheet the compliance owner updates monthly. That works. What does not work is the follow-through: the people who missed the deadline, the new hires whose enrollment happened a month after their start date, the annual re-acknowledgment of the AUP that nobody reminded staff about.

Programs that run cleanly treat training and policy acknowledgment as a recurring ticket cadence, not a one-time event. New hire training is a line on the onboarding ticket with a hard close-by date. Annual refresher training is a recurring ticket opened on the employee's hire anniversary or during a fixed annual window. The compliance owner's job is to monitor exceptions, chase the stragglers, and document the escalation path when somebody is over the deadline. That escalation is part of the CC1.5 and CC2.2 evidence, because it is the moment where control ownership is visibly enforced.

Evidence Pitfalls Unique to the Manual Model

A few failure modes show up repeatedly when the provisioning chain is manual, and the fixes are usually small.

Bringing It Together: The STEPP Lens

How CC1.4, CC1.5, CC2.2, and CC6.2 Points of Focus Show Up in HR Security

The AICPA Points of Focus underneath these four criteria describe the characteristics auditors evaluate. Every one of them has a place in the manual program described above.

CC1.4, Competence

Hiring policies that reflect the competence expected for each role. Evaluation that surfaces when competence is falling short, across employees, contractors, and outsourced service providers. A documented approach to attracting, developing, and retaining people through mentoring and training. Contingency planning for roles important to internal control. A background check process that considers the background of personnel, contractors, and vendor employees. Technical competency assessment during hiring. Ongoing training to maintain technical competencies.

In the manual program, this shows up as documented role definitions, a background check record per hire, training enrollment on the onboarding ticket, and an annual refresher cadence covering the whole headcount.

CC1.5, Accountability

Structural mechanisms that hold individuals accountable for their control responsibilities, including corrective action. Performance measures and incentives that reflect standards of conduct. Ongoing evaluation of whether those incentives still align with control responsibilities. Consideration of whether pressures might push people to bypass controls. Evaluation of performance and the use of rewards or discipline where appropriate.

In the manual program, this shows up as named owners on every onboarding and offboarding ticket, a documented escalation path when deadlines slip, an executive sponsor for the HR security function, and performance expectations that reference the control responsibilities staff actually hold.

CC2.2, Internal Communication

A process to communicate the information personnel need to carry out their control responsibilities. Communication with the board. Separate communication lines, such as whistle-blower channels, that act as fail-safe mechanisms when normal channels are unavailable. A deliberate choice of communication method that fits the audience and the timing. Communication to personnel about changes in their responsibilities. A way for personnel to report failures, incidents, concerns, and other matters. Communication of objectives and changes to objectives. A security awareness training program.

In the manual program, this shows up as AUP acknowledgment tied to onboarding and annual refresh, a documented incident reporting path every employee can name, role change notifications flowing through the same ticketing system, and training covering the full headcount on a defined cadence.

CC6.2, User Access Registration and Deprovisioning

Creation of access credentials based on authorization from the asset's owner or custodian. Periodic review of credential validity across employees, contractors, vendors, and business partners. Processes to disable, destroy, or otherwise prevent the use of credentials when no longer valid.

In the manual program, this shows up as onboarding tickets that tie every credential creation back to a named approver and the role matrix, quarterly access reviews reconciled against an HR-sourced employee list, and offboarding tickets with same-day or 24-hour deprovisioning SLAs plus a second-person verification step before close.

Explore further in Framework Explorer: CC1.4 · CC1.5 · CC2.2 · CC6.2, see the full requirement, implementation guidance, evidence types, and cross-framework mappings.

Source: AICPA TSP Section 100, 2017 Trust Services Criteria with Revised Points of Focus (2022). Point of Focus characteristics described in Truvo's words and mapped to a manual HR security implementation pattern. Consult the source document for the official AICPA text.

Where This Fits in an Effective Security Program

Teams that stay continuously compliant with HR security do not treat the HR controls as a separate workstream. They wire them into the same ticketing and cadence system the rest of the security program runs on. The onboarding ticket that creates access is the same ticket that records AUP acknowledgment. The offboarding ticket that closes access is the same ticket that drives the return-of-asset record. The access review that CC6.2 expects is the same access review the on-prem access control program describes, reconciled against an HR-sourced employee list.

Build the program once and frameworks map onto it without restart. CC1.4, CC1.5, CC2.2, and CC6.2 are lenses that test whether the HR security controls are running as described. ISO 27001 Annex A controls on screening, terms of employment, awareness, disciplinary process, and termination map onto the same workflow. The program is the source of truth. Extend, don't restart.

Further Reading

• SOC 2 Readiness for Bare Metal SaaS: cluster overview and what an on-prem engagement actually looks like
• SOC 2 Change Management with Tickets Instead of CI/CD: the ticket-driven workflow pattern this post inherits
• SOC 2 Access Control for On-Prem: the role-based access model and quarterly review cadence
• How to Choose a SOC 2 Consultant: what to look for if you need outside help structuring the program

Frequently Asked Questions

Does SOC 2 require a Workday and Okta SCIM provisioning chain?

No. CC1.4, CC1.5, CC2.2, and CC6.2 describe outcomes: competence, accountability, internal communication, and access registration and deprovisioning. They do not prescribe a specific HRIS, identity provider, or integration pattern. A manual program that runs through a ticketing system, an HR-sourced employee list, and a documented training and policy cadence satisfies the criteria when it produces continuous evidence.

What HR security evidence do auditors actually sample?

A list of hires and terminations during the observation period, a sample of onboarding records with background checks and signed acknowledgments, a sample of termination records with per-system deprovisioning timestamps, security awareness training completion for the full headcount, the AUP and code of conduct with annual re-acknowledgment, role definitions, evidence of internal communication channels for reporting concerns, and quarterly or annual access reviews reconciled against HR records.

How fast does access need to be removed when someone leaves?

SOC 2 does not name a specific number. What auditors look for is a documented SLA that matches the risk and is measured against actual offboarding timestamps. A common pattern is same-day deprovisioning for security-relevant departures and 24 hours for voluntary departures. The SLA needs to be in policy, enforced through the offboarding ticket, and verified by a second person before the ticket closes.

How do small teams handle segregation of duties in HR security?

The verification step is the main compensating control. The person who runs offboarding is not the same person who confirms that access has been removed across every system. For teams too small to separate onboarding owner from offboarding owner from verifier, a rotating verifier role across operations, engineering, and HR is enough. The evidence lives on the ticket, not in an org chart.

What if security awareness training is tracked in a spreadsheet?

That is fine. Spreadsheet tracking is compatible with SOC 2 as long as the training is legitimate, completion is reconciled against an HR-sourced headcount on a defined cadence, the exceptions are chased, and the spreadsheet is retained through the observation period. The failure mode is not the spreadsheet. It is the drift that happens when nobody owns the reconciliation.

Does SOC 2 require annual re-acknowledgment of the acceptable use policy?

The criteria do not name an exact cadence, but CC2.2 expects ongoing communication of responsibilities, and annual re-acknowledgment is the standard pattern auditors see. A signature on day one with no refresh leaves a visible gap after the first year. Annual re-acknowledgment through a simple form or signature flow keeps the control alive and produces the evidence the auditor samples.