PCI DSS Requirement 9 Guide: Facility Access, Media Handling and Terminal Inspection

Requirement 9 is the part of PCI DSS that assumes an attacker can walk in, carry something out or swap a payment terminal, and it is often the requirement that store, warehouse and data centre teams know least about. This guide works through PCI DSS v4.0.1 Requirement 9, "Restrict Physical Access to Cardholder Data", section by section: facility entry controls (9.2), personnel and visitor access (9.3), media with cardholder data (9.4) and point-of-interaction (POI) device protection (9.5). It is written for PCI programme owners, facilities and retail operations leads, and security engineers preparing evidence for a Qualified Security Assessor (QSA) or a self-assessment questionnaire. Requirement wording is summarised, not quoted, because the standard is published as a PDF in the PCI SSC Document Library; check every value against the current standard and your assessor before relying on it. Details marked "practitioner reading" come from our reading of the standard rather than a fetched page.

Source note: requirement wording is paraphrased from PCI DSS v4.0.1 as reproduced by secondary sources (the ComplianceAsCode PCI DSS v4 control file and Microsoft Learn) and from PCI SSC publications, because the standard itself is a PDF in the PCI SSC Document Library. Confirm against the official text before relying on it.

Key takeaways

• Sensitive areas drive scope. The PCI SSC glossary defines a sensitive area as typically a subset of the CDE housing systems critical to it, and excludes areas where only point-of-sale terminals are present, so a shop floor is not a sensitive area but the back-office server cupboard is.
• Visitors and personnel are managed differently. Personnel access is authorised by job function and revoked at termination (9.3.1, 9.3.1.1); visitors are authorised, escorted, badged and logged (9.3.2 to 9.3.4).
• Media rules cover paper too. The glossary counts electronic storage, removable media and paper reports as media, and 9.4 requires classification, secured transport with management approval, inventories and destruction when no longer needed.
• Terminals need a list, inspections and trained staff. PCI SSC FAQ 1281 confirms 9.5 does not require tethering devices; it requires an up-to-date device list, periodic inspection for tampering or substitution, and training.
• Inspection frequency is now a risk decision. 9.5.1.2.1 requires the frequency and type of POI inspections to be set by a targeted risk analysis performed under 12.3.1, which assessors will ask to see.

How Requirement 9 is structured

Requirement 9 has five sections. The wider standard is summarised in the PCI DSS 4.0 Guide; logical access, which governs the same people once they reach a console, is in the PCI DSS Requirement 7 Guide and the PCI DSS Requirement 8 Guide.

Two definitions matter before any control work. The glossary defines personnel as full-time, part-time and temporary employees, contractors and consultants with security responsibilities for account data, and a visitor as a vendor, guest, service worker or member of staff who does not normally have access to the area; shoppers in a retail store are explicitly not visitors. A console is a directly connected screen or keyboard that permits control of a server or similar system.

9.2: facility entry controls

• Entry to systems in the CDE (9.2.1): badge readers, keyed locks or staffed reception restrict entry to rooms and racks holding in-scope systems. In a colocation facility this is shared: the provider controls the building and cage, you control the rack keys and who is on the access list. Record the split in the responsibility matrix; see the PCI DSS for Service Providers and Responsibility Matrix Guide.
• Monitoring sensitive areas (9.2.1.1): individual access to sensitive areas is monitored by cameras, physical access control records, or both. In practice the standard also expects the data to be reviewed and correlated with other entries, protected from tampering and kept for at least three months unless law restricts it (practitioner reading of the standard). Point cameras at entry and exit points, not at keypads where they could record PINs.
• Network jacks (9.2.2): publicly accessible jacks in meeting rooms, lobbies and shop floors are disabled, or physically or logically controlled, for example switch ports shut down by default and enabled per request, or 802.1X port authentication. This is where the physical requirement meets ATT&CK T1200 Hardware Additions: an attacker plugging a small device into an open port.
• Network and telecoms hardware (9.2.3): wireless access points, gateways, network hardware and telecoms lines are physically restricted. A ceiling-mounted access point with an exposed console port in a public corridor is a common finding.
• Consoles in sensitive areas (9.2.4): consoles are locked when not in use, for example a KVM switch that requires login, or a session lock on a server console in the data room.

9.3: personnel and visitor access

Treat the badge system as an identity system. Its accounts outlive leavers just as directory accounts do, and its admin accounts can grant themselves access to every door. Feed it from the same HR leaver trigger as the directory, and review its administrators as privileged accounts. The Physical Access Control Systems Security Guide covers hardening of the controllers and their integrations.

9.4: media with cardholder data

The glossary defines media as physical material including electronic storage devices, removable electronic media and paper reports. That brings in printed settlement reports, chargeback paperwork, backup tapes, decommissioned disks and USB drives used for data transfer.

• Secure storage (9.4.1, 9.4.1.1, 9.4.1.2): all such media is physically secured; offline backups are stored in a secure location, and that location's security is reviewed at least once every 12 months.
• Classification (9.4.2): media is classified by sensitivity, so handlers know what a box or tape contains without opening it. A simple label scheme (for example "Confidential, contains cardholder data") is enough if it is used.
• Leaving the facility (9.4.3, 9.4.4): media sent out is secured, by secured courier or a delivery method that can be tracked, and management approves every movement, including media handed to individuals.
• Inventory (9.4.5, 9.4.5.1): inventory logs of electronic media with cardholder data are kept, and a full inventory is conducted at least once every 12 months.
• Destruction (9.4.6, 9.4.7): hard copy is destroyed when no longer needed, for example cross-cut shredding, incineration or pulping, with storage containers for to-be-destroyed paper secured; electronic media is destroyed or the data made unrecoverable. NIST SP 800-88 Rev. 2, published September 2025 and superseding Rev. 1, is the reference for sanitisation methods; see the Media Sanitisation Guide.

The cheapest way to pass 9.4 is to have less media. Each paper report or tape you stop producing removes a storage, transport, inventory and destruction process.

9.5: POI device protection

A POI is the initial point where data is read from a card: a hardware and software product, attended or unattended, that lets a cardholder complete a transaction (PCI SSC glossary). PCI SSC FAQ 1281 (July 2025) says 9.5 applies to deployed POI devices used in card-present transactions, not to components used only for manual key entry or to commercial off-the-shelf devices such as smartphones and tablets, though it recommends the same practices for them.

The risk analysis approach is described in the PCI DSS Customised Approach and Targeted Risk Analysis Guide. Devices themselves should be on the PCI SSC approved PTS device list with current approval; a P2PE solution reduces what a swapped terminal can capture but does not remove the inspection duty for the devices in scope (see the PCI Point-to-Point Encryption Guide).

Decision guidance

• Cameras or badge logs for 9.2.1.1: badge logs name the person; cameras show tailgating and what was carried. Use both for data rooms, either one for small comms cupboards, and document which.
• Disable jacks or authenticate them (9.2.2): disabling is simpler for a few public rooms; 802.1X scales for large offices and retail estates where ports move.
• Own destruction or a contractor (9.4.6, 9.4.7): a contractor needs a certificate of destruction per batch and is a third party to monitor under 12.8; on-site shredding with witnessed destruction is easier to evidence for small volumes.
• Inspection frequency (9.5.1.2.1): raise frequency for unattended, high-volume or previously targeted locations, and for devices without tamper-evident seals; lower it where devices are fixed behind staff and covered by cameras.
• Small merchants versus large estates: a single shop meets 9.5 with a laminated device list and a daily check sheet; a 2,000-store retailer needs a device management system, central reconciliation to processor terminal IDs and exception reporting from store managers.
• Cloud-hosted CDE: 9.2 to 9.4.7 for the data centre are largely inherited from the cloud provider's attestation of compliance, but your offices, paper and any on-premises consoles remain yours.

How to implement Requirement 9

1. Map sites and areas. List every facility that touches cardholder data, mark sensitive areas, POI locations, public network jacks and network hardware on floor plans.
2. Write procedures and assign owners (9.1). One owner per site, with a named deputy, and a procedure for each of 9.2 to 9.5.
3. Close entry gaps. Fit or configure badge readers and cameras for sensitive areas, disable or authenticate public jacks, lock network cabinets and set console locks.
4. Connect the badge system to the leaver process. Test with a real leaver: badge disabled the same day, keys collected, log entry captured.
5. Stand up visitor management. Pre-authorisation, expiring visitor badges, escort rules, a log that captures the required fields, and retention settings.
6. Inventory and reduce media. Stop producing unneeded reports, then classify, store, track and inventory what remains. Run the first annual inventory and offline backup site review now so the 12-month cycle has a start date.
7. Build the POI programme. Device list, targeted risk analysis for frequency, inspection checklists with photos of a known-good device, and staff training. Pilot in a few stores for a month, then roll out.
8. Test and fix. Run an unannounced walk-through: try tailgating, plug a laptop into a lobby jack, and present as a terminal repair technician. Fix what works, then repeat. If a change disrupts operations (for example, door rules locking out night staff), roll back to the previous rule set while the access list is corrected rather than leaving the door unlocked.

Detection and measurement

• What to monitor: badge denials and door-forced or door-held-open alarms for sensitive areas; switch port up events on disabled or public ports; POI device serial mismatches reported by the payment processor or terminal management system; visitor badges not returned by end of day.
• Correlation: send badge system events to the SIEM so data room entry can be matched to console logons and change tickets, which supports Requirement 10 reconstruction. See the PCI DSS Requirement 10 Guide.

Framework mapping

For a full cross-walk, see the PCI DSS 4.0 to ISO 27001 Mapping Guide. MITRE ATT&CK T1200 Hardware Additions describes the adversary behaviour that 9.2.2, 9.2.3 and 9.5 are designed to prevent.

Common failure patterns

• Badge system outside the leaver process: directory accounts are disabled on the last day but badges work for weeks, and nobody reviews who administers the door system.
• Visitor log without the required fields: a sign-in sheet records names but not the organisation or the authorising member of staff, or is thrown away after a month.
• Forgotten paper: media controls cover tapes and disks, while printed reports with full card numbers sit in unlocked trays and general waste bins.
• Device list that does not match reality: terminals swapped by a repair contractor are never added to the list, so an inspection cannot spot a substituted device because the expected serial number is wrong.
• Inspection as a tick box: staff sign a daily sheet without turning the device over or checking the serial, and nobody has trained them on what a skimming overlay looks like.
• Cloud inheritance overclaimed: a hosted CDE is used to mark all of Requirement 9 not applicable, while office consoles, network cabinets and paper still handle cardholder data.

Practitioner checklist

• Floor plans mark sensitive areas, POI locations, public jacks and network hardware for every in-scope site.
• Each site has a named owner and documented procedures for 9.2 to 9.5.
• Sensitive area access is monitored by cameras, badge records or both, with retention configured and reviewed.
• Public network jacks are disabled or authenticated; network cabinets and access points are physically restricted.
• Physical access is revoked on the last day for every leaver, tested with real cases.
• Visitor process covers authorisation, escort, expiring badges, return and a log with the required fields.
• Media is classified, tracked when moved, approved by management, inventoried every 12 months and destroyed when no longer needed.
• Offline backup storage location reviewed in the last 12 months.
• POI device list reconciled to processor terminal IDs; inspection frequency set by a written targeted risk analysis.
• Staff in POI environments trained, with records, on tampering and fake technician visits.

Standards and references

• PCI Security Standards Council: Document Library (PCI DSS v4.0.1)
• PCI Security Standards Council: FAQ 1281, POI devices and Requirement 9.5
• PCI Security Standards Council: Glossary
• PCI Security Standards Council: PTS POI
• NIST: SP 800-88 Rev. 2, Guidelines for Media Sanitization
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Hardware Additions

Related NHI Mgmt Group resources: PCI DSS 4.0 Guide · PCI DSS Requirement 10 Guide · Physical Access Control Systems Security Guide · Media Sanitisation Guide · PCI DSS Scoping and Network Segmentation Guide