.svg){kind=logo}
Most founders search for SOC 2 background check requirements, expecting a set of rules that tell them: run a criminal check, use this vendor, complete it within this window.
But the SOC 2 framework does not specify that every employee must pass a background check before getting certified. But auditors still expect proof that you screen people before they touch your systems or your customer data.
That gap between finding no explicit rule and still being expected is where most teams get caught.
Here is the honest answer. SOC 2 is a principle-based framework. The American Institute of Certified Public Accountants sets the criteria. Each company then designs controls that fit its own risk.
Background checks are one common way to meet personnel-risk controls. They are not the only way, and they are not explicitly named in the criteria.
Auditors are not asking "Did you run background checks?" They want to know if your hiring and access process reduces the risk that the wrong person gets access to sensitive systems or customer data. That question has many possible answers.
This guide will walk you through what auditors actually look for, who needs to be screened, what evidence to keep, and how to handle the hard cases.
By the end, you will know how to walk into your audit with a real, documented answer.
If you want to see what a documented, audit-ready process looks like before reading further, our demo walks through a real example in under five minutes.
Does SOC 2 require background checks?
SOC 2 background check requirements are not spelled out in a checklist. The SOC 2 framework is built on the idea that every company is different. What matters is that your controls match your risk, not that you copied someone else's policy.
That said, background screening is one of the most common ways companies satisfy personnel-risk controls inside the Trust Services Criteria. Auditors see it regularly. When a company does not have it, they ask what they have instead.
Why is the answer not a simple yes or no?
SOC 2 is principle-based. The AICPA defines what outcomes your controls must achieve. Your company decides how to achieve them. This gives you flexibility, but it also means there is no single rule to point to.
A startup with five engineers has a different risk than a company with two hundred support staff who handle customer records. SOC 2 compliance background check expectations are shaped by your size, your access model, and the data you handle.
The result is that "Do we need background checks?" depends on your context. Most auditors will expect something. What that something looks like is up to you to define and document.
SOC 2 Background Check: Yes or No?
Now, let’s find out exactly which criteria connect background screening to your SOC 2 program.
Which SOC 2 criteria relate to background checks?
The SOC 2 framework is built on the Security Trust Services Criteria. These criteria describe the outcomes your security controls must produce. Two of them are most often connected to hiring and background screening: CC1.1 and CC1.4.
Neither criterion uses the words "background check." But both deal with whether your company brings the right people into roles that touch systems, data, or internal tools. That is where background screening fits in practice.
How does CC1.1 connect to background checks?
CC1.1 deals with your commitment to integrity and ethical values. It asks whether your company operates in a way that reflects those values across all functions. Hiring is part of that picture.
Auditors look at CC1.1 and ask whether this company makes deliberate choices about who gets access to its systems. A background screening process is evidence that you do. It shows you thought about the risk before giving someone access.
Without any screening process, an auditor may question whether your control environment is built on deliberate trust or just an assumption.
How does CC1.4 connect to background checks?
CC1.4 is the criterion most directly tied to background checks. It asks whether your company attracts, develops, and keeps competent and trustworthy people. Evaluating individual backgrounds is part of meeting that standard.
This criterion covers hiring practices, performance evaluation, and workforce development. Background screening sits at the front of that process. It is how you evaluate someone before they join your team and gain access to your systems.
If you can show a consistent process for screening people in high-risk roles, you are directly addressing CC1.4. That is the practical link between SOC 2 background check requirements and the AICPA criteria.
Also read: SOC 2 Controls List: The Complete Founder’s Guide (2025)
SOC 2 Background Check Requirements: What They Are and What They Are Not
SOC 2 background check requirements live in a space that most compliance guides refuse to name directly. They are not a checklist item. They are not a vendor certification. They are a personnel-risk control that your auditor will measure against your own documented commitments.
Here is what that means in practice. When you go through a SOC 2 audit, your auditor is not working from a master list of required checks. They are working from your policy. They will take your written commitments, pull a sample of your hires, and ask whether reality matched the paper. That is the actual test.
The core requirements that matter
SOC 2 background check requirements, when broken down to what auditors actually verify, come down to five things.
- A documented policy that defines who is screened and how
- A defined scope that tells you exactly which roles and access levels trigger screening
- Evidence that checks were completed for every person in scope during the audit period
- Proof that timing was appropriate, meaning screening happened before or close to the point of access.
- An exception log that captures every case where the standard process was not followed.
None of those five things requires a specific vendor. None of them requires a specific check type. What they require is consistency. A process you defined, documented, and followed the same way for every hire in scope.
Where teams misread the requirement
As highlighted before, most teams read "SOC 2 background check requirements" and go looking for a rule. That rule does not exist in the AICPA criteria.
What exists instead is a principle. The principle is that your company must demonstrate it evaluates people before giving them access to systems, data, or environments that carry real risk.
Background screening is the most common way companies demonstrate that. It is not the only way, but it is the one auditors have seen often enough to know what good evidence looks like.
If you skip screening entirely and have nothing else to show, you have a gap that will surface during sampling. If you screen inconsistently and cannot produce evidence for every sampled hire, you have the same gap. The requirement is not the check itself. It is the proof that your process worked.
What the requirements look like across hire types
SOC 2 requirements apply differently depending on who you are hiring and what they can access. A full-time engineer with production access sits in a different risk tier than a part-time contractor with read-only dashboard access. Your requirements should reflect that difference.
For full-time employees in high-access roles, auditors expect a complete screening process with documented results and timing that aligns with access provisioning.
For contractors, they expect either direct screening or a written attestation from the agency confirming screening has happened. For third-party vendors with system access, they expect contractual commitments and evidence of vendor-level security review.
The requirement scales with the risk. That is the operating logic behind every SOC 2 background check requirement your auditor will test.
The next section explains what auditors actually do when they review your background check controls.
What auditors really check during a SOC 2 background check review?
Most teams prepare by asking, "Do we have background checks?" Auditors prepare by asking, "Can we sample your hires and verify the process worked?" Those are two very different questions.
SOC 2 audit requirements around background screening are about process consistency.
Auditors want to see that you ran the same check for every hire in scope, in a similar way, with evidence to prove it. One-off checks or missing records are where teams lose points fast.
What background check evidence do auditors ask for?
Auditors will pull a sample of employees and contractors hired during your audit period. For each person in the sample, they will look for specific evidence. They will ask for the background check record, the date it was completed, and the vendor name.
They will also check whether access was granted before or after the screening was done. If someone got system access two weeks before their background check came back, that timing gap becomes an audit finding.
Beyond the check itself, auditors want to see a written policy, candidate consent records, and an exception log for anyone who fell outside the standard process. All of that together proves the control is real and repeatable.
The difference between design and operating effectiveness
SOC 2 Type 1 tests whether your controls exist and are designed correctly at a single point in time.
SOC 2 Type 2 requirements go further. They test whether the control actually worked over the audit period, usually six to twelve months.
For background checks, design effectiveness means you have a policy, a vendor, and a defined process. Operating effectiveness means the process ran correctly for each hire in scope during the full audit window.
This distinction matters because many teams pass Type 1 and then struggle with Type 2. They write the policy but fail to apply it consistently over time.
Evidence gaps in Type 2 are harder to explain and harder to fix after the fact.
Read for further clarity: SOC 2 Type 1 vs Type 2: What’s the difference?
Now that you know what auditors check, the next question is who actually needs to go through screening.
Who needs a SOC 2 background check: employees, contractors, or vendors?
The SOC 2 background check requirements for employees are not defined by job title. They are defined by access. If someone can reach your production systems, your customer data, or your internal tools, they are usually in scope.
This covers more people than most founders expect. It is not just engineers. It is support staff, finance teams, HR teams, and sometimes contractors from agencies.
The question is not "are they a full-time employee?" It is "can they cause harm if something goes wrong?"
Do employees need background checks for SOC 2?
Full-time employees who access sensitive systems are almost always in scope. This includes engineers, DevOps teams, support staff, and finance or HR staff. Founders are often in scope too, since they typically have broad access to everything in the organisation.
The role matters less than the access. A customer support rep who can view customer records is just as much in scope as a backend engineer with database credentials. The access level drives the screening requirement.
Background screening for in-scope employees is one of the clearest ways to satisfy your SOC 2 compliance background check obligations. The key is consistency. Run the same process for every person in the same risk category, without exceptions that are not documented.
Do contractors need background checks for SOC 2?
Contractors with system access are treated like employees for SOC 2 purposes. Their employment classification does not reduce the risk they carry. A contractor with access to your production environment carries the same risk as an employee in the same role.
If contractors come through an agency, you have two options. You can run the screening yourself. Or you can request a written attestation from the agency confirming that they screen their own workers. Either approach works, but you need documentation to show the auditor.
The risk follows the access. If a contractor can see customer data or touch production code, they belong in your screening scope regardless of how they are contracted.
Do third-party vendors need background checks for SOC 2?
Vendors with no system access are usually not in scope. They do not create direct personnel risk because they cannot reach your data or your systems through their work with you.
But vendors who do have access, like outsourced IT providers, development agencies, or third-party support teams, are a different story. For these vendors, you should either include them in your screening process or require vendor-level attestation and contractual security commitments.
Third-party risk management is a broader topic, but for background checks, the rule is simple: access determines scope.
The next section covers a question that catches many teams off guard, which is what to do about people who were already employed before your SOC 2 program started.
Do existing employees need retroactive background checks for SOC 2?
Most auditors focus on hires after your control went live. They are testing whether your process worked during the audit period. Employees hired years before your program started are usually not the primary focus of background check sampling.
But "usually not the focus" is not the same as "never an issue." If your policy says all employees must be screened, and some long-tenured employees have no record on file, that is a gap. Gaps need documentation, not silence.
What if employees were hired before the SOC 2 program started?
The cleanest approach is to document a control start date. Your policy should state clearly when the background check requirement began. Employees hired before that date are excluded by design, not by oversight.
If you want to screen existing employees retroactively, you can in some cases. But local laws may limit what you can run. In many places, retrospective screening of current employees is subject to consent requirements and legal constraints. Always involve legal counsel before running retroactive checks on existing staff.
If records are missing for older employees who are now in high-risk roles, document the situation in an exception log. Note the reason, the risk assessment, and any compensating controls you put in place. That is a far better audit position than leaving it undocumented.
What if an existing employee moves into a high-risk role?
Role changes are a real gap for many SOC 2 programs. An employee may have been hired for a low-access role, screened at a lower level, and then promoted into a role with admin or production access years later.
If your policy does not account for role changes, you may end up with engineers or admins who have never been screened for high-risk access. That gap can surface during auditor sampling when they notice a mismatch between access level and screening depth.
Consider building a role-based trigger into your policy. When someone moves into a role with privileged access, a new or enhanced background check should be initiated or documented as an approved exception with a clear rationale.
Understanding what type of check to run is the next practical step.
What type of background check is needed for SOC 2?
SOC 2 background check requirements do not specify a particular type of check. No rule mandates a criminal record search, an employment verification, or a credit check. The type of check you run should match the risk of the role and the data it can reach.
A risk-based approach to background screening is the most defensible position with auditors. It shows you thought about what threats each role carries and designed your screening to address those specific threats, rather than applying the same check to everyone.
Is a criminal background check enough for SOC 2?
For many roles, a criminal background check combined with identity verification is a reasonable baseline. It confirms who the person is and flags obvious risks. For support staff, sales teams, or roles with limited system access, this level of screening may be sufficient.
For higher-risk roles, a criminal check alone may not be enough. Engineers with database access, finance staff with payment system access, and admins with cloud infrastructure access all carry higher risk profiles. Deeper screening is appropriate for those roles.
The question is not whether the check is "enough" in the abstract. It is whether the check is proportionate to the specific risk that role carries and the data it can access.
When should employment verification or education verification be added?
Employment verification confirms that someone's work history is accurate. This matters for technical roles where claimed experience drives access decisions. If someone says they were a senior engineer at a major company and that claim is false, your access decision was based on bad information.
Education verification matters for roles where credentials are part of the trust equation. Healthcare, legal, financial, and senior technical roles often fall into this category.
Adding these checks to high-risk roles strengthens your SOC 2 audit requirements posture. It shows your screening depth matches your access risk, which is exactly the argument auditors want to see.
Should SOC 2 teams use role-based background screening?
Yes. A tiered screening model is the most practical and defensible approach. You define risk categories by role type, and the screening depth matches the category. Lower-risk roles get lighter checks. Higher-risk roles get more complete ones.
This approach also makes your policy easier to follow consistently. Everyone knows which tier their role falls into and what screening that tier requires. It reduces gaps and makes auditor sampling more predictable because the pattern is clear.
Role-based background screening also scales well. As you hire into new roles, those roles slot into existing tiers rather than requiring a new policy decision each time. Knowing what type of check to run is only part of the answer. The timing of that check matters just as much.
When should SOC 2 background checks be completed?
Timing is one of the most common audit findings around background screening. The check itself is not usually the problem. The problem is when it happens relative to when the person gets access to systems or customer data.
The safest position is to complete background screening before the person starts work. If that is not possible, the next best option is to complete it before they are granted access to sensitive systems or production environments.
Should background checks happen before hire or before system access?
Completing screening before the hire date is the clearest audit position. It shows that access was only granted after you confirmed the person's background. There is no timing gap for an auditor to question.
If your process allows someone to start and then be screened, the risk is that they get access before the check comes back. Even a few days of access to sensitive systems before screening is complete can become an audit finding when the dates do not line up.
If pre-hire screening is not possible due to time pressure, consider limiting system access until the check returns. Grant access to low-risk tools first, then expand access once screening is complete. Document that decision in writing so you have the evidence if the auditor asks.
What happens if access was granted before the background check was completed?
This happens. Startups move fast. Someone starts on Monday, and the background check result comes back on Thursday. In the meantime, they had access to the codebase or the support dashboard.
The fix is documentation. Create an exception record that notes the timing, the reason, the access that was granted, and who approved the deviation. That turns a gap into a managed exception. Auditors treat those very differently from undocumented gaps.
A pattern of late checks is a bigger problem than a single incident. If it happens regularly, it suggests the control is not operating as designed. A one-off with clear documentation is manageable. A repeated pattern without documentation is an audit finding that is hard to recover from. Your policy is the foundation for all of this, and the next section covers exactly what that policy needs to say.
What should a SOC 2 background check policy include?
Your SOC 2 background check policy is the document auditors will read first. It tells them what you committed to doing. The rest of the evidence tells them whether you did it consistently over the audit period.
A vague or incomplete policy gives auditors room to question whether your control actually exists by design. A clear, specific policy sets expectations, makes sampling predictable, and gives your team a process they can actually follow.
1. Scope
Your policy should name who is covered. At a minimum, it should include all full-time employees with system access, contractors with system access, and any third parties who can reach production environments or customer data.
You should also define what "system access" means in your specific context. Does it include read-only access to the support dashboard? Does it include access to staging environments? Be specific. Vague scope language creates gaps that auditors notice.
If you use a tiered screening model, describe the tiers in the policy itself. Each tier should name the types of roles it covers and the checks required for that tier, so there is no ambiguity when a new hire comes on board.
2. Timing
Your policy should state when screening must be completed relative to the hire date or start date. The clearest approach is to say screening must be completed before system access is granted. That is the strongest audit position.
If your process allows a window after the start date, define that window explicitly. A common benchmark for US employees is within thirty days of hire, though the closer to the start date, the stronger your position.
Your policy should also describe what happens when screening is delayed. Who approves the exception? What interim access controls apply? Those answers should be in the document so they are not invented on the fly when an auditor asks.
3. Exceptions
Every policy needs an exception process. Exceptions happen in practice. The question is whether they are managed deliberately or just accumulated as undocumented gaps.
Your policy should define who can approve an exception, what documentation is required, and where exceptions are logged. An approved exception with clear documentation is an acceptable audit outcome. An undocumented gap is not, even if the same person would have passed if screened on time.
You should also define how long exception records must be retained. For SOC 2 Type 2 report, evidence from the full audit period must be available. Exception logs from the start of the audit window to the end should be retained, organised, and easy to locate.
Background checks are not always legally straightforward across different geographies. Let’s learn what to do when local law limits what you can run.
What if background checks are restricted by country, state, or privacy law?
Global teams run into this regularly. What is standard screening practice in one country is restricted or prohibited in another. SOC 2 compliance background check expectations do not override local law. If a specific check is not lawful in a jurisdiction, you should not run it.
The good news is that auditors understand this. If you can show that you knew about the restriction, documented it, and used a lawful alternative, that is a defensible position. The problem is when teams simply skip screening with no explanation or documentation at all.
How should global companies handle local background check limits?
The best approach is a global baseline policy with country-specific annexes. Your baseline defines your screening intent and standard process. Each country-level annex explains what is permitted locally and what alternatives apply in that jurisdiction.
In the UK, the Information Commissioner's Office provides detailed guidance on what background checks are lawful under UK GDPR. In France, the CNIL sets out proportionality requirements for employee screening. In the US, the Equal Employment Opportunity Commission and state-level fair chance laws shape what you can ask and when.
Building country-level annexes takes more work upfront. But it protects you from both audit gaps and legal violations, which are two very different problems that can both result from the same missing documentation.
What alternative evidence can satisfy auditors when checks are restricted?
When certain checks are legally off-limits, you have other options. Reference checks, employment verification, skills assessments, and manager-level approval are all alternatives that auditors will accept when documented clearly.
The underlying logic is the same as with background checks: you are showing that you evaluated the person before giving them access. The method is different. The documentation requirement is the same.
You should also consider stricter access controls or enhanced monitoring for individuals in jurisdictions where screening is limited. That demonstrates compensating controls and shows risk awareness.
Always involve legal counsel before deciding which checks are lawful in a specific location or jurisdiction. Not all background check outcomes are clean passes, and the next section covers what to do when a check comes back with something concerning.
What happens if someone fails a SOC 2 background check?
A concerning background check result does not automatically mean someone cannot be hired or that they must lose access to systems. SOC 2 does not require automatic rejection. What it requires is a documented, role-based review process.
The question auditors ask is not "did you reject this person?" It is "did you review the finding, assess the risk given that person's access level, and make a documented decision?" That review process is the control, not the outcome of any individual case.
Does a failed background check automatically mean someone cannot be hired?
No. In many jurisdictions, automatic rejection based on a background check finding is actually unlawful. The US Equal Employment Opportunity Commission requires employers to conduct an individualised assessment before taking adverse action based on criminal history. Many states and local governments have additional fair chance requirements on top of that.
For SOC 2, the important thing is that you have a defined process. That process should consider the nature of the finding, how long ago it occurred, and whether it creates a realistic risk given the person's access level.
A well-documented decision, even one that results in a hire, is better than an undocumented pass or a reflexive rejection with no evidence trail.
The background check red flags auditors may care about
Auditors are not employment lawyers. They are not reviewing whether your individual rejection decisions were legally correct. They are checking whether your process was followed and documented for each person in the sample.
That said, certain findings do carry direct audit relevance. An identity mismatch is an immediate concern because it raises questions about whether the person is who they claim to be. Recent fraud or theft-related findings matter more for roles with financial system access or access to customer payment data.
Employment history mismatches matter for roles where claimed experience drove the access decision. Missing or incomplete background check reports are the most common audit problem.
A missing report is a gap in your evidence, regardless of whether the person would have passed if the check had been run.
Background Check Red Flags: Audit Relevance by Role Type
Now that you understand the full control logic, it helps to see how compliance platforms approach this area in practice.
How Various Tools Handle SOC 2 Background Check Evidence
Managing SOC 2 background check requirements manually stops working the moment your team grows past ten people. You are tracking evidence across HR systems, security tools, and legal inboxes while auditor requests arrive on a schedule only your auditor controls. Something always slips.
Compliance platforms exist to close that gap. The names come up most often for SaaS teams preparing for SOC 2: Vanta, Drata, and ComplyJet. Each takes a different approach to evidence collection, background check workflows, and audit readiness.
Here is what each one actually does well and where the limits show up.
What Vanta Does Well for Background Check Workflows
Vanta connects directly to background check providers. It tracks which employees have completed screening, flags those who have not, and surfaces evidence gaps before your auditor does. For teams already using one of those providers, the integration removes a significant amount of manual coordination.
Vanta also maps background check controls to CC1.1 and CC1.4 inside its platform. That mapping helps teams understand where screening evidence fits within the broader audit picture. If you have an established HR stack and existing vendor contracts, Vanta's integrations make evidence collection more systematic than a folder full of PDFs.
Where Drata Approaches SOC 2 Background Checks
Drata SOC 2 tooling treats background checks as part of a broader personnel risk framework rather than an isolated HR step. Drata recommends criminal background checks as a best practice and extends that recommendation to both employees and 1099 contractors.
For third-party workers placed through agencies, Drata suggests confirming that the agency itself runs screening on its own personnel.
Drata's approach to background check automation is built around its personnel monitoring workflows. When a new hire is logged in a connected HR system, Drata can trigger a background check task and track its completion status in the same audit-ready environment where all other SOC 2 evidence lives.
For teams preparing for Drata SOC 2 Type 2 reviews, the connection between HR events and compliance evidence reduces the timeline gaps that typically create audit findings.
Where ComplyJet can be stronger for lean SaaS teams
ComplyJet is built for smaller SaaS teams that need SOC 2 compliance background check readiness without a large internal compliance or IT team behind them. It handles evidence collection, policy mapping, and auditor coordination in one place without requiring enterprise-level tooling.
For security questionnaire automation, ComplyJet uses AI to help teams respond to customer security questionnaires faster. That is a real and ongoing burden for growing SaaS companies, and one that Vanta supports, but where ComplyJet targets faster turnaround for lean teams.
If you want to see how companies manage SOC 2 without getting buried in evidence requests, visit our customers page to see how teams use one platform and one accountable point of contact to move through compliance faster.
For further clarity, visit: ComplyJet Reviews 2026: Details, Pricing, & Features
Once you know your tooling approach, the next step is getting your audit readiness checklist together before the auditor asks for it.
How can teams conduct a SOC 2 background check before the audit?
Audit preparation for background checks is not complicated. It is systematic. Most teams that struggle in this area either forgot to collect evidence during the audit period or cannot locate the evidence they do have when the auditor asks for it.
The goal is simple. You want to be able to hand your auditor a complete set of records for every sampled hire. That means the policy, the check result, the completion date, and the access provisioning record, all in one place.
What should startups do if they are already in the audit window?
If you are inside an active SOC 2 Type 2 audit period and you have gaps, your job is triage. Start by pulling your full employee and contractor list for the audit period. Identify everyone hired or added during that window.
For each person, check whether a background check was completed and note the date. Compare it to the date they received access. Flag any timing gaps or missing records and document them now in an exception log.
Fix the process for any new hires in the future and document the fix. Auditors care about whether you responded to identified gaps, not just whether the gaps existed in the first place. Catching and documenting your own issues before sampling is a stronger audit position than being caught by surprise.
Use this pre-audit checklist to assess your current readiness:
Also read: SOC 2 Compliance Checklist
Frequently Asked Questions
What is a SOC 2 compliant background check company?
SOC 2 does not require you to use a vendor that is itself SOC 2 certified. Any background check provider can support your SOC 2 compliance background check process as long as their results are documented, lawful, and consistently applied across your hires. That said, choosing a vendor with strong data security practices, clear candidate consent workflows, and exportable audit-ready reports makes your evidence collection much simpler.
When evaluating a vendor, look for jurisdiction coverage, criminal record checks, identity verification, employment history checks, turnaround time, and the ability to export timestamped reports. A vendor that generates clean, organised records makes auditor sampling straightforward rather than a last-minute scramble.
How do I choose a background check vendor for SOC 2?
Start with your hiring footprint. If you hire in multiple countries, you need a vendor with international coverage. If you hire domestically, a local provider may be sufficient. Check that the vendor handles candidate consent in compliance with local privacy law and produces records that are exportable for audit purposes.
For SOC 2 audit requirements, prioritise vendors that generate clear, dated, exportable reports. You should be able to pull a record for any hire and hand it to an auditor with a result, a date, and a vendor name. Integrations with your HR system or compliance platform help keep that evidence organised without manual effort between hires.
What are the key background check requirements for SOC 2?
SOC 2 does not prescribe exact checks. But auditors generally expect a documented policy, a defined scope for who is screened, completed screening for all in-scope hires during the audit period, proof that timing was appropriate relative to access provisioning, and an exception log for any deviations from the standard process.
Common checks include criminal record searches, identity verification, employment verification, education verification, and professional reference checks. The depth of each check should match the risk of the role. Higher-risk roles with access to production systems or customer data should receive more complete screening than lower-risk roles with limited access.
What reasons would make someone not pass a background check?
Common reasons include identity mismatches, undisclosed criminal records, employment history discrepancies, education credential mismatches, and sanctions or watchlist hits. For roles with financial system access, recent fraud-related findings carry higher weight. For roles with direct access to customer data, identity mismatches and deception-related findings are the most concerning.
A failed background check does not always mean rejection. The EEOC requires an individualised assessment before adverse action based on criminal history in the US. For SOC 2, what matters is that you document the review and the decision, whatever that decision turns out to be.
What are the major red flags on a background check for SOC 2?
From a SOC 2 perspective, the most important red flags are identity mismatches and fraud-related findings for roles with financial or administrative access. False employment claims matter for technical roles where access decisions were based on claimed experience. A misrepresentation that drove an access decision is a real personnel-risk problem.
An incomplete or missing background check report is also a significant red flag, though for a different reason. A missing report is a gap in your SOC 2 compliance background check evidence. That is an audit finding regardless of whether the person involved would have passed if the check had been run properly.
How do you tell if you failed a background check?
From the candidate's side, an employer must provide notice if they are taking adverse action based on a background check finding and give the candidate a reasonable opportunity to dispute the information. This is required under applicable consumer reporting laws and varies by jurisdiction.
From the employer side, a concerning check result means your next step is to assess the finding against the role, document your decision, and either proceed with hire, modify the access level, or decline with a clear paper trail. SOC 2 cares about whether you managed the outcome through a documented process, not just whether you ran the check.
What all pulls up on a background check?
Standard background checks typically include identity verification, criminal record searches, employment history, education history, professional license checks, right-to-work verification, and reference checks.
Some roles also include credit checks, particularly for positions with financial system access. Sanctions and watchlist searches are common for regulated industries and roles with significant financial authority.
SOC 2 does not require all of these for every role. The checks you run should reflect the access risk of that specific role. Defining this in your policy by tier or role type keeps your screening approach defensible and consistent during audits.
How far back does a background check go for SOC 2?
SOC 2 itself does not define a lookback period. The lookback window depends on the vendor, the type of check, the role, and local law.
Some US states limit criminal history look back to seven years for certain positions under consumer reporting law. Other jurisdictions have different rules entirely.
For audit readiness, define your lookback approach in your policy and apply it consistently. Consistency matters more than the exact window. An auditor is unlikely to challenge a seven-year lookback if it is defined clearly in your policy and applied to every hire in the same risk tier.
Are background checks required for contractors in SOC 2?
Contractors with system access are generally in scope for SOC 2 background check requirements. Their employment status does not reduce the access risk they carry.
A contractor who can access your codebase, your customer data, or your support tools carries the same personnel risk as a full-time employee in the same role.
If contractors come through an agency, you can request a written attestation that the agency screens its own workers. Document the attestation and keep it on file for auditor requests. If you work directly with individual contractors, run the screening yourself. The access level drives scope, not the contract type.
The final answer
SOC 2 background check requirements are not a rigid checkbox. They are a personnel risk control. Auditors want proof that your company screens the right people, at the right time, keeps the right evidence, and handles exceptions consistently across the board.
The framework does not tell you which checks to run or which vendor to use. It asks whether your process reduces the risk of giving the wrong person access to systems, data, or tools that carry real consequences. Background screening is the most common way to answer that question, and it is the one most auditors expect to see.
Build a policy that reflects your real access model. Screen based on role risk. Keep evidence for every hire in scope. Document your exceptions with approvals and rationale.
Apply the same process every time, without shortcuts that are not explicitly managed.
If you do those things, you will go into your audit with a clear answer when your auditor pulls a sample and asks for the evidence behind your control. That is the only goal that matters.
But most teams know what they need to do. The gap is in building a system that does it consistently without a dedicated compliance team running it.
That is exactly what ComplyJet is built for.
Start your free trial and see how lean SaaS teams use one platform to manage background check evidence, policies, auditor coordination, and security questionnaires without starting from scratch.
