PCI DSS for hotels: a practical guide to v4.0.1 for hotel operations

What PCI DSS is and why it applies to your hotel

PCI DSS (Payment Card Industry Data Security Standard) is a private security standard managed by the PCI Security Standards Council, which was founded by Visa, Mastercard, American Express, Discover and JCB. It is not a law. No Brazilian regulator enforces it directly. What enforces it is the contract with the acquiring bank.

When a hotel signs up with an acquirer to accept card payments (in Brazil, Cielo, Rede, Stone, Getnet or any other), it takes on a contractual obligation to comply with PCI DSS across all its payment channels. The main acquirers in Brazil set their own compliance programmes, with deadlines, accepted types of validation and consequences for non-compliance. The current version is PCI DSS v4.0.1, published in June 2024 as a limited revision of v4.0, with no requirements added or removed. Version 3.2.1 was retired in March 2024.

The penalties for non-compliance are serious: the card brands can fine the acquirer, in amounts commonly cited at between US$5,000 and US$100,000 a month, and the contract usually passes those fines on to the merchant. If card data is breached, the hotel can be held liable for the cost of replacing all the affected cards, forensic investigation fees and chargebacks. Card data is also personal data under the LGPD, Brazil's data protection law: a breach may trigger a duty to notify the ANPD, the national data protection authority. The payments section of our Brazil guide covers how PCI DSS sits alongside Brazilian rules.

Why a hotel's PCI DSS scope is more complex

Many small businesses have a single payment channel: an online shop or a counter terminal. Hotels tend to have several. A mid-sized hotel can have all of these environments at the same time:

A PMS with integrated card processing: in many installations the Property Management System processes payments directly on the platform: pre-authorisation at check-in, charges for in-house spending and the final charge at check-out. If the PMS transmits or stores card data on the hotel's servers, that system is in PCI DSS scope with substantial requirements.

POS in the restaurant, bar, spa and laundry: each point-of-sale terminal in the hotel that accepts cards creates a point of scope. IP-connected POS terminals (chip and PIN over the network) fall under SAQ B-IP if they are properly isolated from the hotel's operational network. POS terminals that talk to wider internal systems may require SAQ C or SAQ D.

The booking engine on the hotel's website: the hotel's website may use a third-party booking engine with hosted checkout. In that model, card data never touches the hotel's servers, and the channel may qualify for SAQ A, the shortest questionnaire. If the hotel's website interacts with the payment form through JavaScript or loads third-party scripts on the checkout page, SAQ A-EP may be required.

OTAs and third-party bookings: bookings that come from Booking.com, Expedia or other channels are generally processed by the channel itself. The hotel receives a payment guarantee or a virtual card, but the scope depends on how that card is charged. If the PMS charges the virtual card directly, that transaction is in the hotel's scope. If the OTA settles the payment and passes it on to the hotel by invoice, that channel may fall outside card scope.

Front desk terminals: card-present check-in and check-out create a separate card-present environment. The terminal's configuration decides which SAQ applies to the channel: whether it processes locally, over the network or through a certified third-party system.

The practical consequence: many hotels have more than one type of SAQ applying at the same time, one for each payment channel. Mapping all of the hotel's payment channels and working out how each one handles card data is the first step in any hotel PCI DSS compliance programme.

Merchant levels and which SAQ applies to your hotel

The merchant level sets how intensive the validation required by the acquirer is. The criteria are set by the card brands and can vary between them, and it is the acquirer that confirms the level based on the reported transaction volume. As a general reference:

• Level 1: more than 6 million Visa or Mastercard transactions a year, or any hotel that has suffered a qualifying breach. Requires an annual audit by a Qualified Security Assessor (QSA) and quarterly scans by an Approved Scanning Vendor (ASV).
• Level 2: 1 to 6 million transactions a year. An annual Self-Assessment Questionnaire (SAQ) plus quarterly ASV scans.
• Level 3: 20,000 to 1 million e-commerce transactions a year. An annual SAQ plus ASV scans.
• Level 4: fewer than 20,000 e-commerce transactions, or fewer than 1 million transactions in total. An annual SAQ; an ASV scan may be required at the acquirer's discretion.

Many independent hotels sit at levels 3 or 4. For hotels with several channels, the acquirer may apply different SAQ types per channel.

The SAQ types most relevant to hotels:

• SAQ A: for the online booking channel when it is fully outsourced to a hosted checkout page. It is the shortest questionnaire. It applies only if card data never passes through the hotel's systems.
• SAQ B-IP: for standalone payment terminals, approved under PCI PTS and connected to the processor over IP, with no electronic storage of card data. It applies to restaurant, bar and front desk terminals properly isolated from the rest of the network.
• SAQ C: for internet-connected payment application systems that do not store data electronically. It may apply to a PMS with payment integration over the network. It is broader than SAQ B-IP.
• SAQ D: the broadest. It applies to hotels that store card data, have complex payment environments or do not qualify for the more specific SAQs.

Choosing the wrong SAQ type is a compliance failure in itself. Check with your acquirer before filling in any self-assessment.

SAQ descriptions refer to PCI DSS v4.0.1, the current version at the time of publication. The content and eligibility criteria of each SAQ can change in revisions of the standard, as happened with SAQ A in January 2025; always check the latest official document from the PCI Security Standards Council.

The 12 PCI DSS requirements

The standard is built around 12 requirements covering network controls, data protection, access management, monitoring, testing and policies. For hotels, each requirement has specific implications:

• 1. Network controls: the guest network must be separated from the network that supports payment systems. The PMS, POS and front desk terminals must sit on separate network segments with documented firewall rules.
• 2. Secure configurations: no supplier default passwords. That includes PMS systems, IP cameras, network routers and POS terminals. They all arrive with default credentials that must be changed before going into production.
• 3. Protection of stored data: the CVV cannot be stored after authorisation, not in PMS logs and not in booking systems. Stored card numbers (PANs) must be encrypted. Many PMS systems have debug logs that capture transaction data; this needs to be audited.
• 4. Data in transit: TLS 1.2 or higher on every transmission path. Card data must never travel by email, WhatsApp or internal messaging.
• 5. Protection against malware: EDR or anti-malware on all in-scope systems, including the computers that access the PMS, POS terminals with an operating system and booking servers.
• 6. Secure systems and software: patches applied regularly to the PMS, the POS terminals' operating system and any payment-facing application. Systems that no longer receive fixes need isolation and a replacement plan (see legacy systems in hotels). If the hotel hosts its own payment page, the scripts on that page need an inventory and integrity control (v4.0).
• 7. Access by business need: the reservations team does not need access to restaurant POS logs. The F&B team does not need access to the rooms PMS. Role-based access control, with least privilege.
• 8. Identification and authentication: unique IDs for each employee. MFA required for all access to the cardholder data environment that is not made directly at the console, such as network access to the PMS and to the reservations back office, as well as remote access. This was expanded in v4.0.
• 9. Physical access: regular tamper checks on POS terminals. Skimming, the fraud in which an illegal device (a skimmer) is fitted over the card reader to copy card data at the moment of payment, depends precisely on a terminal left unprotected and without regular physical inspection. Control over who has physical access to servers and network equipment that support payment systems.
• 10. Logs and monitoring: audit logs kept for 12 months, with 3 months immediately available. Alerts for unusual access patterns, such as a POS terminal accessed outside the restaurant's opening hours.
• 11. Regular testing: quarterly internal and external vulnerability scans for in-scope environments. An annual penetration test. For IP-connected POS systems, this includes the systems that talk to them.
• 12. Policies and governance: a written information security policy, an annual risk assessment, an incident response plan and awareness training for teams that handle card data: front desk, reservations, F&B and finance.

Key PCI DSS v4.0.1 requirements for hotels

The PCI SSC retired v3.2.1 on 31 March 2024. v4.0 brought 64 new requirements, 51 of which were originally classed as future-dated and became mandatory on 31 March 2025; today they are all in force. In June 2024 the Council published v4.0.1, a limited revision of v4.0 with no additional requirements, which has been the current version since then. The changes most relevant to hotels, inherited from v4.0 and kept in v4.0.1:

Expanded MFA: v4.0 (Requirement 8.4.2) requires multi-factor authentication for all access to the cardholder data environment that is not made directly at the console, not only for remote access. In practice, that covers network access to a PMS with integrated payments, administrative access to payment systems and the reservations back office.

Script security on the booking engine (Requirements 6.4.3 and 11.6.1): if the hotel's website loads third-party scripts on the checkout page (Google Analytics, chat tools, marketing pixels), these requirements call for a documented inventory of each script, a business justification and integrity checking. In January 2025, the PCI SSC removed these two requirements from SAQ A and, in their place, began requiring the merchant to confirm that its website is not susceptible to script attacks that could affect the checkout. For hotels using hosted checkout, the question to ask the booking engine supplier is how it protects the payment form. For hotels that host their own form (SAQ A-EP or SAQ D), the requirements still apply.

Longer passwords: the minimum password length for accounts on in-scope systems went from 7 to 12 characters. That includes PMS accounts, network administration and access to POS terminals.

Targeted risk analysis: some requirements now leave the frequency to the merchant, as long as it is justified by a documented, targeted risk analysis (Requirement 12.3.1). That is the case for periodic inspection of POS terminals for tampering and for reviewing certain logs. Other activities, such as quarterly vulnerability scans, keep a fixed frequency.

How to reduce PCI DSS scope in your hotel

The cardholder data environment (CDE) covers every system that stores, processes or transmits card data, plus every system that can affect the security of those components. A smaller CDE means less compliance effort. For hotels, the most effective strategies are:

A fully hosted booking engine: when the checkout on the hotel's website redirects to a payment page hosted by the provider, card data stays outside the hotel's systems, and that channel may qualify for SAQ A. This applies to any booking engine with PCI DSS compliant hosted checkout; ask the supplier for its current Attestation of Compliance (AOC). The hotel's website must not load scripts that interact with the payment form.

Tokenisation in the PMS: for long stays, subscriptions and recurring charges, the PMS can replace the card number with a token issued by the payment gateway. Only the token vault, kept by the provider and not by the hotel, needs to be in scope. The PMS stores only the token, not the PAN.

Network segmentation: restaurant and bar POS terminals isolated on a separate network segment, with no route to the PMS or corporate systems, can be assessed under a standalone SAQ B-IP. Without that segmentation, any system that could reach a POS terminal has to be treated as within the full CDE scope.

A payment gateway for the front desk: front desk terminals connected to an external PCI DSS certified gateway, with no card data stored on the hotel's server, reduce the scope of the card-present channel. The hotel can then apply SAQ B-IP to those terminals if they are properly isolated.

Scope decisions made at the system design stage cost much less than fixing compliance gaps once the systems are in production. That applies when evaluating a new PMS, setting up a booking engine or installing a new POS network.

Next steps

If your hotel has never been through a PCI DSS assessment, the starting point is to map all payment channels and work out how each one handles card data. With that map, you can confirm the merchant level with the acquirer, identify which SAQ applies to each channel and run a gap analysis before committing resources to remediation.

The practical sequence for hotels behind on compliance or close to an acquirer deadline:

• Map all payment channels (PMS, POS, booking engine, front desk terminals) and document how each one handles card data.
• Confirm with the acquirer the merchant level and which SAQ type applies to each channel.
• Run a gap analysis against the applicable SAQ to identify missing controls or controls without evidence.
• Look for scope reduction opportunities before starting remediation, with a particular focus on tokenisation in the PMS and a hosted booking engine.
• Remediate the failing controls and fill in the SAQ.
• If the SAQ requires it, hire an Approved Scanning Vendor (ASV) for the external scan.
• Send the Attestation of Compliance (AOC) to the acquirer on time.

Our team has experience in national and international hotel operations, including chains with several PMS, POS and distribution systems. We can lead the PCI DSS scope mapping, the gap analysis and support for remediation. Talk to our team.

Sources

• PCI Security Standards Council, PCI DSS v4.0.1 and Self-Assessment Questionnaires, pcisecuritystandards.org
• PCI Security Standards Council, Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A (January 2025), blog.pcisecuritystandards.org