PCI DSS 9.3.4: Visitor logs are used to maintain a physical record of visitor activity both within
PCI DSS v4.0.1 control 9.3.4: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 9.3.
Requirement 9: Restrict Physical Access to Cardholder Data › Section 9.3
Visitor logs are used to maintain a physical record of visitor activity both within the facility and within sensitive areas, including:
- The visitor’s name and the organization represented.
- The date and time of the visit.
- The name of the personnel authorizing physical access.
- Retaining the log for at least three months, unless otherwise restricted by law.
Summary
Keep a visitor log with who they were, who they were from, when, and who authorised them, and keep it three months.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 9.3.4.a | Examine the visitor logs and interview responsible personnel to verify that visitor logs are used to record physical access to both the facility and sensitive areas. |
| 9.3.4.b | Examine the visitor logs and verify that the logs contain: • The visitor’s name and the organization represented. • The personnel authorizing physical access. • Date and time of visit. |
| 9.3.4.c | Examine visitor log storage locations and interview responsible personnel to verify that the log is retained for at least three months, unless otherwise restricted by law. |
Four elements, and two of them are commonly incomplete. The log must cover both the facility and sensitive areas, which is usually two records rather than one: signing into reception is not the same as entering the data centre, and 9.3.4.a asks about both. And it must record the name of the personnel authorizing physical access, not just who visited, which is the field most sign-in books omit entirely. Retention is at least three months, which is short enough that a paper book is workable and specific enough that "we keep them for a while" is not an answer. 9.3.4.c examines the storage location, so where the log lives matters as much as that it exists.
What to prepare
- The facility visitor log and the sensitive-area log, both covering the retention period.
- The four fields, checked against actual entries rather than the template.
- The storage location and its access control, since visitor logs are personal data.
- Any legal restriction on retention, which the requirement anticipates.
How to implement it
1. Log sensitive-area entry separately. A reception book does not record who went into the server room, and that is the entry the control most wants.
2. Capture the authoriser. It is a named element and the one that turns a visitor log into an access record, since it says who decided this person could be there.
3. Store it securely, because it is personal data. A sign-in book on a counter shows every previous visitor to the next one, which is a privacy problem before it is a compliance one.
4. Check entries, not the form. Templates have all four fields; completed rows frequently do not.
Where this commonly fails
- One reception log offered for both the facility and its sensitive areas.
- The authorising person never recorded.
- An open sign-in book that discloses previous visitors to everyone who signs after them.
- Logs discarded before three months, or kept with no thought about where.
Related controls
Others in section 9.3:
| Control | What it requires |
|---|---|
| 9.3.1 | Procedures are implemented for authorizing and managing physical access of personnel… |
| 9.3.1.1 | Physical access to sensitive areas within the CDE for personnel is controlled… |
| 9.3.2 | Procedures are implemented for authorizing and managing visitor access to the CDE… |
| 9.3.3 | Visitor badges or identification are surrendered or deactivated before visitors leave… |
← 9.3.3 · All controls · 9.4.1 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.