The Numbers That Matter
If you run an independent hotel, here is the situation as of the day this article was published. PCI DSS v4.0 became mandatory on 31 March 2024 when v3.2.1 was retired by the PCI Security Standards Council. PCI DSS v4.0 itself was then retired on 31 December 2024 and replaced by v4.0.1, which is the only currently active version of the standard. And on 31 March 2025, the 51 requirements that had been classified as "future-dated best practice" became mandatory with no grace period. If your last self-assessment was performed against any earlier version, or against v4.0 with the future-dated requirements marked Not Applicable, you are non-compliant as of this writing.
Most independent hoteliers I speak with do not know this. The ones who do tend to know it in a foggy way that lets them keep delaying. They know "something happened with PCI in 2025." They are not sure if it applies to them. They suspect their payment processor handles it. They are mostly wrong on all three points.
The mechanics are simple. The card networks (Visa, Mastercard, American Express, Discover, JCB) make compliance a contractual condition of accepting their cards. Your acquiring bank passes that contract through to you. If you are out of compliance and your acquirer notices, the bank can pass through non-compliance fees that start at $5,000 per month for months one to three, escalate to $25,000 to $50,000 per month for months four to six, and reach $50,000 to $100,000 per month from month seven onwards, per the published schedules collected from acquirer enforcement actions in 2024 and 2025. If you are out of compliance and you also have a data breach, the Account Data Compromise penalties from Visa alone start at $50,000 per incident for a non-compliant merchant and run to $500,000, with parallel assessments from Mastercard. None of these numbers are theoretical. The Marriott and Starwood breach settlement finalized by the U.S. Federal Trade Commission on 20 December 2024 included a $52 million parallel settlement with 49 state attorneys general, and the related £18.4 million GDPR fine from the UK Information Commissioner's Office in 2020 brought the cumulative damage from that breach into the high nine figures before legal and remediation costs.
That is the downside. The upside is that for the average 30 to 150 room independent hotel that uses a tokenizing payment processor, becoming and staying compliant costs $1,500 to $3,000 per year, takes one person about 90 days to get into shape the first time, and requires no QSA, no consulting retainer, and no enterprise security platform. The difference between $1,500 a year and a five-figure monthly fine is, as you might imagine, the entire point of this article.
This is the honest read on PCI DSS 4.0 for independent hotels in 2026. The four lies hoteliers tell themselves about it, how to choose the right Self-Assessment Questionnaire (which is the single biggest decision you will make), the ten new requirements that hotels fail most often, the seven places card data is hiding in your hotel that you forgot about, the real cost ranges with sources, and a 90-day plan that one operationally-minded person can run without external help.
What Changed and Why You Missed the Deadline
The reason hotel operators missed the PCI DSS 4.0 deadline is not laziness. It is that the PCI Security Standards Council communicated the transition badly, and the hospitality trade press covered it worse. Here is the actual sequence so you can stop being confused about which version you are supposed to be on.
PCI DSS v3.2.1 was published in May 2018 and remained the active version of the standard for almost six years. Most hotel SAQs filed between 2018 and 2024 referenced v3.2.1. PCI DSS v4.0 was published on 31 March 2022 with a two-year overlap period during which both v3.2.1 and v4.0 were active. v3.2.1 was retired on 31 March 2024. From that date forward, any PCI DSS assessment had to be conducted against v4.0.
v4.0 introduced 64 new requirements. 13 of them were effective immediately on publication. The other 51 were designated as "future-dated best practices" with a three-year runway. Hotels and their assessors were allowed to mark the 51 future-dated requirements as Not Applicable on assessments performed between 31 March 2022 and 31 March 2025, with a documented note that they would be addressed by the deadline. Most hotels did exactly that, then forgot about them.
In June 2024, the PCI SSC published v4.0.1, which is a limited revision of v4.0 with formatting corrections, clarified applicability notes, and no added or removed requirements. v4.0 was retired on 31 December 2024, and v4.0.1 became the only currently active version. The 31 March 2025 deadline for the 51 future-dated requirements was unchanged by the v4.0.1 revision and the PCI SSC was explicit on this point in their published FAQ.
That deadline has passed. As of 1 April 2025, the 51 formerly future-dated requirements are mandatory and must be validated with evidence during every PCI DSS assessment. There is no grace period, no temporary mitigation accepted, and Qualified Security Assessors have been instructed to verify not just that controls are implemented but that they were operational before the deadline rather than rushed in the week prior. If your hotel's most recent SAQ marked those 51 requirements as Not Applicable, you are out of compliance from the moment you submitted it.
The four control areas that absorb the most operator time, and that are most often missed, are documented further down. But the most useful summary I can give you here is this: if you have not opened your last SAQ in the past 12 months, you almost certainly need to file a new one. If your last SAQ was an SAQ A, the rules about what qualifies for SAQ A have tightened (more on that below). And if your hotel still emails virtual credit card details in plaintext, you have been in violation of Requirement 4.2.1 since the day you opened your booking engine. None of these are speculative claims. They are the published, current text of PCI DSS v4.0.1.
The Four PCI Lies Hotels Tell Themselves
Before the practical guidance, the four self-deceptions I hear in almost every PCI conversation with an independent hotelier. None of these are stupid. They were all reasonable interpretations of PCI DSS v3.2.1 and the looser enforcement culture of 2018 to 2023. They are no longer true under v4.0.1 and 2025-onwards enforcement.
1. "Our payment processor handles compliance for us"
Your payment processor handles their PCI compliance. They do not handle yours. PCI DSS draws a sharp legal line between a Third-Party Service Provider (TPSP) such as your acquirer, your gateway, or your tokenization processor, and you the merchant. The TPSP is responsible for the cardholder data that travels through their environment and for completing their own SAQ D for Service Providers. You the merchant are responsible for the cardholder data that touches your environment, for the integrations you operate, and for completing your own SAQ. The two responsibilities do not overlap and there is no version of "our processor handles it" that is contractually true. What your processor can do is sell you an architecture where their environment absorbs most of the cardholder data scope, which then lets you complete a much smaller SAQ. That is the actual value of using a tokenizing processor, and it is a real value, but it is not the same as outsourcing your compliance.
2. "We qualify for SAQ A because our booking engine is hosted"
SAQ A is the lightest of the eight SAQ types and applies to merchants who have fully outsourced the storage, processing, and transmission of cardholder data to a PCI DSS-compliant third party, with no electronic storage or transmission on the merchant's own systems. SAQ A merchants may only retain cardholder data on paper (printed reports, receipts) and these paper records may not be received electronically. For an e-commerce channel specifically, every element of the payment page delivered to the customer's browser must originate only and directly from a PCI DSS-compliant Third-Party Service Provider. That is the literal text of the SAQ A v4.0.1 eligibility criteria.
The PCI SSC tightened the SAQ A eligibility criteria further in January 2025 with a new attestation requirement that the merchant's e-commerce site is not susceptible to script-based attacks. In practice, this means that even hotels who use a fully hosted booking engine with iframe-based payment can no longer wave away Requirements 6.4.3 and 11.6.1 if the rest of their booking site loads any third-party scripts that could in principle affect the payment page. Most independent hotel sites do load such scripts (analytics, chat widgets, marketing pixels, review widgets), so the SAQ A path is narrower than it looks. We will come back to this in the SAQ selection section.
3. "We are too small to be a target"
The 2024 Verizon Data Breach Investigations Report classifies hospitality as one of the top-five most-breached industries on a per-organization basis, and the median victim is not a chain. Attackers prefer small independent hotels for a simple economic reason: the per-incident yield (around 12,000 card numbers per year for a 60-room hotel running at 75% occupancy) is enough to be worth the effort, while the defensive posture is typically a decade behind what an enterprise security team would deploy. Attackers also know that the average independent hotel will not detect a Magecart-style payment-page skimming attack for months. The mean dwell time in hospitality breaches investigated by Verizon is over 200 days. The combination of "long dwell, weak detection, high card-yield-per-employee" is exactly why hotels are targeted.
4. "We have never been breached, so we must be fine"
This one is the easiest to dismantle: the median dwell time for a payment-card breach in hospitality is, again, over 200 days. The absence of a known breach is not evidence of security; it is evidence that you do not know whether you have been breached, which is a very different statement. Most hotels that have been breached learned about it from their acquiring bank, who learned about it from a Common Point of Purchase analysis after fraud was reported on cards used at the hotel. By that point the dwell time is typically nine to twelve months and the breach has been quietly active across that whole period. PCI DSS 4.0.1 Requirement 10.4.1.1 was added specifically to push automated log review to the front of the detection stack so that hotels can stop being told about their own breaches by their bank.
Choose Your SAQ Correctly (This Is the Whole Game)
The most consequential decision in your PCI program is which SAQ you fill in. The wrong choice costs you, in worst-case order: a failed assessment (which converts your hotel to non-compliant overnight), tens of thousands of dollars per year in unnecessary compliance overhead, and a much larger attack surface for an actual breach. The right choice is usually obvious once you map your card data flow, which most hotels have never actually done.
The eight SAQ types in v4.0.1, with the question count and the typical hotel scenario that maps to each one:
- SAQ A (about 30 questions): Pure e-commerce with all card data fully outsourced to a PCI DSS-validated TPSP. No electronic storage, processing, or transmission on hotel systems. The booking engine, payment page, and tokenization all run on the processor's infrastructure. The hotel only sees a token reference back. Most boutique independents using Stripe, Adyen, Mews Payments, Cloudbeds Payments, or Prostay Pay with an iframe-based checkout fit here, provided they also meet the new January 2025 attestation that the site is not susceptible to script-based attacks.
- SAQ A-EP (about 190 questions): Partially outsourced e-commerce. The merchant's website affects the security of the payment transaction (for example, a redirect-and-return flow where the hotel page hands the browser to the processor and gets it back) but the merchant still does not electronically store, process, or transmit cardholder data themselves. This is where most hotels actually live today even if they think they are SAQ A.
- SAQ B (about 40 questions): Standalone dial-out terminals only, no electronic cardholder data storage. Effectively obsolete in 2026.
- SAQ B-IP (about 80 questions): Standalone PIN Transaction Security-approved terminals with IP connectivity, no electronic storage of cardholder data. This is the right SAQ for a hotel that takes most payments through a fixed countertop EMV terminal that connects directly to the processor and never integrates with the PMS.
- SAQ C (about 160 questions): Payment application systems connected to the internet, no electronic cardholder data storage. Some hotel POS deployments fit here.
- SAQ C-VT (about 80 questions): Manual entry of single transactions at a time via a virtual terminal provided by a TPSP. This fits a small hotel where the front desk types card numbers into a hosted web terminal one at a time, with no other electronic CHD presence.
- SAQ D (Merchant) (about 330 questions): Everything else. Any electronic storage of cardholder data on hotel systems automatically lands you here.
- SAQ D (Service Provider) (about 330 questions): For service providers. Does not apply to hotels acting as merchants.
For a typical 60-room independent in 2026 with a hosted booking engine, an EMV terminal at the front desk, and no card data stored in the PMS, the right SAQ is either SAQ A or SAQ B-IP depending on which payment channel you treat as primary. The wrong SAQ for that hotel is SAQ D, which most accountants will instinctively pick because they assume the longer questionnaire is "safer." SAQ D is not safer. It applies a much broader requirement set that you cannot actually meet without enterprise infrastructure, and assessors are now trained to fail merchants who self-select into SAQ D without having a documented reason.
The single most impactful thing you can do in the next 30 days is map your card data flow on paper, identify the SAQ that actually applies, and document why it applies. If that mapping exercise reveals that any hotel system electronically stores, processes, or transmits cardholder data (which it almost certainly does, more on that in the "card data is hiding in your hotel" section), your real job before filing an SAQ is to architect that out, not to file an SAQ D and live with the larger surface.
The Ten New Requirements Hotels Fail Most Often
The 51 future-dated requirements that became mandatory on 31 March 2025 cover the whole 12-requirement standard. In the engagements I have seen at independent hotels in 2025 and 2026, ten requirements absorb roughly 80% of the remediation work. Here they are in the order I would attack them, with the actual v4.0.1 control text condensed to plain English and the typical hotel failure mode for each.
Requirement 4.2.1: end the plaintext VCC email problem
Requirement 4.2.1 says that Primary Account Numbers must only be transmitted over open, public networks using strong cryptography. "Open, public networks" includes the public internet, which includes every email server outside your tokenized environment. Hotels routinely receive virtual credit card (VCC) details from OTAs and tour operators in plaintext email. This has been a violation since PCI DSS v1.0 in 2004. It is still a violation under v4.0.1. The Antravia industry survey published in 2026 found that nearly one in three hotels still receive at least some VCC details in plaintext email and treat it as normal. It is not. Fix this by requiring all VCC delivery via the OTA's secure extranet, an API integration, or a tokenized inbox solution. The card networks are increasingly auditing this control directly via the OTA, so if your acquirer has not flagged it yet, your supplier almost certainly will.
Requirements 6.4.3 and 11.6.1: lock down the payment page scripts
These two requirements are the headline of v4.0.1 for e-commerce and they apply to every hotel website that takes payments. 6.4.3 is preventive: every script loaded and executed in the customer's browser on a payment page must be authorized, have its integrity verified, and appear in an inventory with a documented technical or business justification. 11.6.1 is detective: a change- and tamper-detection mechanism must be deployed that alerts personnel within seven days if security-impacting HTTP headers or the contents of payment page scripts change as received by the consumer browser.
The typical hotel failure mode is that the booking page is loaded with eight to fifteen third-party scripts (analytics, chat, retargeting, reviews, A/B test framework, heatmap, consent manager, social pixels) and the hotel has neither an inventory nor a tamper-detection mechanism. The fix is concrete: prune the third-party script list to the minimum, document each remaining script's justification, and deploy either a server-side change-detection tool such as Visualping, Feroot, or PCI Pal, or a client-side script-management product such as Source Defense. Content Security Policy headers and Subresource Integrity hashes are part of the right answer but the PCI SSC's guidance is explicit that they are not sufficient on their own; you also need monitoring.
Requirement 12.5.2: confirm your PCI scope annually
Requirement 12.5.2 mandates an annual exercise to confirm the PCI scope and the components in it (service providers every 6 months). The exercise must identify all cardholder data flows, all systems that store, process, or transmit cardholder data, and any system that is connected to or could affect the security of cardholder data. The Verizon DBIR has stated repeatedly that 34% of hotel breaches originate from card data found in unexpected places. The scope confirmation exercise is the mechanism that finds those unexpected places before an attacker does.
Requirements 8.3.6 and 8.4.2: MFA for all CDE access
Under v4.0.1, multi-factor authentication is required for all non-console access into the cardholder data environment, including administrative access by hotel staff and by third-party service providers. This goes beyond the v3.2.1 baseline (which only required MFA for remote administrative access from outside the network) and is the requirement that breaks the most hotel admin habits. The fix is to deploy phishing-resistant MFA (TOTP at minimum, FIDO2 hardware keys for admin accounts) on every PMS account, every payment gateway login, every router admin login, and every cloud back-office account that touches CDE.
Requirement 11.4.7: authenticated internal vulnerability scans
Internal vulnerability scans must now be performed using credentials that allow authenticated access. An anonymous scan of your network is no longer sufficient. The practical impact is that you need to either run an internal scanner with authenticated credentials yourself (most hotels cannot) or hire a QSA-partner to run a credentialled scan quarterly. Plan to budget an extra $500 to $2,000 per year for this if you do not have internal capability.
Requirement 12.6.3.1: targeted security awareness training
Security awareness training must now cover threats and vulnerabilities that could impact the security of the cardholder data environment, with specific content for the technologies and roles in scope. A generic "phishing 101" video does not satisfy this requirement. You need role-specific content: a different module for front desk staff (focused on social engineering, card data handling, and the plaintext VCC problem), a different module for back office (focused on PMS access control and the fax-archive problem), and a different module for IT or whoever administers your booking engine. Document delivery and completion annually.
Requirements 3.3.2 and 3.5.1.1: keyed cryptographic hashes for PAN
If you store PAN data in any electronic form (please don't), one-way hashes are no longer enough to render the PAN unreadable. You must use a keyed cryptographic hash with associated key-management processes per Requirements 3.6 and 3.7. Practically, this almost never applies to a hotel that uses a tokenizing processor, because the hotel should not have a PAN to hash. The cleanest answer is to architect the PAN out of your environment entirely, which puts you in SAQ A or SAQ B-IP scope and removes Requirements 3.3.2 and 3.5.1.1 along with most of the rest of Requirement 3.
Requirements 6.3.2 and 6.3.3: bespoke and custom software inventory plus patching
All bespoke and custom software must be inventoried and patched. For most hotels this surfaces an unexpected liability: the WordPress or Squarespace or custom-built marketing site that the marketing agency built in 2018, has not patched since 2021, and that loads scripts onto the booking flow. Patching cadence under v4.0.1 reverted to v3.2.1 language: critical vulnerabilities must be patched within 30 days. The fix is to maintain a software inventory (a spreadsheet is fine for an independent), assign an owner per component, and either patch on schedule or retire the component.
Requirement 10.4.1.1: automated log review
Manual log review is no longer acceptable for v4.0.1 daily review requirements. You need an automated mechanism that ingests logs from the cardholder data environment and surfaces anomalies. For a small independent this can be as simple as the audit log feature in your cloud PMS (with email alerts on suspicious events), plus the alerting features in your payment gateway dashboard. You do not need a $50,000-a-year SIEM, but you do need to demonstrate that something is reviewing logs every day.
Requirement 12.10.7: incident response procedures for stored PAN found in unexpected places
If your scope confirmation (12.5.2) finds PAN data in a place it should not be, you need a documented procedure for how you respond. The minimum is: contain (isolate the system), assess (figure out what was exposed and for how long), notify (your acquirer within whatever timeline they require, often 24 to 72 hours), and remediate (remove the data and fix the cause). Write this procedure once, store it where on-call staff can find it at 3am, and review annually.
The Seven Places Card Data Is Hiding in Your Hotel
The Verizon DBIR 34% figure I cited earlier is not abstract. In every independent-hotel PCI engagement I have been involved with in the past two years, the scope-confirmation exercise has surfaced at least three of the following seven places where cardholder data is sitting, often years after it was put there and forgotten. Here is the list, ordered by frequency. Use it as a checklist for your own 12.5.2 exercise.
- Email server archive. Every plaintext VCC email sent by an OTA, or any guest who once typed their card number into a "Please charge my card for the deposit" email, is sitting in your IMAP archive. Search for "card number," "CVV," "expiration," and the four-digit-then-space pattern. You will be horrified by what you find.
- Old PMS database backups. Every nightly PMS backup created before your hotel switched to a tokenizing processor likely contains full PAN data. Check your offsite backup vendor, your hotel's NAS, your front desk manager's external drive, and the unencrypted USB stick in the safe. Backups from before 2019 are particularly likely to contain raw PAN.
- Fax archive. Every OTA-issued VCC fax, every group booking authorization form, every credit card payment authorization form your back office requested. Modern multifunction printers often have a 500-fax archive on internal storage that has never been cleared.
- Folio archive printouts. The stack of printed folios at the back office, the bound archive of guest folios pre-2020, the manager's filing cabinet labeled "audit copies." These contain printed PAN data, which violates SAQ A's "paper only if not received electronically" rule once you realize the folios were generated by an electronic PMS.
- Excel files for revenue and yield management. The "deposits this month" spreadsheet that someone in accounting maintains. The "no-show charges" tracker. The "outstanding VCC payments" workbook. These often have card data pasted in from emails, sometimes for years.
- Handwritten logbooks. The front desk logbook where the night auditor wrote down "Took Mrs Smith's deposit by phone, Visa ending 4242, exp 06/27, charged $400." Yes, this still happens in 2026.
- Vendor portals and third-party tools. The CRM that someone configured to import OTA emails verbatim. The shared inbox that the spa uses to email card numbers between staff. The Trello board that group sales uses to track contract deposits. The Slack DM history with the prior front office manager.
The discovery process is uncomfortable. The remediation is mostly clerical: identify the data, classify it (is it active CHD or historical?), shred or securely delete the historical data, architect the active data flows so they go through the tokenizer instead, and document the new policy that prevents the data from coming back. Plan three to ten staff-days for a 60-room hotel doing this for the first time. Most of it is searching mail archives and shredding folio backups.
The Real Cost: Benchmarks, Not Vendor Scare Tactics
The PCI consulting industry has a strong incentive to inflate the cost of compliance, because that is how they sell their services. The honest cost ranges, by SAQ path and merchant size, are well-documented and converge to these benchmarks for an independent hotel in 2026.
SAQ A path (fully outsourced, tokenizing processor, no electronic CHD on hotel systems). Annual SAQ completion: under $300. Quarterly Approved Scanning Vendor (ASV) external scans: $500 to $2,000 per year depending on provider. Annual security awareness training tooling: $500 to $1,000. Total: $1,500 to $3,000 per year. This is the right path for the majority of independent hotels and it is what your processor's onboarding team should be steering you toward.
SAQ A-EP path (partial outsourcing, redirect flow, no electronic CHD storage but the hotel page can affect transaction security). Add: more questions (about 190 vs. 30), a documented script inventory and a tamper-detection mechanism for 6.4.3 and 11.6.1, and likely a small consulting engagement to get the first-year posture right. Total: $5,000 to $15,000 per year.
SAQ B-IP path (standalone PTS-approved IP terminals, no electronic CHD storage). Total: $1,500 to $5,000 per year. The terminal vendor often bundles SAQ B-IP attestation tooling into their service.
SAQ D path (any electronic CHD storage, or any environment that does not fit a more specific SAQ). Annual SAQ: 330 questions, often requires consulting help to complete correctly ($3,000 to $10,000 first year). Quarterly ASV scans: $500 to $2,000. Penetration testing: $3,000 to $8,000 per year. Endpoint protection and basic SIEM-like log review: $2,000 to $5,000. Annual training: $500 to $1,500. Total: $15,000 to $50,000 per year for a small independent, more if you have multiple properties.
QSA-led Report on Compliance (required for Level 1 merchants with 6 million+ transactions). Total: $30,000 to $80,000 for the assessment alone on a mid-size merchant, plus all of the underlying controls. The Hotel Tech Insight 2026 cybersecurity benchmark for a 60-room independent puts the all-in defense stack at €3,500 to €5,000 first year and €2,000 to €3,500 ongoing, which lines up with the SAQ A path above plus basic endpoint and network controls.
And on the other side of the ledger, the published 2025 benchmark from Antravia Advisory is worth memorizing: tokenized, PCI 4.0-compliant travel merchants paid an average 1.8% interchange fee, compared with 2.9% for non-compliant merchants. Chargebacks fell from 1.8% to 0.6%, and average audit costs dropped by two-thirds. For a 60-room hotel doing $2 million in card revenue per year, the interchange-fee delta alone is $22,000 of recurring annual savings, which is ten to fifteen times the cost of the SAQ A compliance work. Compliance is not a tax. It is a moat that earns you a price advantage at checkout.
The 90-Day Plan One Person Can Run
If your hotel has not addressed PCI DSS 4.0.1 yet, here is the plan that gets you to "passing SAQ A with a documented architecture" in 90 days. One person who is operationally competent and has reasonable access to the GM and the IT vendor can run it without external consulting. Block roughly 8 hours per week for the assigned person across the 90 days.
Days 1 to 15: Scope and discover
Map your card data flow on paper. Where does a card number enter your environment (booking engine, front desk EMV terminal, OTA email, phone, group sales contract)? Where does it go next (tokenizer, gateway, PMS, accounting export)? Where is it stored, if anywhere (it should be nowhere)? Then run the seven-places-card-data-is-hiding checklist from the prior section. Document everything you find in a single spreadsheet with three columns: location, classification (active or historical), planned remediation. Write the policy that explicitly forbids each future occurrence ("staff may not accept plaintext VCC details by email; OTAs must use the secure extranet"). This phase produces three deliverables: a card data flow diagram, a discovery register, and a written CHD-handling policy.
Days 16 to 45: Reduce scope to SAQ A
For each active card data flow that touches a hotel system, architect it onto the tokenizer instead. If your booking engine renders the payment form on your domain, switch to the processor's iframe-hosted payment page (most processors offer both options; ask). If your front desk takes phone-in card numbers and types them into a virtual terminal, ensure that virtual terminal is hosted by the processor and not by the hotel. If your group sales team accepts VCC details by email, switch the deposit collection to the processor's secure link product. Shred the historical card data discovered in Phase 1 (paper to the locked shredder bin, electronic to secure deletion with audit log). At the end of this phase, your card data flow diagram should show every card number entering and leaving the processor's environment without ever touching a hotel-owned system. That is the architecture that lets you file an SAQ A.
Days 46 to 75: Implement the controls SAQ A still requires
SAQ A is small but it is not empty. The 30 controls cover staff access management, vendor management of your TPSPs, security awareness training, and (under v4.0.1's January 2025 update) the e-skimming attestation. Do the following: enable MFA on every cloud account that touches the booking engine, payment gateway, or PMS. Document the TPSPs you use, retrieve their current PCI Attestation of Compliance (each should publish or share theirs), and store these in a vendor management folder with annual renewal reminders. Roll out role-specific security awareness training (front desk, back office, IT) using a hosted tool like KnowBe4, Hoxhunt, or a free equivalent. Implement script tamper-detection on the booking page (Visualping, Feroot, or a custom CSP-with-monitoring setup) and write the alert escalation procedure. Deploy or contract for quarterly ASV scans of your external IP addresses (if you have any; for a fully SaaS hotel this may be effectively zero scope).
Days 76 to 90: File the SAQ A and attest
Complete SAQ A v4.0.1 using the templates from the PCI SSC website. Have the GM or owner sign Part 3a of the Attestation of Compliance. Submit the AoC plus the most recent passing ASV scan report to your acquiring bank via whatever portal they specify. Confirm receipt. Set calendar reminders for the next annual SAQ, the quarterly ASV scans, the semi-annual scope confirmation review (12.5.2.1 if you are a service provider, annually otherwise), the role-specific training renewal, and the TPSP AoC renewal cycle. This is the work that ages your program forward without anybody having to re-discover the whole thing in a year.
Where Prostay Fits, Briefly and Honestly
I write for Prostay so this section is unavoidable, but I will keep it honest. Prostay Pay is a tokenizing payment processor that is built to keep your hotel inside SAQ A scope by default. When a guest pays through the Prostay booking engine or the front desk takes a card via the Prostay POS, the card number itself never travels through the Prostay PMS database; only a token reference does. That architecture is what makes the SAQ A path possible for an independent hotel using Prostay, and it is the same architecture that Stripe, Adyen, Mews Payments, Cloudbeds Payments, and Profitroom Payments offer. Pick any of them, including the non-Prostay options, and you can be on the SAQ A path within 90 days. Pick a processor that integrates by pushing card numbers into your PMS, and you are on the SAQ A-EP or SAQ D path with all the cost and complexity that implies.
The specific Prostay choices that matter for PCI: the booking engine uses an iframe-hosted checkout that meets the SAQ A "every element of the payment page originates only and directly from a PCI DSS-compliant TPSP" criterion; the API never returns PAN data to integrations; the OTA email integration parses VCC details inside the Prostay environment and only ever surfaces the tokenized reference back to the hotel front office. None of this is unique to Prostay. It is, however, easier to get right when the booking engine, PMS, and tokenizer share an audit boundary, which is the actual structural argument for choosing a single-vendor stack over a best-of-breed assembly.
If you want a more in-depth view of how Prostay Pay specifically handles tokenization and the PCI SAQ A architecture, the Prostay Pay product page walks through it. If you are migrating from a legacy PMS with card data stored in the database (which puts you in SAQ D scope by definition), the Prostay PMS migration playbook covers the data-removal step. And if you want help running the 90-day plan above with our payments team on a call, book a demo and we will walk through it without trying to sell you a separate compliance consulting engagement.
Frequently Asked Questions
The five questions I get most often from independent hoteliers about PCI DSS 4.0.1, answered with the actual published rule rather than the trade-press summary of it.
