SOC 222 April 2026 6 min read

SOC 2 Background Checks: CC1.4 Requirements Explained

SOC 2 CC1.4 requires background checks as part of your hiring process. Learn what checks satisfy the requirement, how to document them, and common audit findings.

Key Takeaways

CC1.4 requires that personnel with access to customer data undergo background screening as part of the hiring process.
The specific checks required (criminal, employment, education) are not mandated by SOC 2 — you define the standard in your HR policy and must then consistently apply it.
Auditors test background checks by sampling a set of hires during the observation period and verifying that each received the screening defined in your policy.
Contractors and third-party staff with privileged access to in-scope systems should be covered by your background check policy or your vendor's equivalent.
Gaps most commonly occur when background check completion is not documented in your HRIS or when contractors are excluded from the policy scope.

In this guide

CC1.4 Explained
What Checks Are Required
HR Policy Requirements
Documentation and Evidence
Contractors and Third Parties
Common Audit Findings

CC1.4 Explained

CC1.4 is the SOC 2 criterion that addresses human resources security during hiring. The full criterion reads: "The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives. The entity considers the competence and integrity of its workforce." In practice, auditors interpret this to require pre-employment background checks for staff with access to systems and data in scope.

CC1.4 sits within the Control Environment component (CC1) of the COSO Internal Control framework that underlies the SOC 2 Trust Service Criteria. The control environment sets the tone for how the organization values integrity — background checks are evidence that you vet the people who access customer data before granting them that access.

The criterion does not specify what type of background checks you must run. Instead, it requires that you have a defined policy and apply it consistently. An auditor finding no policy at all, or a policy that was not applied to 30% of hires sampled, will generate a finding regardless of what type of checks you run.

What Checks Are Required

SOC 2 does not mandate specific background check components. Common components used by SaaS companies include: criminal background check (typically 7-year lookback, all counties where the candidate lived and worked), employment history verification (confirming prior employers and dates of employment), education verification (confirming degrees claimed on the resume), and identity verification (confirming the candidate is who they claim to be).

The check types you include should be proportional to the access level of the role. Engineering roles with production database access typically receive the full suite of checks. Administrative roles with limited system access may be subject to a reduced package. Define the requirements by role tier in your policy — this allows auditors to evaluate whether checks were applied consistently within each tier.

Credit checks are used for finance-related roles in many organizations but are not commonly required for engineering or operations staff unless the role involves financial system access. Drug screening, where legally permitted and relevant to the role, may be included but is not a SOC 2 requirement.

HR Policy Requirements

Your HR or information security policy must document: (1) that background checks are required prior to employment for roles with access to in-scope systems; (2) the types of checks conducted by role tier; (3) the timing requirement (typically "before first day of access to production systems"); (4) the process for handling adverse results; and (5) the exceptions process if a check cannot be completed before start date.

The policy must also address what happens when a background check returns adverse results. Define the evaluation process: who reviews adverse results, what criteria are used, and who makes the final determination. This does not mean you must deny employment for all adverse results — it means the decision must be documented and consistent.

Background check policy is typically part of your broader HR or People Operations policy document. It does not need to be a standalone policy, but it must be a clearly identifiable section that auditors can review. Reference the policy in your information security policy under workforce security controls.

Documentation and Evidence

The primary evidence auditors collect for CC1.4 is a list of all hires during the observation period cross-referenced against background check completion records. If you hired 15 people in the past 12 months, the auditor will typically sample 5–8 of them and request evidence that each received the background check defined in your policy.

Background check completion evidence typically takes the form of a report from your background check vendor (Checkr, Sterling, HireRight) showing the check was completed and the date. If your HRIS (BambooHR, Rippling, Workday) integrates with your background check vendor, completion status may be available directly in the HRIS record — this is the most auditor-friendly setup.

A common documentation gap: companies that use a background check vendor but do not retain the completion records. Vendors typically retain reports for a limited period. Ensure your HR process includes downloading or archiving the completion report to a permanent location (HRIS record, document management system, or similar) before the vendor report expires.

Contractors and Third Parties

Your background check policy should address contractors and third-party staff who have direct access to in-scope systems. Auditors frequently find gaps here: a company's full-time employees are all checked, but a contractor with production database access started two years ago with no background check on file.

For contractors engaged through staffing agencies, the standard approach is to require that the agency conduct a background check equivalent to your internal policy and provide written confirmation. This confirmation letter should be retained in your vendor files alongside the engagement agreement.

For software development contractors who access your GitHub repositories or cloud environments directly, the same principle applies. Their background check (conducted by their employer or agency) must be documented. If a contractor is an independent individual rather than a corporate entity, your company must conduct the background check directly before granting production access.

Common Audit Findings

The most common CC1.4 finding is missing background check documentation for one or more sampled hires. This typically occurs when: background checks were conducted verbally or informally without a report; the vendor report was not archived before expiration; or an offshore or contract hire was excluded from the process without a documented exception.

A second common finding is timing gaps — background checks that were completed after the employee was given production access. If your policy says "before first day of access" but your records show checks completed two weeks into employment, the auditor will note the gap. Review your onboarding checklist to ensure production access provisioning is gated on background check completion confirmation.

A third finding is policy inconsistency — applying different check types to similar roles without a documented rationale. If your policy says all engineers receive a criminal check and employment verification, and your sample shows two engineers who only received a criminal check, auditors will flag the discrepancy.

Frequently Asked Questions

Does CC1.4 require international background checks for non-US employees?

SOC 2 does not specify geography for background checks. Your policy should define what checks are conducted for employees in each location. International criminal checks may be limited in scope or not available in some countries. The key is to document what checks are conducted per location and apply them consistently. Where criminal checks are not available, alternative verification (employment and education verification, professional references) may be documented as a compensating measure.

We hired someone before we started our SOC 2 program. Do older employees need retroactive checks?

Background checks for employees hired before your policy was implemented are not required retroactively by SOC 2. Auditors test whether your policy was applied to hires during the observation period — employees hired years before the audit period are outside scope. Establishing a clear policy effective date and applying it to all subsequent hires satisfies CC1.4.

What if a candidate is in a location where certain background checks are restricted by law?

Document the legal restriction in your policy as an exception condition. For example: "Criminal background checks are not conducted for employees in [jurisdiction] due to local legal restrictions. In these cases, employment and education verification are conducted in lieu." The key is a written policy decision, not a blank entry in your audit trail.

Does CC1.4 cover security awareness training as well?

CC1.4 addresses the commitment to competent and integrity-aligned personnel, which encompasses both pre-hire screening and ongoing training. However, security awareness training is also addressed under CC2.2 (internal communications of information security responsibilities) and is a separate audit test. Background checks and training are often tested together as part of the HR controls cluster.

Our background check vendor is Checkr — is that sufficient for SOC 2?

Any FCRA-compliant background check vendor (Checkr, Sterling, HireRight, Accurate Background, etc.) is appropriate for SOC 2. The auditor cares that checks were conducted using a recognized process, not which vendor you used. Ensure your vendor retains reports long enough for audit retrieval, or archive reports to your HRIS. Checkr integrates with most major HRIS platforms, making completion status retrieval straightforward.