PCI DSS Physical Security Requirements for v4.0.1

PCI DSS physical security requirements live in Requirement 9 of the Payment Card Industry Data Security Standard, and they apply to every organization that stores, processes, or transmits cardholder data.¹ Under the current version, PCI DSS v4.0.1, the requirement breaks into five sections: 9.1 governance and documentation, 9.2 facility entry controls, 9.3 personnel and visitor management, 9.4 media handling, and 9.5 protection of point-of-interaction devices.² The controls range from door locks and badge readers to how you destroy an old hard drive. Getting the electronic side right means nothing if someone can walk into your server room unchallenged or swap a card terminal for a skimmer.

Facility Entry Controls

Requirement 9.2 mandates entry controls that restrict physical access to systems in the cardholder data environment. In practice, that means badge readers, biometric scanners, or combination locks on every door leading to servers, network equipment, or workstations that handle card data.² The requirement does not apply to areas that are publicly accessible to cardholders, like a retail sales floor. The focus is on back-end spaces where data actually lives.

For sensitive areas within the cardholder data environment, such as server rooms and data centers, Requirement 9.2.1.1 goes further. Video cameras or physical access control mechanisms, or both, must monitor entry and exit points. Cameras need enough resolution to identify individuals and must be protected against tampering. Footage is typically retained for at least three months, consistent with the standard’s broader log-retention framework. Store the footage securely to prevent unauthorized deletion, and verify regularly that cameras are recording with accurate timestamps.

Personnel and Visitor Access

Requirement 9.3 separates the rules for your own people from the rules for visitors, and the standard expects documented procedures for both.

Authorized Personnel

Requirement 9.3.1 requires organizations to clearly identify everyone authorized to enter the cardholder data environment, whether through badges, access cards, or similar credentials. Access to the system that issues those credentials must itself be restricted to a small group. When someone’s job changes or their employment ends, Requirement 9.3.1.1 requires physical access to be revoked immediately and all keys or cards returned or disabled.² This control fails often in practice because it depends on HR and IT communicating in real time. A badge that still works 48 hours after a termination is a finding an assessor will flag.

Access lists should be reviewed periodically so that every person listed still has a business reason to be there. Anyone who no longer needs entry must be removed. Waiting until a breach investigation to discover that a former contractor still had active credentials is exactly what this control prevents.

Visitors

Requirement 9.3.2 requires visitors to be authorized before arrival, escorted at all times within the cardholder data environment, and given a temporary badge that is visually distinct from employee credentials. Every visitor log should capture the individual’s name, their organization, and which employee authorized the visit. Under Requirement 9.3.3, visitor badges must be collected or deactivated before the visitor leaves the premises.² Retaining these logs for at least three months gives investigators a paper trail if a breach is later traced to a specific visit.

Media Handling, Transport, and Destruction

Requirement 9.4 covers every form of media that holds cardholder data, from backup tapes and external hard drives to printed transaction reports. The standard treats media as a physical security problem because a stolen hard drive is as damaging as a network intrusion.

Classification, Storage, and Inventory

Requirement 9.4.2 requires organizations to classify all media based on the sensitivity of the data it contains. That classification determines how the media is stored, who can access it, and how it is eventually destroyed. Electronic media with cardholder data must be tracked in an inventory (Requirement 9.4.5), and that inventory must be verified at least once every 12 months (Requirement 9.4.5.1). Offsite backup locations also require a security review at least annually under Requirement 9.4.1.2.²

Transport

Anytime media leaves the facility, Requirement 9.4.4 requires management approval. Requirement 9.4.3 adds that the media must be logged, sent via a secured courier or trackable delivery method, and tracked with details about its location throughout transit.² Logs should capture the departure date, the courier or delivery service used, expected arrival, contents, and a recipient signature. These records prove that chain of custody stayed intact during assessments.

Destruction

When media is no longer needed, the standard requires irreversible destruction. For hard-copy materials, Requirement 9.4.6 specifies cross-cut shredding, incineration, or pulping so that cardholder data cannot be reconstructed. Materials awaiting destruction must be stored in secure containers. For electronic media, Requirement 9.4.7 requires that the data be rendered unrecoverable or the media itself physically destroyed.² Many organizations follow NIST Special Publication 800-88 Revision 1 for electronic media sanitization; for cardholder data, its “purge” or “destroy” levels are the safer choice.³ Keep certificates of destruction that record the date, method, and a description of the media for audit verification.

One boundary worth flagging: the federal Disposal Rule under the Fair and Accurate Credit Transactions Act applies specifically to consumer report records rather than cardholder data, though the practical overlap is large.⁴ Organizations that follow PCI DSS destruction procedures will generally satisfy the FACTA rule as well.

Protecting Point-of-Interaction Devices

Requirement 9.5 protects the card readers, PIN pads, and payment terminals where customers physically present their cards. These are prime targets for criminals who install skimming overlays or swap a legitimate terminal for a compromised one.

Device Inventory

Requirement 9.5.1 mandates a detailed list of every deployed point-of-interaction device, including the make, model, serial number, and physical location down to a specific checkout lane.² If a device is moved or replaced, the inventory must be updated immediately. Without an accurate inventory, you have no way to detect whether a terminal has been swapped for a fraudulent one.

Periodic Inspections

Devices must be periodically inspected for signs of tampering, such as broken seals, unexpected attachments, different-colored casings, or missing security labels. Under Requirement 9.5.1.2.1, organizations must perform a targeted risk analysis to determine how often those inspections occur rather than following a generic schedule. This requirement became mandatory on March 31, 2025.⁵ A high-traffic retail location with publicly accessible terminals might inspect daily; a locked kiosk in a controlled environment might inspect weekly. Document the risk analysis and its conclusions.

Staff Training on Tampering

Requirement 9.5.1.3 requires training for all personnel who work in point-of-interaction environments. The training must cover how to verify the identity of anyone claiming to be a repair or maintenance technician, how to make sure devices are not installed or replaced without proper verification, how to recognize suspicious behavior around terminals, and how to report concerns.²

The standard’s guidance flags two criminal tactics worth drilling into staff. Criminals frequently arrive dressed as technicians with toolboxes and work orders, counting on front-line employees to wave them through; employees should always call the vendor or acquirer to verify the visit before granting access to a terminal. Criminals also sometimes ship a fraudulent device to the store with instructions to swap it for the existing one and mail the old device back, sometimes even including a prepaid return label. Staff should never install a new device or ship one out without confirmation from management. Assessors will ask to see your training materials and will interview staff to confirm they actually know these procedures.

Third-Party Data Centers and Colocation

Organizations that host cardholder data in a third-party data center or colocation facility do not get a pass on physical security. The PCI Security Standards Council is explicit: using a third-party service provider does not relieve the entity of responsibility for its own PCI DSS compliance.⁶ You still own the outcome even if someone else owns the building.

In practice, that means keeping documented evidence that your data center provider meets every Requirement 9 control that applies to the space where your systems live. The cleanest way to get this is through the provider’s Attestation of Compliance, which lists exactly which PCI DSS requirements the provider’s assessment covered. The AOC for service providers explicitly includes categories like “Physical space (co-location)” and “Physical security.”⁷ Maintain a clear responsibility matrix that shows which controls the provider handles and which remain yours. The provider may manage facility entry and video surveillance while you remain responsible for securing the cage or cabinet where your specific servers sit. Under Requirement 12.8, you must keep a written agreement acknowledging the provider’s responsibility for the cardholder data it handles.⁶ If a provider cannot produce a current AOC or refuses to share compliance documentation, that is a serious red flag.

How You Prove Compliance

How you demonstrate compliance depends on transaction volume. Larger merchants, generally those processing more than one million transactions per year, must undergo an onsite assessment by a Qualified Security Assessor and submit a Report on Compliance. Smaller merchants at Levels 3 and 4 can typically complete a Self-Assessment Questionnaire instead. The SAQ type that applies depends on how you accept payments. Merchants using standalone terminals, for example, fill out SAQ B, which focuses heavily on physical security around those terminals.

During an onsite assessment, the QSA physically walks through your facility. They check that badge readers work, that cameras are recording, that media storage areas are locked, and that your device inventory matches what is actually deployed. They also review your logs, training records, and media destruction certificates. Findings go into the Report on Compliance, which is submitted to your acquiring bank or the payment brands.

Failing to demonstrate compliance carries real financial consequences. Card brands like Visa and Mastercard impose fines through acquiring banks, and those fines escalate the longer non-compliance persists. Published ranges run from $5,000 to $100,000 per month depending on the merchant’s volume and how many months the violation continues. In extreme cases, a business can lose the ability to accept card payments entirely. Keeping organized, up-to-date physical security documentation throughout the year, rather than scrambling before assessment season, is the single most effective way to avoid surprises.

What Changed With v4.0.1

PCI DSS v3.2.1 retired on March 31, 2024, and v4.0 was itself superseded by v4.0.1 on December 31, 2024. Version 4.0.1 is now the only active version of the standard.⁸ Several requirements labeled “best practices” during the transition became mandatory on March 31, 2025, including the targeted risk analysis for point-of-interaction device inspection frequency under 9.5.1.2.1.⁵

The restructuring also renumbered several physical security requirements. If your policies still reference the old numbering, such as the old 9.9 for device protection, update them to match the current 9.1 through 9.5 structure.

1
PCI Security Standards Council. PCI Data Security Standard (PCI DSS)
2
PCI Security Standards Council. Payment Card Industry Data Security Standard: Requirements and Testing Procedures
3
National Institute of Standards and Technology. Guidelines for Media Sanitization
4
eCFR. 16 CFR Part 682 – Disposal of Consumer Report Information and Records
5
PCI Security Standards Council. Summary of Changes from PCI DSS Version 3.2.1 to 4.0
6
PCI Security Standards Council. Information Supplement: Third-Party Security Assurance
7
PCI Security Standards Council. Attestation of Compliance for Onsite Assessments – Service Providers
8
PCI Security Standards Council. Just Published: PCI DSS v4.0.1