Screening

HITRUST CSF v11 02.b requires you to run lawful, ethical background screening on all employment candidates, contractors, and third-party users, and to scale the depth of screening to the role’s risk and the sensitivity of the information they can access. Operationalize it by defining screening tiers, gating system access on cleared results, and retaining proof of checks, decisions, and exceptions. ¹

Key takeaways:

• Screen everyone who will get access (employees, contractors, third-party users), not just new hires. ¹
• Make screening risk-based and tied to data classification and access rights, then enforce it with access “gates.” ¹
• Auditors look for consistency: documented tiers, completed checks, adjudication records, and exception approvals. ¹

“Screening” in HITRUST is not a vague HR best practice. It’s a control requirement that connects people risk to information risk: before a person becomes an insider with access to your systems or sensitive data, you must perform background verification checks that comply with applicable laws, regulations, and ethics, and you must size those checks to the risk of the role. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to implementation is to treat screening as an access control dependency, not an onboarding formality. Your job is to define (1) who must be screened, (2) what checks apply based on business need, data classification, and risk, (3) what “clear” means and who decides, and (4) how you prevent access before clearance. ¹

This page gives requirement-level guidance: plain-English interpretation, scope, step-by-step execution, evidence to retain, and audit-ready talking points. If you manage screening across HR, Procurement, IT, and third-party access, the core operational win is one workflow and one set of artifacts, even if the checks are performed by different providers.

Regulatory text

HITRUST CSF v11 02.b (excerpt): “Background verification checks on all candidates for employment, contractors, and third-party users shall be carried out in accordance with relevant laws, regulations, and ethics. Screening shall be proportional to the business requirements, the classification of information, and the risks involved.” ¹

What an operator must do:

1. Perform background verification checks for every person in scope: employees, contractors, and third-party users who will access your environment. ¹
2. Follow applicable legal and ethical constraints (for example, consent, fair hiring, local restrictions, data minimization), and document how you do that. ¹
3. Make screening risk-based by tying the screening package to business requirements, information classification, and access risk. ¹

Plain-English interpretation (what “screening requirement” means in practice)

You must be able to prove two things:

• Coverage: every individual who will get access has been screened, including non-employees (contractors and third-party users). ¹
• Proportionality: you don’t run the same check for every role by default; you define tiers based on what the person can access and the harm that could result from misuse. ¹

A clean implementation uses “screening tiers” mapped to role types and data classification, plus access control gates so accounts are not enabled until screening is complete (or an exception is documented and approved).

Who it applies to (entity and operational context)

Entity scope: Any organization implementing HITRUST CSF controls. ¹

People scope (the common miss):

• Candidates for employment (pre-hire / pre-start screening). ¹
• Contractors (independent contractors, temps, agency staff). ¹
• Third-party users (any external party with logical or physical access to your systems, facilities, networks, or data). ¹

Operational contexts where auditors expect tight execution:

• Access to systems that store or process sensitive health information, regulated data, or customer data.
• Privileged access (admins, engineers, database operators).
• Third parties with remote access (support, billing, analytics, managed services).
• Mergers, acquisitions, and rapid onboarding where “temporary access” becomes permanent.

What you actually need to do (step-by-step)

1) Define your screening standard and governance

Create a “Personnel & Third-Party User Screening Standard” that includes:

• In-scope populations (employees, contractors, third-party users). ¹
• The decision owner for screening outcomes (HR, Compliance, Security, or a joint adjudication model).
• The rule: no access until cleared, with a documented exception path.

Deliverable: approved standard + RACI for HR, Security, Procurement, and IT.

2) Build screening tiers tied to access risk and information classification

Create tiers that are easy to apply during onboarding and third-party provisioning. Example structure (you define the checks based on your legal context and risk model):

Tier	Typical access profile	Trigger criteria	Expected outcome
Tier A (baseline)	Limited internal access	Low-risk roles, minimal data access	“Clear” required before account activation
Tier B (sensitive)	Access to sensitive data	Access to higher-classified information	Enhanced review and documented adjudication
Tier C (privileged)	Admin/privileged access	Domain admin, production access, key management	Highest scrutiny; tight exception control

Your mapping logic must reference business requirements, data classification, and risk because that is what HITRUST explicitly tests. ¹

Deliverable: tier matrix + role-to-tier mapping guidance.

3) Integrate screening into onboarding and third-party access workflows (“access gates”)

Operationalize screening with enforceable gates:

• HR onboarding gate: offer acceptance triggers screening; start date and system access depend on completion.
• Contractor onboarding gate: Procurement or the sponsoring manager cannot request access until screening status is recorded.
• Identity governance (IGA) gate: the identity ticket (or joiner workflow) requires an attached screening result or attestation.

Deliverable: workflow steps in your ticketing/IGA tool showing where screening evidence is captured before access is granted.

4) Collect consent, handle privacy, and document lawful processing

The control explicitly requires compliance with “relevant laws, regulations, and ethics.” ¹ That means you should:

• Capture applicant/worker consent when required.
• Limit who can view screening results (need-to-know).
• Store results securely and retain only what you need for the control and for HR/contractual purposes.

Deliverable: consent record + access restrictions to screening files + retention rule.

5) Adjudicate findings consistently (and record the decision)

Define:

• What constitutes “clear,” “consider,” and “fail” (or your equivalent).
• Who can override a finding and what approvals are required.
• How you treat disputes, corrections, or incomplete checks.

Deliverable: adjudication SOP + completed adjudication records for sampled hires/third-party users.

6) Address third-party users explicitly (contractual + operational)

For third-party users, you typically have two acceptable operational models:

• Your organization runs the check (direct screening).
• The third party attests that it screened its personnel consistent with your requirements, and you validate that attestation during due diligence and periodically thereafter.

Either way, you must be able to show that third-party users were screened before they accessed your environment. ¹

Deliverable: contract clause or security addendum language + attestation evidence + access roster tied to screening status.

7) Monitor and re-screen based on risk events

HITRUST 02.b does not state a fixed rescreen cadence. ¹ Operators still need a trigger-based approach:

• Role change into privileged access.
• Rehire after a break in service.
• Material policy violations or credible insider risk events.
• Expansion of access to higher-classified information.

Deliverable: trigger list embedded in HR change and access request workflows.

Required evidence and artifacts to retain (audit-ready)

Auditors usually test screening by sampling joiners and third-party users and tracing to evidence. Build an evidence pack you can produce quickly:

1. Screening policy/standard showing scope and proportionality criteria. ¹
2. Role-to-tier mapping tied to information classification and access risk. ¹
3. Completed screening results (or provider confirmation) for sampled individuals.
4. Consent and disclosures where applicable.
5. Adjudication records for any “consider” outcomes, including approvals and rationale.
6. Exception log with compensating controls and time-bounded approvals.
7. Third-party artifacts: contract clauses, third-party attestation, and an access list showing screened status for third-party users. ¹
8. Access gate evidence: tickets/workflow screenshots showing access granted after screening completion (or approved exception).

Common exam/audit questions and hangups

Expect these questions and prepare tight answers with artifacts:

• “How do you ensure contractors and third-party users are screened?” Show your in-scope definition, onboarding workflow, and an access roster tied to screening evidence. ¹
• “How did you decide what checks apply to which roles?” Produce the tier matrix and mapping to data classification and risk. ¹
• “Can someone get access before screening completes?” If yes, show the exception process, approvals, and compensating controls.
• “How do you handle international hires or jurisdictions with limits on checks?” Show your lawful/ethical processing approach and how the tiering adapts by jurisdiction. ¹
• “Show evidence for a sample of third-party users.” This is where many programs fail because they only have employee records.

Frequent implementation mistakes (and how to avoid them)

1. Treating screening as HR-only. Fix: make Security/IT part of the gate. If accounts can be created without screening proof, the control fails in practice.
2. No written proportionality logic. Fix: document tier triggers tied to data classification and access rights. ¹
3. Third parties covered “by assumption.” Fix: require attestation or run checks yourself, and keep a roster of third-party users with evidence. ¹
4. Storing raw reports everywhere. Fix: restrict access, store centrally, and retain decision evidence without broad distribution.
5. Exceptions without expiry. Fix: time-bound exceptions and require re-approval when access or role changes.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat enforcement context as indirect: screening failures tend to amplify insider threat, fraud risk, and unauthorized disclosure risk. The practical exam risk is straightforward: if you cannot demonstrate screening coverage for contractors and third-party users, assessors often record a control gap because the text explicitly includes those populations. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope + gates)

• Publish the screening standard with in-scope populations and “no access until cleared” rule. ¹
• Inventory all access pathways for non-employees (VPN, SaaS, support portals, on-site badges).
• Implement a minimal access gate in your ticketing/IGA workflow: required field for screening status/evidence reference before provisioning.

Days 31–60 (tiering + third-party alignment)

• Build screening tiers and map them to roles and data classifications. ¹
• Update HR and contractor onboarding checklists to include tier assignment and adjudication owner.
• Add third-party contract language or an attestation process for third-party user screening; pilot with high-risk third parties.

Days 61–90 (evidence hardening + exception discipline)

• Create an exception log with approval workflow and compensating controls.
• Run an internal audit-style sample: select recent employees, contractors, and third-party users; verify evidence completeness end-to-end. ¹
• Operationalize trigger-based re-screening for role changes into privileged or sensitive access.

Where Daydream fits naturally: If your bottleneck is chasing evidence across HR, IT tickets, and third-party attestations, Daydream can centralize the screening requirement workflow and evidence collection so you can answer assessor samples quickly without rebuilding spreadsheets each audit cycle.

Frequently Asked Questions

Do we have to screen every single third-party user, even if they only have limited access?

HITRUST 02.b includes “third-party users” in scope and requires screening proportional to risk. ¹ You can apply a lighter tier for low-risk access, but you still need a defined process and evidence.

Can we rely on a staffing agency’s background checks for contractors?

Yes, if you can show the checks were performed and are aligned to your screening tiers and legal/ethical requirements. ¹ Keep the agency attestation and tie it to the specific individuals who received access.

What does “proportional” screening look like in an audit?

Auditors look for documented tiering logic tied to business requirements, information classification, and risk, plus consistent application. ¹ A role-to-tier matrix and sampled proof usually satisfies this.

Do we need to re-screen employees periodically?

HITRUST 02.b does not state a specific frequency. ¹ Most programs implement trigger-based re-screening for role changes, access expansion, or credible risk events and document those triggers.

How do we handle jurisdictions where certain checks are restricted?

Keep the requirement intact by documenting jurisdictional variations, capturing required consent, and applying alternative risk controls where a check cannot be performed. ¹ The audit focus is whether you followed relevant laws and still managed access risk.

What evidence is “enough” without storing full background reports?

Keep a verification record that shows what was checked, the completion date, the outcome, and who adjudicated it, with access restricted to need-to-know. ¹ Retain enough detail to prove the tier was applied correctly and access was gated.

Footnotes

1. HITRUST CSF v11 Control Reference