Personnel Physical Access Authorization

To meet the personnel physical access authorization requirement in PCI DSS 4.0.1, you must run a documented process that identifies who is allowed into the Cardholder Data Environment (CDE), approves access based on job need, updates access when roles change, and revokes access immediately at termination. You also must enforce “authorized-only” entry to CDE spaces. (PCI DSS v4.0.1 Requirement 9.3.1)

Key takeaways:

• You need a closed-loop access lifecycle for CDE physical entry: request, approve, provision, review/modify, revoke.
• “Immediately upon termination” is an operational dependency between HR and facilities/security; treat it like an incident-level SLA. (PCI DSS v4.0.1 Requirement 9.3.1)
• Evidence matters as much as controls: auditors will ask for lists, approvals, revocation proof, and logs tied to specific people and dates. (PCI DSS v4.0.1 Requirement 9.3.1)

Personnel physical access authorization is a basic control with outsized audit impact because it intersects multiple teams (facilities, security, IT, HR, and CDE operations) and often relies on legacy badge systems. Requirement 9.3.1 in PCI DSS 4.0.1 is straightforward on paper: only authorized personnel may physically access the CDE, and you need procedures to authorize, manage changes, identify personnel, and revoke access immediately at termination. (PCI DSS v4.0.1 Requirement 9.3.1)

Operationally, most gaps come from handoffs. HR terminates someone, but the badge remains active. A contractor’s engagement ends, but the facilities team never receives the offboarding ticket. Or “temporary” visitor access becomes effectively permanent because no one reviews badge entitlements against current job needs.

This page is written for a Compliance Officer, CCO, or GRC lead who needs to turn the requirement into a working, auditable process. The goal is simple: you can point an assessor to your procedure, show consistent execution, and produce clean evidence for a sample of hires, transfers, and terminations without scrambling across inboxes and spreadsheets.

Regulatory text

PCI DSS 4.0.1 Requirement 9.3.1 requires that “procedures are implemented for authorizing and managing physical access of personnel to the CDE, including identifying personnel, managing changes to individual access requirements, revoking or terminating access immediately upon termination, and limiting physical access to the CDE to only those personnel authorized.” (PCI DSS v4.0.1 Requirement 9.3.1)

Operator interpretation (what this means in practice):

• You must have a written procedure (not tribal knowledge) describing how people get CDE physical access and how it is controlled. (PCI DSS v4.0.1 Requirement 9.3.1)
• You must be able to identify who has access (names/unique IDs), not just “badge group A.” (PCI DSS v4.0.1 Requirement 9.3.1)
• You must manage change: role changes, team moves, location changes, and contractor end dates must trigger updates to physical access. (PCI DSS v4.0.1 Requirement 9.3.1)
• You must revoke immediately upon termination; this includes employees and third-party personnel with badges or keys. (PCI DSS v4.0.1 Requirement 9.3.1)
• You must limit entry to authorized personnel only via door controls, staffed checkpoints, or equivalent mechanisms for the CDE boundary. (PCI DSS v4.0.1 Requirement 9.3.1)

Plain-English requirement (one sentence)

Only specifically approved, identifiable people can physically enter the CDE, and you must promptly remove access when their need ends or employment/engagement terminates. (PCI DSS v4.0.1 Requirement 9.3.1)

Who it applies to

Entity scope: Merchants, service providers, and payment processors with CDE facilities or spaces. (PCI DSS v4.0.1 Requirement 9.3.1)

Operational scope (where this bites):

• On-prem data centers, server rooms, network closets, and cages that contain CDE systems.
• Office areas that include CDE workstations, secure print rooms, or card data handling operations.
• Colocation spaces where your organization controls physical access lists (even if the building is managed by a third party).
• Third parties on-site (facilities contractors, hardware vendors, auditors, cleaners) who could reach the CDE boundary.

Key scoping decision you must document: what constitutes the CDE physical boundary (doors, cages, mantraps, reception checkpoints) and which access systems control it. This boundary definition drives your access list, your logs, and your evidence set.

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

1) Define the CDE physical boundary and access methods

• Produce a simple boundary description: doors, cages, rooms, badge readers, locks, and any staffed entry points.
• Map each boundary point to a control method (badge system, keyed lock, guard desk process).
• Decide which systems are “systems of record” for access (e.g., the badge platform plus a key cabinet log).

Deliverable: CDE Physical Access Boundary Description (1–2 pages) tied to your PCI scope narrative.

2) Establish an authorization model (who can approve, and based on what)

• Set approval roles: typically CDE owner (business), facilities/security admin (provisioner), and compliance/security (oversight).
• Define approval criteria: job function, documented need, and location. Keep it simple and enforceable.
• Require identity proofing for badge issuance (badge photo, unique ID, link to HR identity).

Control objective: Access is intentional and attributable to a person. (PCI DSS v4.0.1 Requirement 9.3.1)

3) Implement an access request and provisioning workflow

Minimum workflow states you need:

1. Request submitted (person, reason, CDE area requested, start date, end date if temporary).
2. Approval captured (who approved, date/time).
3. Provisioned (badge ID, access group/door list, effective date).
4. Confirmation (requester notified; record retained).

If you don’t have a ticketing workflow today, start with a controlled mailbox plus a standard form, then migrate to a workflow tool. If you use Daydream for compliance operations, set up an intake template and evidence tasks so every CDE access grant automatically creates an audit-ready record and a retention trail.

4) Manage changes to access requirements (transfers, role changes, location moves)

You need a trigger that detects change. Common triggers:

• HR job change feed
• Manager-submitted access change ticket
• Contractor engagement change notice from procurement or the third party sponsor

Operational rule: changes must be processed as access modifications, not net-new grants. That allows you to show you removed unnecessary doors/areas, not just added more.

Deliverable: Access Change Procedure with clear responsibility assignments (manager vs HR vs facilities vs security). (PCI DSS v4.0.1 Requirement 9.3.1)

5) Revoke access immediately upon termination (employee and third party)

This is the highest-risk part of the requirement. Build it like a “must-work” control:

• Define termination events: involuntary termination, voluntary resignation, end of contract, badge reported lost with separation suspected.
• Establish the notification channel from HR (and from the third party sponsor for contractors).
• Facilities/security disables the badge and retrieves physical credentials when possible (badges, keys).
• Record the timestamp of termination notice and the timestamp access was disabled.

What auditors look for is not your intent; they look for proof that you consistently revoke without delay. (PCI DSS v4.0.1 Requirement 9.3.1)

6) Enforce “authorized-only” entry at the CDE boundary

Authorization is meaningless if tailgating is common or doors are propped open.

• Configure doors so they require authenticated entry (badge, biometric, or equivalent) where feasible.
• If you rely on a guard desk, document the guard’s verification steps and escalation path.
• Post “no tailgating” signage and include it in security awareness for CDE personnel.
• Investigate exceptions: door forced open alarms, repeated invalid badge attempts, recurring escort failures.

7) Build routine oversight (so the process stays true)

PCI DSS 9.3.1 does not prescribe a specific review frequency in the excerpt provided, but you still need operational checks to prevent entitlement drift.

• Run periodic reconciliations: “current CDE badge holders” vs “current staff/contractor roster requiring access.”
• Spot-check terminated personnel against badge system disablement records.
• Track and close exceptions as tickets with documented resolution.

Required evidence and artifacts to retain

Keep evidence tied to specific people and specific dates. A clean evidence package usually includes:

• Procedure: Physical Access Authorization and Management Procedure for CDE. (PCI DSS v4.0.1 Requirement 9.3.1)
• Access request records: completed forms/tickets showing requester, justification, approvals, and provisioning details. (PCI DSS v4.0.1 Requirement 9.3.1)
• Access list: export/report from badge system listing personnel with CDE access (names/IDs) and their access profile. (PCI DSS v4.0.1 Requirement 9.3.1)
• Change records: tickets showing access modified after role/location changes. (PCI DSS v4.0.1 Requirement 9.3.1)
• Termination/offboarding records: HR termination notice (or equivalent), badge disablement confirmation, and (if applicable) returned badge/key log. (PCI DSS v4.0.1 Requirement 9.3.1)
• Physical entry logs: door/badge event logs for CDE entry points, retained per your organization’s retention standard and available for sampling. (PCI DSS v4.0.1 Requirement 9.3.1)
• Exception handling: records for emergency access, lost badge, or temporary access with end dates. (PCI DSS v4.0.1 Requirement 9.3.1)

Common exam/audit questions and hangups

Expect questions like:

• “Show me your procedure for authorizing and managing physical access to the CDE.” (PCI DSS v4.0.1 Requirement 9.3.1)
• “Provide a list of all personnel with CDE physical access, and evidence of approval for a sample.” (PCI DSS v4.0.1 Requirement 9.3.1)
• “For these terminated individuals, show that physical access was revoked immediately.” (PCI DSS v4.0.1 Requirement 9.3.1)
• “How do you identify personnel? Can you map badge IDs to named individuals?” (PCI DSS v4.0.1 Requirement 9.3.1)
• “How do you handle contractors and other third parties? Who sponsors and approves their access?” (PCI DSS v4.0.1 Requirement 9.3.1)

Hangups that stall assessments:

• Multiple badge systems across sites with no consolidated reporting.
• Keyed locks for CDE rooms with informal key sharing and weak logging.
• Visitor processes treated as “out of scope” even though visitors pass the CDE boundary.

Frequent implementation mistakes (and how to avoid them)

1. Group-based access with weak identity mapping
   Fix: ensure every credential maps to a person in a system of record and can be exported as a named list. (PCI DSS v4.0.1 Requirement 9.3.1)

2. Termination revocation depends on manual email chains
   Fix: create a single required termination notification path and a tracked disablement task. Make it auditable with timestamps. (PCI DSS v4.0.1 Requirement 9.3.1)

3. Temporary access without an end date
   Fix: require an end date for non-permanent access and make expiry removal part of the provisioning workflow.

4. No process for role changes
   Fix: treat transfers like terminations plus re-grants. Remove old doors/areas before adding new ones. (PCI DSS v4.0.1 Requirement 9.3.1)

5. CDE boundary is vaguely defined
   Fix: publish a boundary description tied to badge readers/doors. Auditors test what you define.

Risk implications (why operators treat this as a priority)

Physical access is a direct path to compromise of CDE systems through device tampering, rogue hardware installation, theft of media, or direct console access. Requirement 9.3.1 is designed to prevent “ghost access” (people who should not be able to enter) and to ensure the organization can prove control under audit. (PCI DSS v4.0.1 Requirement 9.3.1)

Practical 30/60/90-day execution plan

First 30 days (stabilize and document)

• Define and publish the CDE physical boundary and entry points.
• Inventory all physical access mechanisms (badge systems, keys, guards).
• Draft and approve the physical access authorization procedure aligned to 9.3.1. (PCI DSS v4.0.1 Requirement 9.3.1)
• Pull an initial “who has access” export and reconcile obvious anomalies (terminated personnel, unknown badge owners).

Days 31–60 (operationalize workflows and evidence)

• Implement a standardized access request/approval workflow (ticket or form).
• Implement a standard access change workflow for transfers and contractor changes.
• Implement a termination notification and badge disablement workflow with timestamps.
• Build an evidence folder structure (or in Daydream, an evidence collection mapped to this requirement) so each access event produces retrievable artifacts.

Days 61–90 (prove consistency and close edge cases)

• Run a formal reconciliation between HR roster and CDE access list; open tickets for discrepancies.
• Test “termination to disablement” for recent separations and document results.
• Validate third-party access sponsorship and end-date handling for contractors.
• Run an internal mini-audit: sample access grants, changes, and terminations; confirm you can produce evidence quickly. (PCI DSS v4.0.1 Requirement 9.3.1)

Frequently Asked Questions

Does this requirement apply if our CDE is hosted in a colocation facility?

Yes if your organization authorizes or manages who can physically enter your CDE space (for example, a cage or dedicated room). You still need procedures, named authorization, and revocation on termination. (PCI DSS v4.0.1 Requirement 9.3.1)

Do contractors and other third-party personnel count as “personnel” here?

Yes in practice, because the requirement focuses on “physical access of personnel to the CDE” and limiting access to authorized individuals. Treat third-party badges/keys with the same approval, identification, change, and termination rigor. (PCI DSS v4.0.1 Requirement 9.3.1)

What does “identify personnel” mean for badge systems?

You should be able to map each credential to a unique person (name plus unique identifier) and produce a report of who has CDE access. Shared badges or unassigned credentials create audit and security failures. (PCI DSS v4.0.1 Requirement 9.3.1)

How do we prove access was revoked immediately upon termination?

Keep termination documentation (HR notice or equivalent) and the badge system record showing disablement time. Auditors typically sample multiple terminations and look for a consistent, traceable chain of evidence. (PCI DSS v4.0.1 Requirement 9.3.1)

We use physical keys for a CDE server room. Can we still comply?

You can, but you need a controlled key issuance and retrieval process that identifies key holders, documents approvals, and supports rapid revocation when someone leaves. If keys cannot be effectively revoked, consider upgrading the boundary control. (PCI DSS v4.0.1 Requirement 9.3.1)

What’s the minimum documentation an assessor will expect?

A written procedure, an access list for CDE entry, approval records for a sample of access grants/changes, and termination revocation proof for a sample of leavers. If those artifacts are scattered, centralize them in a system like Daydream so evidence is collected as work happens. (PCI DSS v4.0.1 Requirement 9.3.1)