Visitor Access Procedures

PCI DSS 4.0.1 requires you to run a controlled, auditable visitor program for any area that contains or can access the cardholder data environment (CDE): pre-authorize visitors, escort them at all times, issue visible visitor identification that differs from employee IDs, and recover or deactivate badges before they leave or when the badge expires. ¹

Key takeaways:

• Define “visitor” and “CDE area” operationally, then enforce pre-approval, escorting, and visible badging every time. ¹
• Your evidence needs to prove two things: the procedure exists and staff follow it consistently (logs, badge records, and escort verification). ¹
• Badge collection/deactivation is a common gap; build it into the exit process and verify it with reconciliations. ¹

Visitor access is a physical security control with direct impact on CDE confidentiality. PCI DSS doesn’t require you to stop all visitors; it requires you to control them with a repeatable process that prevents unescorted presence, prevents identity confusion (visitor vs. personnel), and prevents “badge drift” where temporary credentials remain active after the visit.

Operationally, this requirement becomes simple once you draw two boundaries: (1) which spaces are “in” scope as CDE or connected/supporting areas, and (2) who counts as a “visitor” (including third-party technicians, auditors, cleaning staff, interview candidates, or anyone without standard personnel access). Then you implement four non-negotiables: authorization before entry, escorting, visible visitor identification, and badge recovery/deactivation at exit or expiry. ¹

CCOs and GRC leads should treat this as a control that fails quietly. A single exception can invalidate the spirit of the program if it becomes the norm. The goal is straightforward: you should be able to show an assessor, with records, that every visitor to the CDE was approved, escorted, visibly identified, and fully offboarded from physical access immediately after the visit. ¹

Regulatory text

PCI DSS 4.0.1 Requirement 9.3.2 states: “Procedures are implemented for authorizing and managing visitor access to the CDE, including visitors are authorized before entering, visitors are escorted at all times, visitors are clearly identified and given a badge or other identification that visibly distinguishes them from personnel, and visitor badges or identification are collected or deactivated before visitors leave the facility or at the date of expiration.” ¹

Operator translation (what you must do):

• You must have documented procedures (not tribal knowledge) for visitor access to any CDE area. ¹
• You must require pre-entry authorization (someone accountable approves). ¹
• You must ensure visitors are escorted at all times while in the CDE. ¹
• You must issue visitor identification that is visible and clearly different from employee/personnel credentials. ¹
• You must recover the badge/ID or deactivate it before the visitor leaves, or at badge expiration. ¹

Plain-English interpretation (what “good” looks like)

A compliant program makes it hard for a visitor to wander, blend in, or keep access after the visit. The procedure should work even during busy periods (deliveries, maintenance windows, peak office traffic) and even when the visitor is a trusted third party.

Assessors usually focus on consistency. If one site, one shift, or one reception desk handles visitors differently, you will struggle to demonstrate “procedures are implemented.” ¹

Who it applies to

Entities: Merchants, service providers, and payment processors that have CDE physical locations or facilities where CDE systems are housed or can be accessed. ¹

Operational context (where this shows up):

• Data centers, server rooms, network closets that contain CDE components
• Office spaces with CDE workstations, call-center floors handling card data, or secured cages
• Co-location footprints where your CDE resides (you still need procedures for your controlled areas and your staff/visitor behavior)
• Third-party visits: HVAC, cabling, fire suppression inspections, ISP work, auditors, and building management tours

If your “CDE” is cloud-only, you may still have a CDE-relevant physical footprint (end-user devices, jump hosts, secure admin rooms). Map the reality of how people access systems that can reach the CDE and treat those areas as CDE-adjacent for visitor control.

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

1) Define scope and roles

1. List CDE areas (rooms, cages, floors) and mark entry points (doors, turnstiles, mantraps).
2. Define “visitor” as any non-personnel individual without standard authorized access for the area. Include third-party technicians and short-term contractors unless they are formally onboarded as personnel with approved access.
3. Assign accountable roles:
   • Authorizer (often the CDE owner, facilities/security lead, or operations manager)
   • Escort (host employee; must stay with visitor)
   • Reception/security (issues badges, checks ID, logs entry/exit)

Deliverable: a short visitor procedure that names these roles and ties them to CDE areas. ¹

2) Implement pre-entry authorization

1. Require an access request (ticket, email approval, calendar invite with approval, or visitor management system workflow).
2. Validate purpose and destination: where they will go, why, and for how long.
3. Confirm host/escort: no host, no entry.
4. Block “walk-ins” for CDE access unless an emergency exception process exists and is documented with after-the-fact approval.

Minimum rule: no visitor enters the CDE without recorded approval. ¹

3) Check-in: identify and badge visibly

At check-in:

1. Verify identity using a government-issued ID or your organization’s defined identity proofing approach.
2. Issue a visitor badge that is:
   • visually distinct from employee badges (color, label, lanyard)
   • time-bound (date or time window)
3. Record entry details in a visitor log:
   • visitor name, organization, reason for visit
   • host/escort name
   • areas authorized
   • check-in time and badge number

Practical tip: make “VISITOR” readable from several feet away. If your badge printer fails, have manual badges available. ¹

4) Escorting rules that survive reality

Escorting “at all times” fails when the rule is vague. Write what escorts must do:

• Visitor stays within line-of-sight (or within the same secured room, based on your environment and procedure).
• No badge sharing; visitor cannot be handed off without explicit transfer to another named escort.
• Prohibit visitors from photographing, plugging devices into networks, or handling media unless approved under a separate process (tie to your broader physical/media controls).

Operationalize it:

• Train hosts that escorting is a responsibility, not a courtesy.
• Add signage at CDE entry points: “Visitors must be escorted.”

Requirement anchor: visitors are escorted at all times in the CDE. ¹

5) Exit controls: collect or deactivate badges

Build a hard stop at exit:

1. Badge return at reception/security, or
2. Badge deactivation in the access control system for time-bound badges, plus a reconciliation that expired badges cannot re-open doors.

Add a daily/weekly control (based on your volume) where security/facilities reconciles:

• badges issued vs. returned
• any exceptions and incident tickets

This is where many programs fail: badges are issued correctly but never recovered, creating a persistent physical access path. ¹

6) Handle exceptions (emergencies, after-hours, multi-tenant sites)

Define a narrow exception process:

• Emergency work may allow accelerated approval, but you still require authorization, escorting, and visible identification.
• After-hours visits require pre-approval plus confirmation that reception/security coverage exists or a documented alternate check-in method exists.
• For multi-tenant buildings or co-location, clarify which party controls lobby access vs. cage/room access, and ensure your procedure covers your controlled boundary.

Required evidence and artifacts to retain

Keep evidence that maps directly to each clause of the requirement. ¹

Procedure and governance

• Visitor access policy/procedure for CDE areas
• Role definitions (who can authorize; who can escort)
• Training/acknowledgment records for reception/security and CDE staff (host/escort expectations)

Operational records

• Visitor logs (electronic or paper) with approvals, escort names, entry/exit times, badge numbers
• Badge issuance records and badge inventory controls (if you print badges)
• Physical access control system data for temporary badges (issuance, activation, deactivation)
• Exception records (emergency access approvals, after-hours access) with approvals and post-visit validation

Verification

• Periodic reconciliation records (issued vs. returned/deactivated)
• Internal audit or control test results (spot checks, walkthroughs)

Tip for operators: align retention to your broader PCI evidence retention approach; keep records long enough to support assessment sampling and trend review.

Common exam/audit questions and hangups

Expect assessors to probe consistency and scope boundaries.

Typical questions

• “Show me the written procedure for visitor access to the CDE.” ¹
• “How do you ensure visitors are authorized before entry? Show approvals for these samples.” ¹
• “How do you enforce escorting at all times? What happens during lunch breaks or shift change?” ¹
• “How do your visitor badges look different from employee badges?” ¹
• “Prove badges are collected or deactivated at exit. Show the reconciliation.” ¹

Hangups

• “Visitor” vs. “contractor”: if contractors roam like employees but are treated like visitors on paper, your process will not match reality.
• Shared spaces: if a hallway leads to a CDE door, define where the procedure starts (usually at the controlled door).
• Escorting language: “available on-site” is not “escorted.”

Frequent implementation mistakes (and how to avoid them)

1. Badge looks like an employee badge. Fix: use a different color/lanyard and add “VISITOR” text. ¹
2. No proof of authorization. Fix: require a ticket/approval artifact linked to the visitor log entry. ¹
3. Escorting collapses during busy ops. Fix: make escort responsibility explicit, train hosts, and empower reception/security to deny entry without an escort present. ¹
4. Badges not returned. Fix: enforce badge return as part of exit, then reconcile issued vs. returned/deactivated. ¹
5. Procedure exists, but sites do their own thing. Fix: standardize the minimum required steps, then allow site-specific add-ons without changing the baseline controls. ¹

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied source catalog. Practically, failures here create a direct path for unauthorized physical access to systems that store, process, or transmit cardholder data, or to network points that can reach those systems. That risk is why assessors treat visitor controls as a “show me” requirement: they will ask for records and test the process in a walkthrough. ¹

Practical execution plan (30/60/90-day)

Time-boxing helps, but exact durations depend on your site count and tooling. Use these phases as a template and scale effort accordingly.

First 30 days (Immediate)

• Confirm CDE physical boundaries and entry points.
• Draft/update the visitor access procedure with the four mandated elements.
• Standardize the visitor badge format to be visibly distinct.
• Implement a single visitor log template and approval capture method.
• Train reception/security and CDE staff on escort expectations and denial-of-entry rules. ¹

Next 60 days (Near-term)

• Roll out the process to all in-scope sites; remove local variations that weaken controls.
• Add badge reconciliation (issued vs. returned/deactivated) and document how exceptions are handled.
• Run a tabletop test: simulate a third-party technician arriving unannounced and validate staff responses.
• Collect evidence from real visits and correct gaps before assessment sampling. ¹

By 90 days (Stabilize and prove)

• Perform a formal control test (sampling visitor entries) and document results and remediations.
• Ensure access control system settings support time-bound visitor badges or rapid deactivation.
• Put the procedure into your policy management and review cycle.
• If you use Daydream to manage compliance workflows, set up an evidence request cadence so facilities/security can attach visitor logs, badge reconciliations, and exception approvals as they occur, instead of scrambling at assessment time. ¹

Frequently Asked Questions

Do auditors count third-party technicians as “visitors”?

If they are not personnel with approved, standard access, treat them as visitors for CDE entry: pre-authorize, escort, issue a distinct badge, and collect/deactivate it at exit. ¹

Can a visitor ever be unescorted if they have a badge?

For CDE areas, the requirement states visitors are escorted at all times. If someone needs unescorted access, onboard them as authorized personnel under your access control process rather than treating them as a visitor. ¹

What counts as “clearly identified” and “visibly distinguishes them from personnel”?

The identification must be visible and obviously different from employee IDs in normal conditions. Most teams do this with different colors, large “VISITOR” text, and distinct lanyards. ¹

We use an electronic visitor system with QR codes on phones. Is that acceptable?

It can be, if the identification is visible and clearly distinguishes visitors from personnel, and you can prove authorization, escorting, and deactivation/expiration handling in records. If staff cannot easily recognize it, add a physical badge. ¹

How do we handle multi-day visitors?

Approve access for specific dates/areas, keep escorting in place, and ensure the badge expires or is deactivated at the approved end date. Reconcile multi-day badges more frequently because they are easier to forget. ¹

What evidence should we show if reception is outsourced to a building management team?

Keep your written procedure, define responsibilities in the contract/SOW where possible, and retain visitor logs and badge deactivation/return evidence for CDE entry. You still need proof the procedure is implemented at your controlled boundary. ¹

Footnotes

1. PCI DSS v4.0.1 Requirement 9.3.2