HiringCoach.ai

Background checks

Last reviewed 2026-05-18

<h2>Requirement</h2> <p>HiringCoachAI performs third-party background checks before any worker is granted access to sensitive systems, regardless of worker type (full-time employee, contractor, short-term helper, intern, or volunteer).</p> <p>A background check is required before any worker is granted any of the following access:</p> <ul><li>Production system access</li><li>Customer-data access</li><li>Source-code access</li><li>Vendor-dashboard access</li><li>Administrative access to compliance, security, payment, or identity systems</li></ul> <p>Sensitive-system access is not automatic for any worker type. The Security Officer approves or denies every request for production, customer-data, source-code, vendor-dashboard, payment, identity, security, or compliance-administrator access based on business need, least privilege, signed confidentiality / acceptable-use terms, training status, and risk.</p> <h2>Exceptions</h2> <ul><li><strong>Planned exception:</strong> any future request to grant sensitive access to a worker for whom third-party screening is operationally infeasible requires formal amendment of this policy, with documented Security Officer approval and written rationale, before access is granted.</li><li><strong>Emergency exception:</strong> documented emergency-access exceptions follow the exception process in the patch-management policy.</li></ul> <h2>Current state</h2> <p>Current sensitive-system access is covered by an owner/officer exception to employee/vendor screening, with compensating controls under access control, training, MFA, audit logging, and change management. Before any additional worker receives sensitive access, third-party screening is required.</p> <p>Limited internal-document collaboration that does not include customer data, source code, production systems, or vendor dashboards does not trigger the screening requirement above.</p> <p>Background-screening records are retained internally when the requirement is triggered.</p> <h2>Check components</h2> <p>For pre-access screening, at minimum:</p> <p>1. <strong>Identity verification</strong>: confirmed via government-issued ID. 2. <strong>Employment eligibility</strong>: verified per jurisdictional requirements (I-9 in US for full-time employees; equivalent worker-type checks for other workers). 3. <strong>Criminal history</strong>: national criminal records search (US: multi-state; non-US: equivalent per country). 4. <strong>Education / credential verification</strong>: for claimed credentials material to the role. 5. <strong>Sex-offender registry search</strong> (US). 6. <strong>Global sanctions / PEP screen</strong> (OFAC, EU, UK consolidated lists).</p> <h2>Provider</h2> <p>Preferred: <strong>Checkr</strong>. Alternatives: HireRight, Sterling, Yardstick. Provider choice is the Security Officer&#39;s discretion and may vary by jurisdiction.</p> <p>The provider&#39;s report is retained internally in hashed or redacted form, recording only the date of check, provider, result (pass / fail / pending), and provider reference number. Raw reports are retained by the provider per their policy and are not duplicated locally.</p> <h2>Non-US personnel</h2> <p>Equivalent checks per jurisdiction, respecting local labor and privacy law (e.g., EU may limit criminal-record searches; Germany has strict rules on reference checks). The Security Officer confirms jurisdictional fit before initiating.</p> <h2>Re-checks</h2> <p>For any worker with continuous sensitive access:</p> <ul><li><strong>At role change</strong> that grants new sensitive access (e.g., promotion to admin or security alternate).</li><li><strong>Every 5 years</strong> for workers with continuous production access.</li><li><strong>On credible concern</strong> (flagged by another team member, audit finding, external report).</li></ul> <h2>Failure</h2> <p>A &quot;fail&quot; result does not automatically disqualify; the Security Officer reviews with legal counsel if available to determine whether the finding is material to the role. If material, the offer is withdrawn or access is not granted.</p> <h2>Consent</h2> <p>Candidates are informed in writing that a check will be conducted and sign consent (FCRA-compliant in the US for full-time employees; equivalent worker-type consent for other workers) before it runs.</p> <h2>Non-sensitive access (no screening required)</h2> <p>Internal-only access that does not include customer data, source code, production systems, or vendor dashboards does not trigger the screening requirement above. The Security Officer may authorize such non-sensitive access for contractors, short-term helpers, interns, or volunteers when all of the following are true:</p> <ul><li>The access is justified by a documented business need</li><li>Access is least-privilege and time-bounded where practical</li><li>Confidentiality / acceptable-use terms are acknowledged before access</li><li>Required security or privacy training is completed before sensitive operational work</li><li>The access level is approved by the Security Officer</li><li>The access scope does not include any of the sensitive systems listed under §Requirement</li></ul> <p>The Security Officer may deny any access request, narrow the scope, or require the worker to complete third-party background screening before the request is reconsidered.</p> <h2>Related</h2> <ul><li><a href="/trust/docs/access-control-policy">Access control policy</a> (provisioning and deprovisioning section)</li><li><a href="/trust/docs/acceptable-use">Acceptable use</a></li><li><a href="/trust/docs/information-security-policy">Information security policy</a></li></ul>

← Back to the trust center

showUpgradeModal: false, modalType: migration, planName: