Most SOC 2 auditors will pick a handful of recent hires from your employee list and request one specific artifact: the completed background check, dated before the start date, sourced from a documented vendor. If you cannot produce it, that is an exception in your report.
The control sits inside CC1.4, the Common Criteria provision the AICPA derives from COSO Principle 4, and it is one of the most reliably tested items in a first-year SOC 2 examination.
Background screening is not the most technically complex part of SOC 2. It is, however, one of the most procedurally fragile. The policy looks simple on paper. Then a contractor starts a week early because someone needed help shipping a release, the vendor screening gets postponed, and a year later an auditor finds the gap in twenty minutes.
This guide explains what SOC 2 actually requires when it comes to background checks, what auditors look for in practice, and how to build a screening programme that holds up under sampling.
What Is a SOC 2 Background Check?
A SOC 2 background check is the pre-employment screening a service organisation performs to verify that the people it hires can be trusted with access to systems and data inside the SOC 2 scope. It is the operational evidence that supports the abstract principle baked into the Trust Services Criteria: the organisation hires competent people of sound integrity, and it can prove it.
In practice, that means a documented check performed by a third party that returns verified information about identity, criminal history, employment history, and, depending on the role, education and credit. The check is run against every new hire before they get logical or physical access to systems within scope. The result is stored, mapped to a named employee, and retrievable on demand.
It is worth being clear on one thing: SOC 2 does not prescribe what a background check must contain. The AICPA criteria describe outcomes, not procedures. Your policy is what defines what gets checked, on whom, and how often. The auditor then tests whether you followed your own policy.
Why SOC 2 Background Checks Are Important
Insider risk is one of the few attack vectors that perimeter security cannot fix. An employee or contractor with legitimate credentials and undisclosed motives sits inside the network from day one. Background checks are how mature security programmes reduce the probability of that scenario before it begins. According to the Verizon 2024 Data Breach Investigations Report, insider threats continue to represent a persistent and costly category of security incidents, reinforcing why personnel vetting remains a foundational control.
Auditors care for a related reason. The Control Environment criteria (CC1) sit at the top of the SOC 2 framework because everything else rests on the assumption that the people running the controls are competent and trustworthy. Skip the screening step, and the rest of the audit is built on a weaker foundation. That is why background check evidence is one of the first things auditors sample, and why a missing or late check shows up as an exception even when the rest of your control environment is strong.
Insider Note: Auditors do not just check that the screening happened. They check the timing. A background check completed two months into employment is often treated the same as no check at all, because access to in-scope systems was granted before the control was operative. Time stamps matter as much as the document.
SOC 2 Background Check Requirements
Which Trust Service Criteria Require Background Checks?
Background checks are explicitly referenced in the Common Criteria that apply to every SOC 2 engagement, regardless of which optional Trust Services Categories you include. The two controls that matter most are CC1.1 and CC1.4.
CC1.1 establishes the entity’s commitment to integrity and ethical values. Background checks support this by demonstrating due diligence in selecting people who meet the organisation’s standards of conduct. CC1.4 is more direct: it derives from COSO Principle 4, which states that the entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives. Within CC1.4, evaluating individual backgrounds is named as a specific point of focus. That is the hook auditors use.
Because these are Common Criteria, they apply regardless of whether you are scoping Security only or adding Availability, Confidentiality, Processing Integrity, or Privacy. There is no version of SOC 2 that escapes them.
Who Needs to Be Background Checked for SOC 2?
The short answer: anyone whose role gives them logical or physical access to systems, data, or facilities within your SOC 2 scope. The longer answer requires you to draw the line in your own policy and stick to it.
At a minimum, this includes full-time employees who join the organisation after the policy is in place. Most mature programmes extend the requirement to part-time employees, contractors who receive credentials, and outsourced personnel performing in-scope work. Vendors are usually handled differently — through contractual flow-down requirements rather than direct screening — but the principle is the same: people inside the trust boundary must be vetted.
Roles with privileged access (engineers with production credentials, finance staff with payment system rights, support personnel handling customer data) often warrant deeper screening than baseline roles. Documenting this risk-based approach in your policy is good practice and helps you defend the design of your control during the audit.
What Types of Checks Must Be Performed?
The Trust Services Criteria do not specify which checks to run. That decision sits with the organisation, informed by role, jurisdiction, and regulatory context. A common baseline for SOC 2 purposes covers several distinct areas.
Identity verification confirms the candidate is who they claim to be.
Criminal history — national, state, or county-level depending on jurisdiction — flags relevant offences.
Employment verification confirms the work history disclosed during hiring.
Education verification matters for roles where credentials are material. For positions touching finance, payments, or fiduciary responsibility, a credit check may be appropriate. For roles with global reach, a global sanctions and watchlist screen is often added.
The point is not to maximise the number of checks but to match the depth of screening to the sensitivity of the role. An auditor reviewing your programme will look for that logic.
Pro Tip: Build a screening matrix that maps role categories
Build a screening matrix that maps role categories (engineer, finance, support, executive) to specific check types. Reference this matrix in your background check policy. When an auditor asks why a particular hire received a particular set of checks, the matrix is your answer — and it removes the discretion that creates inconsistency.
What SOC 2 Auditors Expect to See
Documentation and Evidence Requirements
Auditors test SOC 2 controls through sampling, not blanket review. Expect them to request a list of all employees and contractors hired during the audit period, then pick a representative sample — often between five and fifteen people, depending on company size. For each name on that sample, they will ask for the completed background check report (or evidence summarising its completion, since some organisations retain only a confirmation rather than the full report for privacy reasons), the date the check was completed (which must precede the date of system access), the name of the screening vendor used, and evidence that any adverse findings were reviewed and adjudicated according to policy.
Auditors are looking for consistency. If your policy says screening completes before the start date, every sample must show that. If your policy says re-screening occurs every two years for long-term staff, expect a sample of tenured employees and a request for refresh evidence. For a structured walkthrough of what evidence to prepare across the full audit lifecycle, the SOC 2 compliance checklist is a useful starting point.
Roles and Responsibilities for SOC 2 Background Check Compliance
Background screening is one of the few SOC 2 controls that crosses HR, security, legal, and operations in equal measure. Confusion about ownership is a common reason controls fail.
A workable division typically gives HR end-to-end operational responsibility — running the check, retaining the record, notifying the hire. Security or compliance owns the policy itself and the mapping to SOC 2 controls. Legal owns the regulatory perimeter, particularly Fair Credit Reporting Act (FCRA) obligations in the US and equivalent laws elsewhere. The hiring manager is the gate that prevents access provisioning before clearance is confirmed.
Write these roles into the policy explicitly. An auditor reading your documentation should be able to identify the responsible owner for each step without asking.
Ongoing Monitoring and Continuous Compliance
The SOC 2 Type 2 examination tests whether your controls operated effectively over time, not just whether they exist on paper. That changes how you think about screening. Continuous compliance means three things in this context. First, every new hire goes through the policy, every time, with no exceptions tolerated without documented justification. Second, periodic re-screening for high-trust roles — typically every two to three years — captures changes that occur after employment begins. Third, exception handling is itself a documented control, with risk acceptance, approval, and remediation timelines recorded.
Worth Knowing: A 2024 CFPB advisory
A 2024 CFPB advisory opinion clarified that consumer reporting agencies must prevent the reporting of information that has been legally sealed or expunged, and must avoid duplicative records. This shifts some compliance risk onto the screening provider — which is precisely why vendor selection matters for SOC 2.
How to Embed Background Checks Into Your Hiring Workflow for SOC 2
Background Check Policy Best Practices
A SOC 2-ready background check policy answers six questions clearly: who is subject to screening (employees, contractors, others); what checks are run for each role category; when the check must be completed relative to the start date; how adverse findings are reviewed and adjudicated; who owns each step; and how records are retained and for how long.
Avoid policies that read like aspirations. Auditors test against the policy as written. If the policy says “background checks are performed prior to employment,” every sample must show that. A weaker but more accurate policy — “background checks are initiated prior to start date and completed within 30 days” — is often the better choice because it matches operational reality. To understand how this kind of policy gap becomes an audit finding, see our guide on how to avoid common SOC 2 pitfalls.
Training and Awareness for SOC 2 Compliance
The people who recruit, onboard, and provision access need to understand the screening policy as a hard control, not a recommendation. The two failure modes worth training against are urgency pressure — a hiring manager pushing for early access because the role is critical — and inconsistency, where different recruiters apply the policy differently for similar roles.
Annual security awareness training is a natural place to reinforce this. So is the onboarding process for new hiring managers, recruiters, and HR business partners. The SANS Security Awareness programme is one widely used framework for structuring this kind of training at scale.
How to Document Background Checks for Your SOC 2 Audit
For each hire, retain a record that includes the candidate’s name, the screening vendor, the date the check was completed, the scope of the check performed, and any adjudication notes if findings required review. Store these records in a system that the audit team can access without ad-hoc retrieval. A centralised HRIS or compliance platform is the usual choice. Email folders are not.
When the auditor samples, you should be able to produce the evidence within hours, not days. Audit response time is itself a signal of programme maturity.
Benefits of SOC 2 Background Checks
Credibility and Client Trust
Enterprise procurement teams routinely ask whether your hiring process includes background screening as part of their security review process. A clean answer with documented evidence shortens security review cycles and removes a friction point that often delays deals. As noted in Gartner’s research on enterprise security posture, buyers increasingly scrutinise personnel controls as part of third-party risk assessments — making your screening programme a commercial as well as a compliance asset.
Demonstrable Security Focus
Screening is one of the most visible signals that an organisation treats personnel security seriously. It anchors the conversation about insider risk and gives security leaders something concrete to point to when clients, auditors, or board members ask how the organisation manages human-layer risk.
Risk Management
The link between pre-employment screening and reduced incident rates is well established. The Society for Human Resource Management (SHRM) notes that background checks are among the most consistent risk mitigation tools available at the hiring stage. Screening will not catch every risk, but it removes the most obvious ones at the cheapest point in the employment lifecycle.
Regulatory Compliance Across Multiple Frameworks
Background checks support compliance with frameworks well beyond SOC 2. ISO 27001 references personnel screening in Annex A.6.1.1. HIPAA requires workforce clearance procedures for anyone accessing protected health information. PCI DSS mandates background investigations for personnel with access to cardholder data environments. A well-designed programme satisfies several of these requirements at once, making it one of the more efficient investments in your compliance portfolio.
Important: A SOC 2 background check programme that does not also comply with the Fair Credit Reporting Act in the US — or equivalent laws elsewhere — is a legal exposure, not a control. Disclosure forms, written consent, pre-adverse action notices, and final adverse action notices are mandatory when a US-based hiring decision is based even partly on screening results. Class-action settlements in this space run into tens of millions of dollars annually.
Frequently Asked Questions
Is ISO 27001 compliant with GDPR?
ISO 27001 is compatible with GDPR and supports many of its requirements, particularly around security of processing, access control and incident management. It is not, by itself, a complete route to GDPR compliance, because it does not address privacy-specific obligations such as lawful basis and data subject rights.
Does achieving ISO 27001 mean I am GDPR compliant?
No. Certification proves you have a working information security management system. GDPR compliance additionally requires lawful basis, transparency, consent where relevant, handling of data subject rights, data protection impact assessments and lawful international transfers. A certified ISMS covers the security pillar of GDPR, not the whole regulation.
Is GDPR an ISO standard?
No. GDPR is European Union law, enforced by national supervisory authorities. ISO standards are voluntary frameworks published by the International Organization for Standardization. They can support legal compliance, but they are not laws and cannot replace one.
Do I need both ISO 27001 and GDPR compliance for my business?
If you process personal data of individuals in the EU, GDPR compliance is legally required. ISO 27001 remains optional, but it provides the security backbone that GDPR expects and is often demanded by customers and partners. Most organisations handling EU personal data benefit from running both.
Which should be implemented first, GDPR or ISO 27001?
GDPR is the legal obligation, so its requirements cannot wait. In practice, building the ISMS first is efficient, because it produces much of the risk assessment and many of the “appropriate technical and organisational measures” GDPR requires. The pragmatic answer is to plan them together rather than strictly sequencing one before the other.
What are the penalties for non-compliance with GDPR vs. ISO 27001?
GDPR carries administrative fines of up to €10 million or 2% of global turnover for less severe breaches, and up to €20 million or 4% for serious ones, whichever is higher. ISO 27001 has no legal penalty. Failing an audit means losing or not obtaining the certificate, which is a commercial consequence rather than a fine.
What types of organisations benefit most from pursuing both ISO 27001 and GDPR compliance?
Organisations that handle significant volumes of EU personal data and that sell to security-conscious customers gain the most. Technology and SaaS providers, healthcare and financial services firms, and any processor handling data on behalf of EU clients benefit from pairing a recognised security certification with demonstrable privacy compliance.
How does ISO 27701 relate to both ISO 27001 and GDPR?
ISO 27701 defines a Privacy Information Management System and adds privacy controls that ISO 27001 does not cover, with a built-in mapping to GDPR requirements. It began as an extension to ISO 27001 and, since the 2025 revision, can be implemented and certified as a stand-alone standard. It is the most direct bridge between an ISO security programme and GDPR’s privacy obligations, though it still does not amount to legal certification of compliance.
Conclusion
SOC 2 background checks sit at the intersection of HR, security, legal, and audit. The technical bar is not high, but the procedural discipline is. A defensible programme combines a clearly written policy, a vendor that produces audit-ready evidence, integrated workflows that prevent timing failures, and consistent documentation across every hire. Get those four elements right, and the CC1.4 sample becomes one of the easier parts of the audit, rather than the place your report picks up its first exception.
If you are building or overhauling your screening programme as part of a broader SOC 2 readiness effort, learn more about what a structured compliance engagement looks like in practice.
