SOC 2 background checks for employees and contractors

Does SOC 2 require background checks for SOC 2 employees and contractors?

The 2017 Trust Services Criteria do not name a specific background check, so a SOC 2 does not require one by name. What the criteria do expect is that the organization attracts, develops and retains competent people, and the CC1.4 points of focus ask it to consider the background and technical competency of individuals. Auditors test this through a sample of people hired during the examination period, so the practical question is whether your hiring records show that screening was considered, performed where your policy requires it, and documented before access was granted. Your organization owns the screening policy, the decision on which roles need which checks, and the records. The independent CPA firm tests those records and issues the report. DeployOpen can help prepare the screening procedure, the checklist and the evidence trail in your own systems, but it does not perform the screening decisions or issue any opinion.

The right answer depends on your own risk and role design. A engineer with production database access, a finance user with payment approvals and a contractor on a short project with read-only access do not carry the same risk, so they should not follow the same screening path. Start by listing the roles that handle customer data, privileged infrastructure or security tooling, then decide for each role which checks are proportionate and lawful where you operate. Cover contractors and staff from vendors the same way, and make your contracts with those vendors state which screening the supplier performs and what it must provide on request. Ask your auditor early which population and evidence they will sample, because a policy that says every hire is screened will be tested against actual hires, and a gap in one file is an exception in the report. Confirm local employment law and any customer requirements with your legal and HR leads before you set the policy.

Who the background check policy must cover

Employees are the population most organizations already screen, but SOC 2 asks for more than a hiring step. The 2017 Trust Services Criteria point of focus under CC1.4 asks the organization to consider the background and technical competency of the people it hires, so the policy should state what checks apply to which roles and who approves exceptions. Screening usually sits with HR and a background check provider, and the organization owns the decision to hire. Auditors typically sample new hires during the period and ask for the screening result or the record that the check was waived under an approved rule.

Role-based scope: Define which roles require checks (for example, production administrators, staff with access to customer data, and finance approvers) and which use a baseline check.
Timing: State whether checks must clear before the start date or before system access is granted.
Jurisdiction limits: Record which checks are lawful in each country where staff work, since some checks are restricted by local law.
Evidence kept: Retain the completed screening record or signed consent, the approver, and the date, without copying sensitive report contents into the HR file.
Exceptions: Require documented approval and compensating controls for any hire who starts before results return.

Illustrative example: a payments team lead starts on a Monday, and the policy requires a completed check before production access. The HR system shows the cleared date, and the access ticket references it.

Check that your policy names the roles in scope and that a sample of recent hires can be traced from start date to screening record.

How auditors test background checks in the examination period

The sequence below shows how an auditor moves from the written screening policy to sampled individuals and their screening records, producing a workpaper at each step so the result can be traced and re-performed.

Read the written screening policy
The auditor starts by reading the organization's written policy on pre-employment and contractor screening. They check whether it states which checks apply, when they run relative to start dates, who approves exceptions and who owns the process. The output is a workpaper summarizing the policy's requirements, which becomes the benchmark for every later test. If no written policy exists, the auditor records that gap as a finding before sampling begins.
Confirm which roles require which checks
Next, the auditor asks management to map roles to screening requirements, such as whether employees with production access, privileged data access or financial authority need more checks than other staff. They compare that map with the policy and with the system description. The output is a workpaper listing each role category and its required checks, along with any roles management has excluded and the reason given for each exclusion.
Extract the population of new hires and contractors
The auditor requests a complete list of people who joined during the observation period for a Type 2 report, or before the as-of date for a Type 1 report. The list should cover employees and contractors, and it should include vendor staff where the organization relies on them for in-scope systems. The auditor checks the list for completeness against HR records and the identity provider. The output is a population workpaper with its source and extraction date recorded.
Select a sample and request screening records
From the population, the auditor selects individuals to test, typically weighting toward roles with the strictest requirements. For each selected person, they request the screening record, such as the vendor report, the completion date, the scope of checks performed and the approver. The sample size and selection method are documented in the workpaper, along with the reasons for any judgmental choices.
Compare screening dates with start dates
For each sampled individual, the auditor compares the date the screening was completed with the date access to systems or data was granted. A check finished before access was provisioned is consistent with the policy. A check completed after access began, or never completed, is an exception that needs explanation. The output is a testing workpaper showing the start date, screening date, access grant date and the result for each sample item.
Review how exceptions were handled
Where a screening was late, incomplete or missing, the auditor asks how management identified the gap, what compensating action was taken and who approved any temporary access. They look for evidence of escalation and resolution, not only an explanation. The output is an exception workpaper that records the facts, management's response and whether the control operated as designed for that item.
Conclude and document the results
Finally, the auditor combines the sample results into a conclusion on whether the screening control operated effectively during the period. Exceptions are evaluated for their significance and reported to management, and the conclusion is reflected in the report. The organization should expect the auditor to ask for the same workpaper items it will need to reproduce its own testing before the examination starts.

Which background check evidence satisfies the auditor

A SOC 2 auditor does not accept a statement that background checks happen. The auditor looks for a written rule, a dated record for each sampled person, and proof that exceptions were handled. The cards below cover the records that connect those pieces, and the points where most organizations leave gaps.

Written policy and role criteria

The written policy states which roles require a background check, which checks apply to each role, who may approve an exception, and when screening happens relative to the start date. Role criteria should name the categories (for example, staff with production access or access to customer data) rather than leave the decision to each hiring manager. Check that the policy matches what HR actually does, because auditors compare the document with the sampled records. The organization owns this policy, and its management approves it.

Screening record per sampled person

For each new hire in the audit period, keep a record showing the check was completed before or at the start of access. The record should hold the check date, the provider or HR owner, and the result category, such as clear or referred. A vendor report reference or a signed HR attestation with a date both work if they are consistent. Confirm with your provider and counsel what the record may contain, since the full report often holds more personal data than the auditor needs.

Contract clauses for contractors and vendors

Contractors and staff supplied by vendors are often outside HR's process, so the screening duty has to appear in the contract. Clauses should require the supplier to run checks equivalent to yours on people who reach your systems or data, to tell you of adverse results where the law allows, and to let you audit compliance. The contract is evidence of the design of the control. Ask the auditor which clause wording they expect before signing, and keep the signed copies with the vendor records.

Exception and escalation records for adverse results

When a check returns an adverse result, the organization must show what it did. Keep a record of the finding category, the person who reviewed it, the decision (hire, decline, restrict access, or request more information), and the date. Where the organization decided to proceed, the rationale should be written down and approved by someone above the hiring manager. An empty exception log is not automatically a good sign, since auditors may ask how adverse results would have been recorded.

Re-screening and recertification rules

SOC 2 does not prescribe how often background checks must be repeated, so this card covers only what the organization chooses to set. If the policy requires re-screening for certain roles, for example after a change of role or at set intervals, the records must show it happened for the sampled people. A rule that exists only on paper will fail sampling. Decide the trigger events, the owner of each re-screen, and the retention period before the audit period starts.

Minimal personal data in screening records

Screening evidence contains sensitive personal information, so keep only what the auditor needs to test the control. Store the check date, the result category and the approver, and keep full reports with the provider or in a restricted HR system. Limit who can open these records, set a retention period, and remove them when the purpose ends. Confirm with your legal or privacy team which jurisdictions restrict these checks, because the rules differ between countries and the answer shapes what the record may hold.

What EU customers may also ask suppliers for

A SOC 2 report does not replace contractual asks that European customers may place on their suppliers. Under Implementing Regulation (EU) 2024/2690, which sets technical and methodological requirements for certain digital infrastructure and digital provider entities under NIS2, supplier contracts must, where appropriate, cover staff training and background checks alongside cybersecurity requirements, incident notification, audit rights and exit obligations. The same annex says customers' awareness programs and background checks may extend to direct suppliers and service providers where appropriate. For a SaaS vendor, that means a customer's contract may ask for background check commitments in writing, even if your SOC 2 already tests the control.

Whether these asks reach you depends on your customer's regulatory status, not on your own. A bank, cloud provider or managed service provider in scope of NIS2 may have to pass these expectations down, while a customer outside scope may still use its procurement questionnaire to ask the same thing. Before answering, check which customers are in scope, what their contract template says about personnel screening, and whether the wording is limited to "where appropriate." Confirm the scope and the wording of any clause with counsel, and ask the customer's compliance team to identify the regulation it relies on.

Prepare a short mapping between the customer's clause and your existing evidence: the background check policy, the check provider's confirmation for sampled hires and contractors, and the vendor's own commitments for subcontracted staff. Where a clause asks for something your SOC 2 does not test, such as checks on specific roles or re-screening intervals, decide whether to adopt it or negotiate it. The auditor will not issue an opinion on a customer's contract, so treat these asks as separate contractual commitments that your own counsel and compliance lead must approve.

Where background check programs break during an audit

Most background check failures in a SOC 2 examination are not about the screening itself. They come from gaps between what the policy promises and what the records show, and from populations of people with system access who fall outside the process. The cards below cover the gaps auditors most often raise and a practical fix for each.

Policy says screening happens, records do not

The policy states that every hire is screened before start, but the auditor finds no completed check for a sampled employee. Often the screening was run through a recruiter or a third-party portal and the result was never stored in the HR or compliance system. Check that each sampled hire has a dated, attributable result on file, and that the policy describes where that result lives. Where the policy and the practice diverge, fix the practice first, then reword the policy to match what the team can actually produce.

Contractors left out of the process

Full-time staff are screened, but contractors onboarded through agencies, freelance platforms or direct engagements are not. Their production access often matches or exceeds that of employees. Confirm which screening obligations are written into the contractor agreement or the agency contract, and keep a single register of every non-employee with system access so the auditor can sample them alongside employees.

Screening after the start date

A candidate receives credentials on day one while the background check is still pending, and no rule explains what happens if the result is adverse. Auditors look for a documented sequence: whether access is granted before or after clearance, and what happens when a check is still open at the end of the review window. Define a rule, such as no production access until clearance is recorded, and make the identity provisioning step check for that record.

Checks vary by role without a rule

Engineers with production access get a thorough check, while finance or support staff with access to customer data get a basic identity verification only. The variation may be sensible, but it is rarely written down. Create a table that links role or access tier to the screening scope, approved by management, and confirm that each sampled person's check matches the tier they were assigned.

Personal data kept longer than needed

Background check reports contain sensitive personal data, and many organizations keep them in email, shared drives or the recruiter's account indefinitely. Set a retention period for the report itself, separate from the fact that a check was passed, and restrict who can open the report. Confirm that the disposal step is recorded, since a retention rule without evidence of deletion will not satisfy an auditor who samples it.

Vendor staff with production access and no terms

A managed service provider or outsourced support team holds administrator access to production, yet the contract says nothing about how its staff are screened. This is a gap in vendor management as much as in hiring. Review each vendor with privileged access, confirm the contract requires equivalent screening and prompt notice of staff changes, and keep the vendor's attestation or written confirmation on file. Ask the vendor to show evidence rather than accept a general statement.

Who owns screening, who prepares evidence and who tests it

The organization owns its background screening controls and every decision made under them. Management decides which roles require screening, which checks apply to each role, what a flagged result means for hiring or access, and whether a screening provider is used at all. That ownership does not move when an outside party helps. If a screening vendor runs the checks, the organization still needs its own written criteria, its own approval step and its own record of who was cleared and when. The same applies to contractors and staff at vendors that touch the system: the organization decides what it requires of them and confirms it in contract terms or onboarding records.

An implementation partner such as DeployOpen can help set up the workflow that produces those records. In practice that means defining the sequence of steps from offer to clearance, connecting the HR system and the identity provider so that a cleared start date and account creation can be matched, and organizing the screening confirmations, approval tickets and contractor attestations into a folder the auditor can sample. Ask any partner to state in writing which parts of the workflow it configures and which decisions remain with your HR and security owners. The partner prepares systems and evidence. It does not decide who is hired, and it does not certify the result.

Only the independent CPA firm tests the controls and issues the SOC 2 report. The auditor selects samples of new hires and contractors from the examination period, asks for the screening evidence and the matching access approvals, and forms an opinion on whether the controls operated as described. Management's written representations support that work, but they do not replace testing. Because the preparing party and the testing party must stay separate, the consultant who designed the workflow should not be the person who signs off that it works. Before fieldwork begins, confirm with your CPA firm which screening records it will accept, how long it will sample back, and whether it expects evidence from a screening vendor directly.

Frequently asked questions about SOC 2 background checks

Is a background check mandatory under SOC 2?

No. SOC 2 does not name background checks as a fixed requirement. The 2017 Trust Services Criteria address them through the CC1.4 criterion on competence, which lists considering the background and technical competency of individuals as a point of focus. A point of focus is a characteristic that can help you design and evaluate a control, not a separate requirement, and not every point of focus has to be addressed. What the auditor tests is whether your own controls for hiring competent people are designed and operating as you describe them. If you decide that a screening step is how you meet that intent, it must be written down, applied consistently and evidenced. The 2017 Trust Services Criteria are the place to read the exact wording.

Do contractors and vendor staff need background checks for SOC 2?

The criteria do not prescribe one, but the CC1.1 points of focus ask you to consider contractors and vendor employees when setting standards of conduct. Most organizations therefore treat contractors with access to production systems or customer data the same as employees, or require their staffing vendor to screen people and confirm that in the vendor contract. Where you rely on a staffing firm, the evidence is the contract clause, the vendor's screening attestation and your own record that each contractor was covered before access was granted. Check with your auditor how they want contractor screening documented, because the answer depends on the access those people hold.

What happens if a background check is missing for one sampled hire?

A single missing record is a finding the auditor will ask about, and how it is handled depends on the report type. In a Type 1 report, the auditor evaluates whether the control was designed suitably at a point in time. In a Type 2 report, the auditor samples hires across the observation period and tests each sample against the control. An exception does not automatically mean a qualified opinion, but it must be described, its cause explained and any remediation evidenced. The best defense is a joiner checklist that makes screening a gate before system access, with the completed record stored alongside the offer and start dates. Ask your auditor how they handle exceptions in sampling before the period begins.

Can we rely on a vendor's attestation for background checks?

You can rely on a vendor's attestation only as far as you have evaluated it. If a staffing firm, screening provider or subservice organization performs checks for you, review its own SOC 2 report or equivalent assurance, confirm the scope covers the screening process, and read the exceptions and complementary user entity controls it lists. Those complementary controls often describe what you must do yourself, such as verifying that the vendor's list of screened people matches your access list. Record that review as vendor management evidence. Your auditor will decide how much reliance is appropriate, so confirm your approach with them before relying on a third party's statement.

How much effort does setting up background checks take, and what drives it?

The effort is driven more by process design than by any single screening product. Costs fall into three groups: the screening fees charged per check by a provider, the internal time to define which roles need which checks, and the recurring time to verify each new hire and contractor against the policy. Effort rises with the number of countries you hire in, because local rules on criminal record checks and data protection differ, the number of roles with privileged access, and the volume of contractors. Ask any provider for a written quote that lists per-check fees, country coverage, turnaround and what is included in each package. Figures vary by provider and jurisdiction, so confirm them directly rather than relying on general estimates.

Do we need a consultant to set up background check controls?

No. An organization can design and run these controls without a consultant, and the auditor will test whatever you actually do. A consultant or implementation partner can help you write the screening policy, define role tiers, connect your identity provider and HR records so joiner evidence is generated automatically, and assemble the evidence set. DeployOpen plans and implements this kind of readiness work in your own environment under a fixed scope, but it does not issue reports or attest to controls. Only an independent CPA firm can perform the examination. Whatever route you take, agree the scope and evidence list with your auditor first, as they set the bar for what counts as sufficient.

How DeployOpen prepares screening evidence before the audit

DeployOpen works on the systems and records that show background screening happened for employees and contractors before access was granted. We prepare the onboarding workflow, the records it produces and the evidence an independent CPA firm will sample, while the organization keeps ownership of its screening policy and its screening decisions.

How we scope

We agree a written scope listing which worker types, identity systems and onboarding tools the screening evidence covers.
We confirm with the organization which screening is performed by HR or a third-party provider and where those records live.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure the onboarding workflow so access is linked to a recorded screening status before accounts are created.
We set up records that tie each new hire or contractor to a screening date, approver and outcome in the same system.
We test that the workflow blocks provisioning when a screening step is missing, and document the test results.

How we hand over

We deliver the control description, the evidence map and a sample pack showing screening records for workers who joined during the period.
We document who owns each step, how exceptions are escalated and how the records are retained.
We hand over the material to the organization and to its CPA firm, which alone decides what evidence is sufficient.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the handover.
We can review new contractor and vendor onboarding paths as the organization adds teams or suppliers.
We help the organization confirm screening requirements with its auditor and with any customer that asks suppliers for them.