Hotel PCI DSS compliance: what properties need to know

Why hotels are complex PCI DSS environments

A typical retail business has one or two payment touchpoints. A hotel has many more: front desk check-in and check-out, the restaurant, the bar, the spa, in-room minibar charges, parking, and the online booking engine. Each is a potential entry point into the Cardholder Data Environment (CDE) – the systems and processes that store, process or transmit card data.

At the centre of all of this sits the Property Management System (PMS). The PMS handles card authorisations for room payments, manages pre-authorisation holds, often stores card tokens for post-stay charges, and integrates with the restaurant and spa POS systems. It's simultaneously the most important operational system in the property and, from a PCI perspective, the highest-risk one.

The question of how payments are processed – through an integrated gateway within the PMS, or through standalone card terminals – has a significant effect on both scope and SAQ type. A property using fully standalone, unconnected terminals handles card data in a very different way from one where the PMS passes card data directly to a payment gateway. The compliance architecture needs to reflect that difference, and it often doesn't.

Add high staff turnover, seasonal operations and the frequent presence of third-party contractors on-site, and you have an environment where the controls that PCI DSS requires – individual credentials, MFA, documented access reviews – are harder to maintain consistently than they would be in a more stable commercial setting.

PCI DSS v4.0: what changed and what hotels need to address

PCI DSS v4.0 became the only valid version of the standard in March 2025, with v3.2.1 retired. For hotels that haven't reviewed their compliance posture since v3.2.1, several changes require direct attention.

The customised approach is new in v4.0 and gives organisations more flexibility: instead of implementing a specific prescriptive control, you can implement an alternative control that achieves the same security objective – provided you can document and demonstrate equivalent protection. This is particularly relevant for hotels running legacy PMS environments where a prescriptive control may be difficult or impossible to implement exactly as written. The flexibility is useful, but it comes with a documentation and evidence burden that many properties underestimate.

MFA is now required for all access to the CDE – not just remote access, as was the case under v3.2.1. Any user accessing payment systems or PMS interfaces that touch card data needs multi-factor authentication, regardless of whether they're accessing from within the building or remotely. In environments where shared credentials and basic password authentication have been the norm, this is the most common remediation gap we see.

Targeted risk analysis is another v4.0 addition: for certain controls where the standard gives you some flexibility in implementation frequency, you now need a formal documented risk analysis to justify your chosen approach. This is a process change, not a technical one – but it catches properties that have been operating on undocumented assumptions.

Requirement 6.4 introduces specific controls for e-commerce payment pages – relevant for any hotel running a direct booking engine on its own website. Scripts on payment pages must be managed and reviewed, and an inventory of authorised scripts must be maintained. This is aimed at Magecart-style skimming attacks, which have affected hospitality booking systems.

Scope definition: what's in your CDE and what isn't

The CDE is defined as the people, processes and technology that store, process or transmit cardholder data – and any systems that are connected to them. That last part is where scope tends to grow unexpectedly in hotel environments.

In a typical hotel, the CDE includes the PMS and its database, the payment terminals at each revenue point, the network segments connecting them, the payment gateway integration, and any staff member with access to card data or to systems in scope. If your front desk computers are on the same network segment as the payment terminals, the front desk computers are in scope. If the PMS integrates with your restaurant POS over the same uncontrolled internal network, that network is in scope too.

Scope reduction is the most powerful tool in PCI compliance. If you can demonstrate – and prove through testing – that a system segment has no network path to the CDE, it's out of scope. This is why network segmentation is the foundation of a workable PCI compliance architecture, not merely a security best practice. The hotel network security article covers VLAN design and segmentation implementation in detail – the key point here is that without segmentation, your entire hotel network is in scope, which makes compliance both more expensive to achieve and harder to sustain.

Scope also has an organisational dimension. Staff who have any access to cardholder data – even if that's just viewing a card number on a booking form – are in scope from a people and process perspective. Role-based access controls, documented access reviews and individual credentials (rather than shared logins) are the controls that address this.

SAQ selection for hotels

Hotels that self-assess their PCI compliance (rather than undergoing a full QSA assessment) need to select the right Self-Assessment Questionnaire. Getting this wrong is a common finding – and selecting a lighter SAQ than your environment actually qualifies for doesn't provide compliance cover.

SAQ B-IP or SAQ C apply to properties using standalone IP-connected terminals with no electronic cardholder data storage and no integration between the payment terminal and any other system. These are the lightest-touch options. They're appropriate for a property where card payments are taken on a terminal that communicates directly with the acquirer, with no card data passing through any other hotel system.

SAQ D is the full 12-requirement assessment. It applies to any property with direct PMS integration to payment processing, any property that stores electronic cardholder data (including card tokens beyond what the payment processor manages), and any property that processes card-not-present transactions through a direct gateway integration. In practice, a significant proportion of hotels that believe they qualify for SAQ B-IP or SAQ C actually require SAQ D.

The most common reason for this misclassification is how the PMS handles pre-authorisation holds. Many PMS platforms store an authorisation reference or a card token internally to allow post-stay charges to be applied. If that token is managed within the PMS rather than exclusively by a validated payment processor, the PMS is handling cardholder data – and SAQ D applies. If you're uncertain, the safe assumption is SAQ D until your PMS vendor provides clear documentation of their data handling.

For larger properties or groups, a QSA (Qualified Security Assessor) assessment rather than self-assessment may be required by your acquiring bank. QSA assessments follow the same requirements but involve an independent assessor reviewing evidence rather than the property completing a questionnaire.

PMS integration and third-party payment processors

The relationship between your PMS and your payment processor determines more about your PCI scope than almost anything else.

If your PMS vendor offers a validated P2PE (Point-to-Point Encryption) solution – where card data is encrypted at the terminal, before it ever reaches the hotel's systems, and decrypted only at the payment processor – your PCI scope is dramatically reduced. With a properly implemented P2PE solution, card data effectively never exists on your network in usable form. The PCI DSS Council maintains a list of validated P2PE solutions; if your provider claims P2PE compliance, verify they appear on it.

If your PMS processes payments through a direct gateway integration – where card data passes through the PMS before reaching the acquirer – the PMS, its database, its network connections and the systems it integrates with are all in scope. This is the more common architecture in older PMS installations, and it carries a substantially higher compliance burden.

Questions worth putting to your PMS vendor directly: Are you PCI DSS Level 1 validated? Do you offer a validated P2PE solution? What does your shared responsibility model for PCI compliance look like – what's your responsibility and what's ours? What audit evidence can you provide for your own compliance? The answers to these questions determine how much of the compliance work sits with the property versus the vendor. Many hotels have never asked them.

For card-not-present transactions – phone bookings where staff manually key in card details – a hosted payment page approach (where the customer enters card details directly into a payment processor's hosted interface rather than giving them to a staff member) removes that interaction from PCI scope entirely. If your operation still involves staff manually handling card numbers over the phone, this is worth addressing both for PCI reasons and for fraud risk.

Common hotel PCI audit failures – and how to avoid them

The findings that appear most consistently in hospitality PCI assessments are not exotic technical failures. They're process and configuration gaps that could have been addressed without significant technical investment.

Flat networks connecting POS and PMS to guest Wi-Fi are the single most common scope failure. Without VLAN segmentation, the entire hotel network is in scope – and guest Wi-Fi on the same network as payment systems is a hard finding that requires remediation before an assessment can pass.

Default or shared credentials on payment terminals or network equipment remain a persistent problem. Terminals delivered with factory-set PINs, managed switches with default admin passwords, Wi-Fi access points never reconfigured from defaults – all fail PCI DSS Requirement 2.2, which prohibits the use of vendor-supplied defaults.

Insufficient access controls cover several related findings: front desk or restaurant staff with broader PMS access than their role requires; shared login credentials for POS systems (common in busy hospitality environments where individual logins are seen as slowing service); no documented access review process; and former staff accounts that remain active after someone leaves. Each of these is a process failure – they require policy and operational discipline, not technical complexity.

Patch management failures are consistent across the sector. PCI DSS Requirement 6.3 requires critical patches to be applied within one month of release. In hotel environments with on-premise PMS and POS systems, patch cycles are often informal or non-existent. Systems running operating systems no longer receiving security updates – Windows 10 reached end of support in October 2025, for instance – are a hard finding.

Insufficient logging is frequently missed. PCI DSS requires 12 months of audit logs to be retained, with three months immediately available for review. Many properties either don't have logging configured on payment systems at all, or retain logs for 30 days as a default and have never reviewed the requirement.

Absence of a penetration test within the required period – at least annually – is a straightforward gap to identify. PCI DSS requires testing of network segmentation controls specifically, not just general penetration testing. A penetration test that doesn't include verification of CDE isolation doesn't satisfy this requirement.

None of these findings require exceptional technical resource to address. They require a structured assessment to surface them and a remediation programme with clear ownership. The cost of addressing them is consistently lower than the cost of a breach or the penalties for non-compliance.