12.7 Personnel screening: requirements and evidence

PCI DSS 12.7 personnel screening: what the requirement asks before anyone gets CDE access

Requirement 12.7.1 asks you to screen potential personnel who will have access to the cardholder data environment (CDE) before you hire them, within the limits of local law. The insider risk it addresses is simple to state: someone with legitimate access to card data, or to the systems that protect it, can do more damage than an outside attacker who must first get past your controls. Screening is meant to reduce that risk before the person ever holds a credential. For a compliance lead or hiring manager, the practical question is not whether screening happens in principle but whether you can show, for each candidate in a CDE role, that it was completed before the start date and recorded in a form an assessor can review.

Most of the work is HR process and records rather than technology. The hard parts are usually organizational. Role definitions are often inconsistent, so one team treats a database administrator as in scope while another does not treat a support engineer with console access that way. Local law limits what can be checked, what candidates must consent to and how long results may be kept, and those limits differ by jurisdiction and sometimes by role. The most common failure at audit time is not a missing screen but a screening record that HR cannot retrieve quickly, cannot tie to a specific hire, or cannot show was completed before access began. Confirm with your legal and HR teams which checks are lawful in each location before you write the procedure.

The SAQ D guidance notes that screening is only a recommendation for roles such as store cashiers who access one card number at a time during a transaction, so the first decision is role scoping. Ask HR and the CDE owner to produce a written list of roles with CDE access, then check it against your current system inventory and access records, including contractors and temporary staff. Then decide which roles fall under the requirement and document the reasoning, because an assessor will test the list against the access you actually granted. Your assessor will likely interview responsible HR personnel about the process, so the people who run screening should be able to explain it without preparation.

Which roles and people fall under 12.7.1

Requirement 12.7.1 applies to potential personnel who will have access to the cardholder data environment, so the first job is deciding who that group is. The decisions below change how wide the screening net runs, and each one should be recorded in your own documentation before you draft screening procedures.

Direct and administrative CDE access

Start with people who can read, change or administer systems that store, process or transmit account data, including database administrators, payment application developers with production access, and anyone holding privileged accounts on CDE hosts. Ask whether the role could view or alter card data, or disable the controls that protect it. If yes, the role is in scope for screening before hire without exception. Confirm the list against your access reviews and identity directory, not only against job titles.

Indirect CDE access

Some roles touch the CDE without touching card data directly, such as network engineers who manage firewalls on the CDE boundary or staff who can reach CDE segments through shared jump hosts. Ask whether a person could reach the CDE, change its configuration, or affect its security if they acted maliciously. Access that is technically possible but never granted in practice still deserves a documented decision, because the standard speaks to access the role will have.

Contractors and temporary staff

Contractors, agency workers and temporary staff who will work in or on the CDE are potential personnel in your environment even when a third party employs them. Ask who hires, screens and holds the contract, and whether your contract requires that screening. Third-party personnel are usually governed through the third-party management requirement, Requirement 12.8, but you must still state in your own records which external individuals fall inside your CDE boundary.

Shared support functions

IT operations, help desk and desktop support staff often sit outside the CDE on paper but reset passwords, push patches, or open remote sessions into CDE systems. Ask whether any support path leads into the CDE and who can trigger it. Help desk roles with password reset rights over CDE accounts are a common gap, because they carry access without appearing in the payment team's roster. Include them if the path exists, even when the role is organizationally separate.

Roles with recommendation-only screening

The SAQ D note to 12.7.1 describes screening as only a recommendation for roles such as store cashiers who access one card number at a time during a transaction. Ask whether the role's access is limited to a single transaction at a time with no broader system or data access. If so, you may document it as a recommendation rather than a mandatory screen. Record the reasoning, confirm it with your assessor or acquirer where the answer is uncertain, and revisit the decision when the role's access changes.

How an assessor tests 12.7.1 and what they ask to see

This table compares what an assessor does for 12.7.1, the evidence they request and the findings that come up most often. Read each row as a step in the assessment, and use the evidence column to prepare files before the assessor asks. The main takeaway is that the screening rules must be written down and traceable to individual hires.

Test area	Test approach	Evidence requested	Common findings
Screening process interview	Assessor interviews responsible human resources personnel about how screening is requested, performed and recorded before hire	Written screening procedure, named owners, description of who triggers checks	Process known informally, no written procedure, HR and security describe different steps
Defined CDE-access roles	Assessor confirms which roles were defined as having access to the CDE and checks the list against access records	Current list of CDE-access roles, approval record, mapping to system access groups	Role list undefined or outdated, contractors or temporary staff missing from the list
Sample of recent hires	Assessor selects recent hires in CDE-access roles and traces each to a completed screening record	Hire roster for the sample period, screening report or vendor confirmation per hire	Screening record cannot be found for one or more sampled hires
Timing against hire date	Assessor compares screening completion dates with the hire or access grant date for each sampled person	Screening completion dates, offer and start dates, access provisioning tickets	Screening recorded after the start date or after access was granted
Local law limits	Assessor checks how legal restrictions on screening were identified and handled for each jurisdiction	Legal review memo, jurisdiction-specific screening scope, documented alternatives used	No legal review on file, or restrictions applied without a written rationale
Screening not performed	Assessor checks whether any exceptions exist and whether each has a documented reason and approval	Exception log with reasons, approvals and risk acceptance where applicable	Missing exception record, or a reason that does not tie to a legal or role-based basis
Third-party personnel	Assessor checks whether screening obligations were passed to providers who supply staff with CDE access	Contract clauses, provider attestations, records of provider screening for named staff	Provider staff with CDE access assumed screened without any written confirmation

How to implement 12.7.1 in six steps

This sequence turns the screening expectation in Requirement 12.7.1 into a documented process that HR, legal and identity administration run the same way every time. At the end, you can show an assessor which roles were screened, under which lawful checks, and that no one reached the cardholder data environment without a recorded result.

Define CDE-access roles with HR and the CISO
Start by listing every role that will have access to the cardholder data environment, including administrators, developers with production access, support staff, and contractors. HR and the CISO agree on the list together, and each role is tied to the systems or access groups it can reach. The output is a role register that names each role, its CDE access path, and its owner. The step is done when the CISO and HR head have signed the register and every CDE group in your identity system maps to a listed role.
Document local legal limits with counsel
Requirement 12.7.1 applies only within the constraints of local law, so counsel must state in writing which screening types are permitted for each role and jurisdiction. Cover background checks, reference checks, identity verification, and any restrictions on criminal record or credit history checks. The output is a legal memo that lists permitted and prohibited checks per role category and per country where you hire. The step is done when counsel has reviewed and dated the memo and HR has confirmed it matches current practice.
Select checks the organization can lawfully run
Using the legal memo, choose the screening checks you will apply to each role category. Assign checks to roles rather than applying one package to everyone, and record which provider or internal team performs each check. Where a check is not lawful for a role, document the alternative. The output is a screening matrix that links each role to its checks, its performing party, and its legal basis. The step is done when every role in the register has at least one assigned check or a documented reason why none applies.
Write the screening procedure and decision criteria
Write a procedure that tells HR how to start screening, how candidate consent is captured, how results are reviewed, and who makes the hire decision. Define the criteria that lead to approval, rejection, or escalation to the CISO, and state how results are stored and for how long local law allows. The output is an approved screening procedure with a decision record template. The step is done when the procedure is published to HR and hiring managers, and a sample completed decision record exists for a hypothetical candidate (illustrative).
Tie screening results to identity provisioning
Configure your identity lifecycle so that a user joins a CDE group only after HR records a passed screening result for that role. In practice this means the identity provider or directory draws group membership from an HR-approved attribute, not from a manual request alone. Identity tools such as authentik's SCIM provider can push group creations, changes and removals to target applications and deprovision users when they lose access, so the provisioning rule can drive removal as well as grant. Confirm the exact attribute flow with your own identity team before relying on it. The output is a written provisioning rule and a test record showing a blocked user and an approved user. The step is done when a screening-pending user cannot receive CDE group membership in your test environment.
Set up the evidence register and annual review
Build an evidence register that links each CDE-access user to the role, the legal memo version, the screening record reference, and the approval date, without storing unnecessary personal data. Schedule a yearly review in which HR and the CISO confirm the role register, legal memo, and procedure still match current roles and law. The output is the evidence register plus a review record with its sign-off. The step is done when an assessor interview with HR can be answered by pulling one register entry for any CDE user, and the first annual review is on the calendar.

Which evidence passes a 12.7.1 test

An assessor testing 12.7.1 looks for proof that screening happens before hire and that the organization can show it for each person with CDE access. The cards below cover the records that tie a role, a screening decision, an access grant and any exception together so a sample can be traced from end to end.

CDE role register

This is the list of roles and named positions that give access to the cardholder data environment, maintained by HR and security together. It defines who falls under 12.7.1 in the first place, so the screening population is not decided by memory. Review it when job descriptions change, when projects add new administrators, and at least once a year. Assessors usually take a sample of hires and check that each one appears on the register. Confirm that contractors and temporary staff with CDE access are listed too, since they are often missed.

Written screening policy and procedure

The policy states what screening covers, which roles it applies to, who performs it, and how results are judged. The procedure sets the steps, the order relative to the offer and start date, and the escalation path for adverse findings. Owned by HR with input from legal and security, it should be reviewed on a schedule and whenever local law changes. An assessor will compare the text against what HR actually does, so a policy that promises checks the team does not run will fail the interview. The interview expected for 12.7.1 is with HR management, so those staff should be able to explain it directly.

Screening record per candidate

Each candidate for a CDE role needs a record showing the check performed, the date it was completed, the outcome, and the person who recorded it. The date must fall before the hire or access start date, which is the point an assessor checks first. Keep the record in the HR system or a restricted file, and limit what it contains to what the law allows the organization to hold. Sample a few recent hires from the register and confirm each has a dated, signed outcome before their start date.

Legal basis for local law limits

Because 12.7.1 applies only within the constraints of local law, the organization must document what the law allows in each jurisdiction where CDE staff work. This record is written with counsel and names the checks that are permitted, the checks that are restricted, and any consent or notice steps required. It is the evidence that explains why a screening step was skipped or changed for a given person. Review it when the company hires in a new country or when local rules change. Assessors will ask for it when they see gaps in the screening records, so keep it separate from the general policy and dated.

Screening outcome linked to account creation

Screening only reduces insider risk if a failed or incomplete check actually stops access. The identity system should create CDE accounts only after the screening outcome is recorded as passed. In a self-hosted setup, an identity provider such as authentik can provision accounts into target applications over SCIM 2.0, and it deprovisions users when they lose access, so offboarding and access removal can follow the same source of truth. Note that such a tool moves accounts; the screening decision still comes from HR. Confirm the approval step exists and test it with a sample candidate.

Exception approval records

Where screening was not completed before access was granted, or where a local law limit meant a standard check was not run, the organization should hold a signed exception. The record names the person, the role, the reason, the compensating steps such as tighter monitoring or supervised access, the approver, and an end date for the exception. Exceptions should be rare and reviewed by a named owner, often the CISO and HR lead together. Assessors look for exceptions that never expire or that were approved after access began. Keep the log current between audits so every exception can be traced to a decision.

What meeting 12.7.1 costs in money and effort

This table breaks down what screening potential CDE personnel costs, who is paid for each part, and whether the cost is one-time or recurring. Read it as a checklist for requesting quotes, since no figures are published here and most costs depend on your hiring volume, jurisdictions and existing directory tools. The main takeaway is that screening fees and legal review are paid to outside parties, while open-source identity tools reduce directory license spend but not screening fees.

Cost component	One-time or recurring	What drives it	How to keep it down
Legal review of local law limits	One-time, revisited when laws or hiring countries change	Number of jurisdictions, types of checks permitted, and rules on criminal history, credit and consent	Ask counsel for a single written memo per jurisdiction and reuse it across roles with the same rules
HR process design	One-time, with periodic updates	Number of role types with CDE access, whether screening is set by role, and how HR and hiring managers split tasks	Define a small set of role categories and a standard checklist instead of case-by-case rules
Screening service fees paid to background check providers	Recurring, per candidate or per check	Check types per role, international checks, re-screening rules, and provider contract terms	Screen only roles that need CDE access and request volume-based pricing with a written check list
Identity provisioning changes	One-time build, then recurring maintenance	Whether access is granted only after screening clears, and how many systems receive user accounts	Use a central identity provider with automated group provisioning so access follows the screening status
Evidence upkeep for each hire	Recurring, per hire	Records retained per candidate, consent forms, and links between screening results and access grants	Store a single screening record per hire with a date and approver, and link it to the access ticket
Assessor sampling effort	Recurring, each assessment cycle	Number of hires sampled, how many roles are in scope, and the quality of the records available	Keep records indexed by hire date so the assessor can pull a sample without manual searching
External review of HR and legal processes	Optional, periodic	Complexity of local laws, prior findings, and whether counsel reviews the final process	Limit external review to the jurisdictions and roles that carry the most legal risk
Directory and identity tool licenses	Recurring, if commercial directory products are in use	Number of users, directory features needed, and vendor licensing model	Self-hosted open-source directories such as FreeIPA or authentik can reduce license spend, though screening fees stay the same

How self-hosted identity tools can support 12.7.1 evidence

The two open-source tools below manage access to systems in the cardholder data environment. They do not perform screening, but they can record who holds CDE access and when that access ends, which gives an assessor records to test alongside 12.7.1 interviews with HR.

authentik SCIM provisioning

The authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0. You can make a CDE group the gate for a target application, so group membership decides who receives an account there. A full sync runs every hour, so a change in the identity source reaches the target within that window. Confirm which of your applications accept SCIM 2.0 and which need a manual process.

Deprovisioning as a revocation record

authentik deprovisions users from the target when they lose access to the application. Removing someone from the CDE group therefore changes the target account, and if your team keeps the sync and audit logs, produces a dated trail an assessor can sample. For 12.7.1, this trail shows that access ended. It does not show that a person was screened. Ask the vendor and your administrators what each log retains and for how long before you rely on it.

FreeIPA as the identity directory

389 Directory Server, the directory behind FreeIPA, stores users, groups, hosts and other network objects as a multi-master LDAPv3 directory. Centralized access control and delegated administration, through the web UI and command line tools, let you decide which staff may add or remove people from CDE groups. This can give you one authoritative record of who holds CDE access. Confirm the replication topology and delegation model with your architects before you design around them.

Screening stays with HR

Neither authentik nor FreeIPA performs screening, background checks or identity verification before hire. That work stays with your HR function and any screening provider you engage, within local law. Your team must confirm how the HR system passes a new hire's approval to the identity tool, whether by ticket, scheduled export or an integration built for your environment. Without that handoff, the directory cannot show that screening came before access was granted.

License duties before modification

FreeIPA is licensed under GPL-3.0-or-later, and authentik is licensed under MIT. The GPL carries obligations when you modify and distribute covered code, which can apply to custom connectors or patches your team builds for HR integration. Check with counsel before you modify or distribute either project. Keeping integration code in separate components makes those duties easier to scope and document.

Who does what for 12.7.1: your team, a partner and the assessor

Your organization owns the control. Requirement 12.7.1 expects potential personnel who will have access to the cardholder data environment (CDE) to be screened before hire, within the limits of local law. That work sits with people inside the business, and no partner or assessor takes it over.

HR owns the screening process and records: HR defines which checks apply to which roles, runs or contracts the checks, and keeps the records the assessor will ask to see.
Legal owns the local law limits: Legal confirms which checks are permitted in each jurisdiction, what candidates must consent to, and how results may be stored and used.
The CISO owns the CDE role register: The CISO or delegate maintains the list of roles that access the CDE, so HR knows which candidates fall under the requirement.
Managers confirm role changes: When an internal transfer gives someone CDE access, the same screening expectation applies, and that trigger should be written into the process.

Ask your HR and legal teams to confirm the local rules with counsel before the process is documented, since the requirement itself defers to local law.

Where organizations fall short on 12.7.1 and how to close each gap

Most screening failures are not refusals to screen. They come from missing role lists, late checks and records that drift from who actually holds CDE access. Each card names one gap, the action that closes it and the evidence an assessor can inspect.

No written list of CDE-access roles

Without a defined list of roles that can reach the cardholder data environment, screening is applied by habit and misses people. Build the list from access groups, administrator roles, jump hosts and support accounts, then decide which roles fall under 12.7.1. Evidence: a dated role register tied to the CDE system component inventory, approved by HR and the security owner. Confirm the list covers contractors and privileged service roles, not only employees.

Screening recorded after start dates

The requirement expects screening before a person is hired into a CDE-access role, so a check completed after the first day of access is a gap even if it later comes back clean. Make background screening a gate in the offer and onboarding workflow, and block CDE group membership until the result is recorded. Evidence: onboarding tickets showing the screening completion date earlier than the access grant date.

Screening done but not documented for every role

Teams often screen senior staff reliably and let contractors, temporary staff or internal transfers slip through without a record. Assessors interview HR about the process, so inconsistent practice is visible quickly. Keep one screening register that lists each candidate, role, check type, date and outcome, and include transfers into CDE roles. Evidence: the register sampled against the access roster with no unmatched names.

Local law limits assumed, not documented

The requirement applies screening within the constraints of local law, and many organizations assume those limits without writing them down. Ask counsel or HR to record, by country and role, which checks are permitted, which are restricted and what consent is required. Evidence: a signed legal memo or jurisdictional table referenced in the screening policy, reviewed when hiring locations change.

Accounts created before screening results are recorded

Identity systems often create a CDE account during provisioning, days before HR closes the screening file, which leaves access in place without evidence of screening. Tie account creation to a screening status attribute so that the account remains disabled until the result is recorded. In authentik, for example, provisioning to a target application through the SCIM provider can be paused by group membership until the screening flag is set (illustrative). Evidence: identity audit logs showing screening status set before the account was enabled.

No recurring check against CDE membership

People move roles, gain access through groups and leave, so a screening record that was accurate at hire can drift from current membership. Run a scheduled reconciliation that compares CDE group members with the screening register and flags anyone without a completed record. Evidence: dated reconciliation reports with exceptions resolved and signed by the owner. Confirm the frequency with your QSA, since the requirement does not set one for this check.

Questions buyers ask about 12.7.1 cost, effort and outside help

How much effort does a personnel screening program take to run?

The effort depends mostly on how many roles reach the cardholder data environment (CDE) and how often people change jobs. Requirement 12.7.1 applies to potential personnel who will have access to the CDE, so the first task is a role list that separates people with CDE access from those without. Each in-scope role then needs a defined screening step before the offer is confirmed, and the steps must be repeatable for every hire. Recurring effort comes from new hires, contractors and internal transfers into CDE roles. Ask any provider to break the work into one-time design (policy wording, role mapping, process flow) and recurring work (screening each candidate, keeping records, reviewing role changes), and to state who performs each part.

Can an organization meet 12.7.1 without an outside partner?

Yes. The organization owns its personnel process, and 12.7.1 does not require a third party to run screening. Most teams handle it with their existing HR process, a documented screening standard, and a list of CDE roles. Outside help is usually useful for the technical side, such as building the role list from identity records and keeping access aligned with the hiring decision. A partner can prepare evidence, but it cannot replace HR or legal decisions about which checks are lawful in each jurisdiction. Your assessor, a Qualified Security Assessor (QSA), will test the process directly, so the work must be documented in a form the team can explain.

How long does setup take, and what sets the timeline?

No setup duration is supplied for this requirement, so treat any figure you hear as unverified until it appears in a written scope. The timeline is driven by the number of CDE roles, whether screening processes already exist, how many jurisdictions apply, and how much identity data must be linked to access records. Teams with a documented hiring process and clear CDE roles usually need less design work than teams that must define both from the start. Fixed-scope engagements with DeployOpen are agreed in writing before work starts, so ask for the timeline, deliverables and assumptions in that written scope rather than relying on a general estimate.

What does the work need from HR and legal?

HR and legal own the decisions that make screening lawful and consistent. HR defines which roles count as CDE access, which checks apply to each role, and how candidates are informed and asked for consent where the local law requires it. Legal confirms what checks are permitted in each jurisdiction, how long records are kept, and how candidate data is handled under privacy rules. The requirement itself makes screening subject to local law, so the policy must state those limits clearly. Before work starts, ask your provider which HR and legal sign-offs the scope assumes, and who holds the final approval for each screening step.

Can a partner run the screening checks for us?

A partner can design, build and document the screening process and the systems that support it, but the decision to hire a person stays with the organization. Background checks are usually carried out through a licensed screening provider or internal HR, and that provider's contract, data handling and legal basis must be reviewed by your legal team. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so it does not run background checks on candidates. If your model involves an external screening company, treat it as a third party under your third-party risk process and confirm its duties in writing.

How does the assessor test personnel screening evidence?

The assessor interviews the responsible human resources personnel and reviews how screening is applied before people gain CDE access. The assessor does not accept a certificate as validation. Evidence usually includes a documented screening procedure, the list of roles treated as CDE access, examples of completed screening records that show the step occurred before access was granted, and the handling of cases where local law limits a check. Access records from your identity system can help show that CDE access followed the screening decision. Only the independent QSA issues the assessment report, so ask your partner to prepare the evidence while the assessor decides whether it meets the requirement.

How DeployOpen scopes and prepares 12.7.1 evidence

DeployOpen does not screen people or decide which roles need screening. Your HR and legal teams own that process. DeployOpen works on the systems side: it helps define which accounts reach the CDE, connects the identity and access records that show who was onboarded, and prepares the documentation an assessor will ask to see for 12.7.1.

How we scope

Our written scope lists which roles and account types reach the CDE, so HR knows which hires fall under 12.7.1.
We map where access to CDE systems is granted, including directories, identity providers and privileged administration tools.
Scope also records which roles your legal counsel has confirmed as screenable within local law, and which are not.

How we build

We configure identity records so a CDE account can be traced to an HR-approved onboarding record before access is granted.
Where open-source identity tools are used, such as authentik's SCIM provider or FreeIPA, we set up account creation and removal so access follows the approved onboarding path.
We test that accounts without a completed onboarding record cannot be created in the CDE, and document the results.

How we hand over

You receive a written map of the onboarding-to-access workflow, with owners named for HR, security and system administration.
Handover includes test records, configuration exports and a short guide for showing an assessor the sequence from screening to access.
Your HR team receives a checklist of the questions an assessor is likely to ask in the interview for 12.7.1, so they can answer from records.

How we support

Ongoing support is available as a retainer for changes to identity configuration, new CDE roles and updates to the onboarding workflow.
Before each assessment, we can review whether account records still match the approved scope and flag gaps for your team.
Confirm with your QSA which evidence they accept for 12.7.1 before work starts, since assessors decide what satisfies the requirement.