PCI DSS visitor log requirements (9.3.4): what to record and how long to keep it

What does PCI DSS 9.3.4 actually require?

PCI DSS v4.0.1 (June 2024) states requirement 9.3.4 as: “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.”

Its customized approach objective reads “Records of visitor access that enable the identification of individuals are maintained.”

Four details matter in practice:

• v4.0.1 says “visitor logs”, plural. The June 2024 revision replaced “a visitor log” and added “both”, making clear that the facility and the sensitive areas each need a record (PCI SSC Summary of Changes).
• Date and time are now explicit. In v3.2.1 the control was 9.4.4, which listed only the visitor’s name, the firm represented and the onsite personnel authorising access. Old register templates often still follow that list.
• ”Computer rooms and data centers” became “sensitive areas”. The glossary definition in v4 is wider and now includes rooms housing systems that manage CDE security (see the next section).
• Exit time is good practice, not a hard requirement. The 9.3.4 guidance suggests recording entry and exit times, to confirm visitors left, and ID verification against the name in the log.

PCI DSS v4.0.1 was published on 11 June 2024 and v4.0 was retired on 31 December 2024. The PCI Security Standards Council ran a request for comments on v4.0.1 from 3 June to 20 July 2026 to begin work on the next version. As of October 2026 no new version has been published, so assessments run against v4.0.1.

Facility and sensitive areas: which doors need a visitor log?

The cardholder data environment (CDE) is the people, processes and systems that store, process or transmit card data, plus systems with unrestricted connectivity to them (PCI SSC glossary). Requirement 9.3.4 covers two kinds of place, and most published advice covers only the first.

• The facility. The Requirement 9 overview says facility controls “often exist outside a CDE or sensitive area”, such as a guard desk that identifies, badges and logs visitors in your building or tower lobby.
• Sensitive areas. The glossary defines these as “typically a subset of the CDE”: data centres, server rooms, back-office rooms at retail locations, any area that concentrates card data storage, processing or transmission, and areas housing systems that manage CDE security. It excludes areas with only point-of-sale terminals, such as cashier areas and “call centers where agents are taking payments.”

Two consequences catch Indian teams out:

• A contact centre floor taking card payments is not a sensitive area, but its server room is. The floor is usually still part of the CDE, so the 9.3.2 rules (authorised, escorted, badged) apply there, and the server room needs its own record. An older PCI SSC FAQ on requirement 9.1.1 of earlier versions treated call centres as sensitive areas, so agree the classification with your QSA.
• An employee can be a visitor. The glossary’s definition of visitor includes “personnel that normally do not have access to the subject area.” An HR manager or housekeeping supervisor entering the data hall belongs in its log.

In a multi-tenant tech park, the tower desk keeps one log while a tenant such as a bank’s card operations team runs its own reception and data room. If you rely on a landlord’s or colocation provider’s log, requirement 12.8.5 asks you to record which requirements each provider manages, which you manage, and which are shared.

Visitor badges under PCI DSS 9.3.2 and 9.3.3

Requirement 9.3.2 requires procedures for authorising and managing visitor access to the CDE, including:

• visitors are authorised before entering;
• visitors are escorted at all times;
• visitors are clearly identified and given a badge or other identification that expires;
• visitor badges visibly distinguish visitors from personnel.

Requirement 9.3.3 adds that visitor badges or identification are surrendered or deactivated before visitors leave the facility or at the date of expiration. Its objective: “Visitor identification or badges cannot be reused after expiration.”

What failure looks like in an Indian building:

• The reusable day card. A numbered lobby card is never collected and works for weeks. That fails 9.3.3.
• The contractor who looks like staff. An AMC technician wears the employees’ lanyard colour. That fails “visibly distinguishes”.
• The escort who leaves. The host walks a vendor engineer into the data hall, then goes to a meeting. That fails “escorted at all times”.

How does 9.3.1 personnel access relate to the visitor log?

Requirement 9.3.1 covers your own people: identifying them, managing changes to their physical access, revoking identification, and limiting access to the badge system. Requirement 9.3.1.1 adds, for sensitive areas, access based on job function, revoked immediately on termination, with keys and cards returned or disabled.

Requirement 9.2.1.1 requires access to sensitive areas to be monitored by cameras or access control mechanisms, with the data “reviewed and correlated with other entries” and kept for at least three months unless restricted by law.

Who needs PCI DSS in India, and why it applies here

PCI DSS v4.0.1 “is intended for all entities that store, process, or transmit cardholder data (CHD)” or sensitive authentication data, or that could affect the security of the CDE: merchants, processors, acquirers, issuers and other service providers. Payment brands and acquirers decide who must validate compliance and how. Requirement 9.3.4 is assessed in a full Report on Compliance, but some shorter self-assessment questionnaires leave out the 9.3 visitor controls (SAQ C for v4.0.1 goes from 9.2.2 to 9.4.1), so check which document you validate with. Visa, for example, states that “PCI DSS compliance is required of all entities that store, process or transmit Visa cardholder data.”

The Reserve Bank of India builds on this. Its Master Direction on Regulation of Payment Aggregators (15 September 2025) requires payment aggregators to ensure merchant infrastructure meets standards “like PCI-DSS and PCI-SSF”, to submit their PCI DSS Attestation of Compliance and Report of Compliance to their IT Committee, and to “review PCI-DSS compliance status as part of merchant onboarding process.” Under RBI’s card-on-file directions, in force since 1 October 2022, only card issuers and card networks may store card-on-file data, with a narrow exception for settlement.

In India that typically puts in scope the lobbies and data rooms of banks, payment aggregators and processors, card-handling BPOs and contact centres, retailers, and the colocation providers that host them.

Evidence map: PCI DSS 9.3.x requirements and what your visitor process must produce

What does a QSA test for PCI DSS 9.3.4?

The defined approach testing procedures are:

1. 9.3.4.a: examine the visitor logs and interview responsible personnel to verify they record physical access to the facility and to sensitive areas.
2. 9.3.4.b: examine the logs for the visitor’s name and organisation, the date and time of the visit, and the name of the person authorising access.
3. 9.3.4.c: examine where the logs are stored and interview personnel to verify they are kept at least three months, unless restricted by law.

For 9.3.2 the assessor reads your documented procedure, then observes visitors in the CDE to confirm they were authorised, are escorted, and wear a badge that sets them apart from staff and does not allow unescorted access. For 9.3.3, they observe visitors leaving and interview staff to confirm badges are surrendered or deactivated.

Expect requests like these on the day:

• “Show me the data hall visitor log for a date about three months ago.”
• “Pick five entries. Who authorised each one, and where is that recorded?”
• “This person is in the server room CCTV export. Where are they in the log?”

PCI visitor log retention: three months, or a year under the DPDP Rules?

PCI DSS sets a floor: “at least three months, unless otherwise restricted by law.” “Restricted by law” means a law that stops you keeping the data that long. India has no such restriction for visitor logs. From 13 May 2027 it sets a one-year minimum instead.

Rule 8(3) of the Digital Personal Data Protection Rules, 2025 requires a data fiduciary to retain personal data, associated traffic data and other logs of processing done by it or its processors for at least one year from the date of processing, for the purposes specified in the Seventh Schedule (State purposes such as security, functions under other laws and assessing significant data fiduciaries), and then erase them unless another law requires longer. Rule 6(1)(e) repeats the one-year period under security safeguards. Cyril Amarchand Mangaldas reads the rule as “mandatory for all organizations”, and Lakshmikumaran & Sridharan read it as applying to all data fiduciaries. Section 8(7) of the Act, which requires erasure once the purpose is served, gives way to retention another law requires, so Rule 8(3) governs the first year.

Most of these duties apply from 13 May 2027 (Rule 1(4), eighteen months after publication); some firms, including Cyril Amarchand Mangaldas, count from the next day and give 14 May 2027. A proposal to shorten the timeline was floated in January 2026; as of 12 October 2026 no change had been notified (S.S. Rana & Co.). See our guide to the DPDP Act and your visitor register.

One year satisfies both, and a single schedule can cover every detail:

Common PCI visitor log audit findings

The gaps we see most often before a PCI DSS assessment:

• Missing exit times. Entries show “in” but not “out”, so nobody can say who was inside during an incident.
• Illegible manual logs. Names cannot be read, the organisation column says “vendor”, and times are blank on busy mornings.
• No approver name. The host is written down, but not who authorised access, which 9.3.4 asks for by name.
• Lobby only. The building logs visitors; the data centre does not, or relies on access control that records only staff badges.
• A shared spreadsheet anyone can edit. The log sits on a shared drive or travels on WhatsApp, entries change without trace, and old months vanish.
• Purged at 90 days. Deleting at three months “because PCI says so” leaves nothing for an incident found in month four, and will fall short of the DPDP one-year minimum once it applies on 13 May 2027.

PCI DSS visitor log checklist

1. Map every door between the street and the card data, mark each as facility or sensitive area, and name who keeps the record there (12.8.5 for providers).
2. Record for every visit the name, organisation, date, time in and out, host, approver and areas visited, including employees entering a sensitive area they do not normally access.
3. Authorise visitors before entry and escort them in the CDE at all times.
4. Issue passes that expire with the approved window and CDE badges that look different from staff badges, and collect or deactivate every one at exit or expiry.
5. Keep the visit record for one year, protect it from editing and log every access to it.
6. Write down retention decisions for photos and mobile numbers, and keep proof of each erasure.

Where Orb fits

Orb, our visitor management system, supports your PCI DSS assessment by capturing the visitor record at the point of entry.

Questions buyers ask