Personnel Background Screening

PCI DSS 4.0.1 Requirement 12.7.1 requires you to run background screening on anyone who will have access to the cardholder data environment (CDE) before hire, within local legal constraints. To operationalize it fast, define which roles are “CDE-access,” standardize the screening package and decision criteria, block CDE access until screening clears (or an approved exception exists), and retain auditable proof. ¹

Key takeaways:

• Scope first: tie screening to CDE access paths, not job titles.
• Gate access: no CDE credentials or badges until screening is complete or an approved exception is documented.
• Evidence wins audits: keep screening results, adjudication notes, and exception approvals linked to access tickets. ¹

“Personnel background screening requirement” under PCI DSS is a control that assessors expect to see working as a hiring-and-access gate, not a statement in an HR policy binder. Requirement 12.7.1 is narrowly framed: it applies to potential personnel who will have access to the CDE, and it must occur prior to hire, within the constraints of local laws. ¹

Operationally, the quickest way to meet this requirement is to treat it as an identity risk control embedded into two workflows you already have: recruiting/onboarding and access provisioning. Your HR team (or a third-party screening provider) performs checks; your security/IAM team enforces a “no-screen, no-access” condition; your compliance team defines the standard and audits exceptions.

This page gives requirement-level implementation guidance you can copy into procedures: who is in scope, what a defensible screening standard looks like, how to handle local-law limitations, what evidence to retain for a QSA/ISA, and the exam questions that typically expose gaps. Where helpful, it also notes how tools like Daydream can keep screening evidence tied to access decisions and exceptions across teams.

Regulatory text

Requirement (verbatim): “Potential personnel who will have access to the CDE are screened, within the constraints of local laws, prior to hire to minimize the risk of attacks from internal sources.” ¹

What this means for an operator

• “Potential personnel” includes employees, contractors, temporary staff, interns, and third-party personnel you onboard into roles that can access the CDE.
• “Will have access to the CDE” is a scoping trigger. If a role can authenticate into CDE systems, administer CDE components, access cardholder data, or enter CDE-restricted spaces, the role is in scope.
• “Screened… prior to hire” means the screening happens before you finalize employment (and, in practice, before you grant CDE access). If local employment practices complicate “prior to hire,” your compensating approach should still ensure no CDE access is granted until screening is completed or an exception is approved and time-bounded.
• “Within the constraints of local laws” means you must adapt the screening package by country/state (or other jurisdiction) and document those constraints and the alternative checks you do perform. ¹

Plain-English interpretation

If someone could get into your cardholder data environment, you must vet them before bringing them on, as far as the law allows where they live/work. Then you must be able to prove you did it.

---

Who it applies to (entity and operational context)

In-scope organizations

• Merchants and service providers that store, process, or transmit account data.
• Service providers whose people, processes, or systems can affect the security of the CDE. ¹

In-scope personnel (practical scoping)

Treat a person as in scope if they can do any of the following:

• Log into a system that is in the CDE.
• Administer infrastructure that hosts, segments, monitors, or protects the CDE (common examples: firewalls, hypervisors, EDR consoles, SIEM with CDE logs).
• Access storage locations where account data exists.
• Enter CDE-controlled physical areas (data center cages, restricted network rooms).
• Provide support with privileged escalation paths into the CDE (on-call SREs, DBAs, security engineers). ¹

Tip for fast operationalization: define a “CDE Access Population” list based on access pathways (systems, groups, badges), then map roles to that list. This prevents gaps when job titles change.

---

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

1) Define “CDE access” in your environment (scope statement)

Create a short scoping statement that names:

• CDE systems and admin tools
• Identity groups/roles that grant CDE access
• Physical access controls for CDE spaces
• Third parties whose personnel can obtain those access paths (managed service providers, on-site technicians)

Deliverable: CDE Access Definition + Role-to-Access Map aligned to PCI scoping. ²

2) Establish a background screening standard (what checks, decision rules, ownership)

Write a procedure that answers:

• Who orders the screening: HR, vendor management, or security operations.
• When: after conditional offer, before start date, and before any CDE access provisioning.
• What checks: specify the package at a requirements level (do not rely on “we run a background check”).
• Adjudication criteria: what findings trigger escalation, rejection, or additional review.
• Local-law variants: how you adapt by jurisdiction, and how you document those constraints. ¹

Deliverable: Personnel Background Screening Procedure (CDE roles).

3) Build an access gate: “no-screen, no-CDE-access”

Implement a control that prevents provisioning until screening clears:

• Add a required field in the access request ticket: “Screening complete? Yes/No; date; reference ID.”
• Require attachment (or verified reference) before IAM approves membership in CDE access groups.
• If physical access is relevant, require screening status before issuing CDE badge access. ¹

Exception path: define who can approve exceptions (often CISO + HR + compliance), what compensating controls apply (restricted access, supervised access, shorter access duration), and how quickly the screening must be completed under that exception.

Deliverable: Provisioning workflow change + exception workflow.

4) Ensure third-party personnel are covered

If a third party supplies staff who can access your CDE:

• Put screening obligations in the contract/SOW.
• Require proof at onboarding (attestation or evidence, depending on your risk posture and legal constraints).
• Make “no proof, no access” enforceable in your provisioning process. ¹

Deliverable: Contract clause + onboarding checklist for third-party personnel.

5) Retain evidence in a way an assessor can test

Background screening often fails audits because evidence is scattered between HR systems and access tickets. Fix this by tying screening proof to the access decision:

• In the access ticket: store adjudication status and a reference to the screening record.
• In the screening record: store the role requested and whether it includes CDE access.
• In exceptions: store approvals, duration, compensating controls, and closure. ¹

Where Daydream fits: Daydream can act as the system of record that links “person in role” → “screening evidence” → “access approvals” → “exceptions,” so you can answer QSA sampling requests without stitching artifacts together across HR, ITSM, and IAM.

---

Required evidence and artifacts to retain

Keep artifacts that prove design and operation:

Policy/procedure (design evidence)

• Personnel background screening procedure for CDE-access roles ¹
• Defined adjudication criteria and documented local-law constraints ¹
• Exception procedure with approvers and compensating controls ¹

Operational evidence (execution evidence)

• Completed screening results or screening completion confirmations for sampled personnel ¹
• Access requests and approvals showing CDE access granted only after screening completion ¹
• Exception records, including rationale, approvals, and closure evidence ¹
• Third-party attestations or evidence that third-party personnel with CDE access were screened ¹

Retention approach: align to your HR and security record retention rules, but ensure you can produce a coherent “story” for each sampled person: requested access → screening completed → access granted (or exception approved).

---

Common exam/audit questions and hangups

Assessors typically probe these areas ¹:

1. Scope clarity: “Show me the list of roles with CDE access and how you determined it.”
2. Timing: “Prove screening happened before hire and before access was granted.”
3. Completeness: “Do contractors and third-party staff follow the same standard?”
4. Local law: “Which locations limit screening, and what do you do instead?”
5. Exceptions: “How many exceptions exist, who approved them, and when were they closed?”
6. Sampling readiness: “Provide evidence for a sample of personnel with CDE access.”

Hangup to anticipate: HR may treat screening as confidential and resist sharing details. Solve this with a compliance-friendly evidence format (completion status, date, adjudication outcome, reference ID) that avoids over-collection but still proves control operation.

---

Frequent implementation mistakes (and how to avoid them)

Mistake: Screening is HR-only and disconnected from access provisioning

Fix: Make screening status a mandatory input to IAM/ITSM provisioning, and block CDE access until satisfied. ¹

Mistake: Job title-based scoping

People with non-obvious titles often hold admin rights.
Fix: Scope by access paths (groups, systems, physical zones), then map to roles.

Mistake: Contractors and third-party staff are excluded

Fix: Contractually require screening and enforce it operationally with the same access gate. ¹

Mistake: “Local laws” becomes a blanket excuse with no documentation

Fix: Maintain a jurisdiction-by-jurisdiction matrix listing constraints and the alternative checks you perform, reviewed by HR/legal.

Mistake: No exception discipline

Fix: Time-bound exceptions, require named approvers, and document compensating controls and closure.

---

Risk implications (why assessors care)

Background screening is a preventive control against insider threats and credential misuse by people who can reach systems handling payment card data. When it is poorly designed or not evidenced, inappropriate access can persist and access decisions become hard to justify during PCI DSS scoping, assessor testing, and remediation follow-up. ¹

---

Practical execution plan (30/60/90)

First 30 days (Immediate)

• Confirm CDE scope and enumerate CDE access paths (systems, groups, badges). ²
• Define the “CDE Access Population” and owners (HR, IAM, compliance).
• Draft/update the screening procedure and exception workflow. ¹
• Add a screening-status field to access requests for CDE roles and start collecting evidence.

Days 31–60 (Near-term)

• Implement hard gating in IAM/ITSM for CDE access (approval cannot complete without screening proof). ¹
• Update third-party onboarding and contracts/SOWs for personnel screening where third-party staff can access the CDE. ¹
• Build the local-law constraints matrix with HR/legal input and document the alternate checks.

Days 61–90 (Operationalize and test)

• Run an internal audit-style sample: pick recent hires/contractors with CDE access and prove end-to-end evidence.
• Remediate gaps (missing tickets, unclear adjudication, exceptions without closure).
• Centralize evidence mapping in a system like Daydream so you can respond to QSA requests with a single export: people, roles, screening status, access grant date, and exceptions. ¹

---

Reference frameworks (for alignment, not extra requirements)

• PCI DSS 4.0.1 Requirement 12.7.1 is the controlling requirement for this page. ¹
• PCI DSS scoping expectations inform how you define who has CDE access. ²
• PCI SSC publications can be used to track updates and interpret changes in versions. ³

Frequently Asked Questions

Does PCI DSS require re-screening existing employees annually?

Requirement 12.7.1 specifies screening prior to hire for personnel who will have access to the CDE. ¹ If you choose periodic re-screening as a risk decision, document it as your standard, but treat it as above-baseline.

What counts as “access to the CDE” for background screening scope?

Treat access as any logical or physical ability to reach CDE systems or administer controls that protect them. Document the access paths (groups, systems, badge zones) and map people to them for audit-ready scope. ¹

Can we grant access on day one if the screening is “in progress”?

The requirement is prior to hire and is meant to reduce internal risk. ¹ If business constraints force exceptions, require explicit approval, apply compensating controls, and close the exception once screening completes.

How do we handle jurisdictions where certain checks are restricted?

Build a location-based matrix of what checks are allowed, what you run instead, and who approved the approach. The requirement explicitly allows constraints of local laws, but you must be able to show you respected those constraints and still screened. ¹

Do third-party contractors provided by a staffing firm need to be screened by us?

PCI DSS places the obligation on your organization to ensure potential personnel with CDE access are screened. ¹ You can accept third-party screening evidence or attestations where appropriate, but enforce “no evidence, no access.”

What evidence is usually sufficient for a QSA without exposing sensitive HR data?

Provide completion status, date completed, adjudication outcome (pass/fail/approved-with-conditions), and a reference ID that ties back to the screening provider record. Pair it with the access request showing CDE access was granted only after completion (or an approved exception). ¹

Footnotes

1. PCI DSS v4.0.1 Requirement 12.7.1

2. PCI DSS v4.0.1

3. Just Published: PCI DSS v4.0.1