Every hotel tech sales call eventually reaches the privacy question. A revenue manager asks where guest data lives, an IT director sends a questionnaire, or a group's procurement team asks for a data processing agreement before the pilot. The answers vendors give in that moment are often borrowed from a competitor's website or a founder's half memory of a compliance webinar. Some of them are wrong, and buyers who have dealt with regulators can tell.

This post takes seven myths hotel tech vendors repeat about GDPR and PCI DSS and checks each one against what the regulators and standards bodies actually publish. It is not legal advice. It is a guide to the claims that cost credibility in a deal, with links to the primary sources so your team can read them directly and check with counsel before changing a contract.

A working definition to keep in mind: a privacy claim is sales-safe when a hotel's IT or legal reviewer could check it against a regulator's own text and find it accurate. Everything below fails or passes that test.

Myth 1: "We are GDPR certified"

Reality: certification under the GDPR exists, but it is narrow. Article 42 of the GDPR provides for certification mechanisms approved by a supervisory authority or the European Data Protection Board, and it states plainly that certification does not reduce the responsibility of the controller or processor for compliance. A vendor cannot award itself a GDPR badge, and a SOC 2 report or ISO 27001 certificate is not a GDPR certification either.

What to say instead: name the specific evidence you have. "We have a SOC 2 Type II report, a signed data processing agreement template and a published sub-processor list" is checkable. "GDPR certified" invites the reviewer to ask which scheme, and most vendors have no answer. Our guide to whether hotel software needs SOC 2 covers what that report does and does not prove.

Myth 2: "The hotel is the controller, so privacy is their problem"

Reality: processors carry their own obligations. The ICO's guidance on controller and processor contracts lists the minimum terms Article 28(3) requires: processing only on documented instructions, a duty of confidence, security measures meeting Article 32, rules on sub-processors, help with data subject rights, deletion or return at the end of the contract, and audits. The ICO also notes that both controllers and processors are obliged under Article 32 to put appropriate security measures in place.

The role can also shift. The ICO says that if a processor acts outside the controller's instructions and decides the purpose and means of processing, it will be considered a controller for that processing, with the same liability. A vendor that reuses guest data across hotels to train a pricing or upsell model should look hard at that line. The EDPB's Guidelines 07/2020 on controller and processor, final version adopted in July 2021, are the reference most hotel group legal teams will use.

Myth 3: "We use a payment gateway, so PCI does not apply to us"

Reality: the PCI Security Standards Council answers this directly in an FAQ on outsourced payment processing. When an entity outsources processing and never stores, processes or transmits cardholder data, many requirements may not apply directly. But the Council says this does not remove the responsibility to make sure account data is protected by the third party.

The FAQ lists what remains: confirming the provider is PCI DSS compliant for the services offered, keeping written agreements that acknowledge responsibilities under Requirement 12.8.2, monitoring the provider's compliance status at least annually under Requirement 12.8.4, and clearly defining shared responsibilities. Merchants still validate compliance, typically through a Self-Assessment Questionnaire such as SAQ A. For a booking engine or guest payment tool, "we tokenise through our gateway" is a good start to the answer, not the whole answer.

Myth 4: "PCI DSS 4.0 is just the old standard with a new number"

Reality: the PCI SSC says version 4 added 64 new requirements, and 51 of them were future-dated and effective as of 31 March 2025. Those dates have passed. Two of them, Requirements 6.4.3 and 11.6.1, are what the Council calls e-commerce security requirements for payment page security. In January 2025 it removed them from SAQ A but added an eligibility criterion that merchants confirm their site is not susceptible to attacks from scripts, and stressed that the change does not remove the underlying requirements. That matters to any vendor hosting a booking engine checkout.

If your security page or sales deck still says "PCI DSS 3.2.1 compliant", update it. Hotel IT reviewers notice stale version numbers, and it suggests the rest of the answers may be stale too.

Myth 5: "Hosting in the US means we cannot sell to European hotels"

Reality: transfers need a valid mechanism, not an EU postcode. On 10 July 2023 the European Commission adopted its adequacy decision for the EU-US Data Privacy Framework, under which personal data can flow freely from the EU to US companies that participate in the framework. The Commission also says the US national security safeguards apply to all GDPR transfers to US companies regardless of the mechanism used, which supports standard contractual clauses as well.

The opposite myth is just as common: "we are on AWS Frankfurt, so there are no transfers." If your support team in another country can access guest records, or a US sub-processor handles email or analytics, there may still be transfers to document. List them on your sub-processor page and in your answers to the hotel security questionnaire.

Myth 6: "Breach notification is the hotel's job, not ours"

Reality: it is both. Article 33 of the GDPR requires the controller to notify the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a breach. Article 33(2) requires the processor to notify the controller without undue delay after becoming aware of it. The hotel's 72 hour clock depends on how fast its vendor speaks up.

That is why hotel groups ask for a contractual notification window and a named security contact. Vendors who answer with a specific internal process, owner and timeframe move through procurement faster than vendors who answer "we comply with GDPR".

Myth 7: "Old data inherited from an acquisition is the previous owner's problem"

Reality: the Marriott case says otherwise. The ICO's penalty notice of 30 October 2020 records that Marriott acquired Starwood in 2016 and did not detect the attack on Starwood's systems between the acquisition and September 2018. Marriott estimated that 339 million guest records were affected, of which 30.1 million were EEA records and 7 million were associated with the United Kingdom. The ICO imposed a penalty of £18.4 million.

Hotel tech is consolidating, and buyers now ask about it. If your company has acquired a product or been acquired, expect questions about how legacy guest data was migrated, retained or deleted. Our post on what hotels worry about when their software changes ownership covers the commercial side of that conversation.

Myth and reality at a glance

How to turn privacy from an objection into a proof point

1. Publish a trust page with your sub-processor list, hosting regions, transfer mechanism and current PCI DSS version.

2. Keep a data processing agreement ready that maps to the Article 28(3) terms the ICO lists, so legal review starts from your paper.

3. Write one approved answer for each myth above and train sales and customer success to use it word for word.

4. Give every answer an owner and a review date, because standards change and stale answers are how myths spread.

5. Add the trust page to your RFP response library and your onboarding pack.

Privacy answers sit in the trust layer of the hotel tech GTM system. Vague claims slow procurement, while precise ones shorten it, especially with the hotel IT directors who now sit in most group buying decisions.

If deals keep stalling at the security and privacy review, our free GTM leak audit will show where in your sales process the trust gap is costing you, before the next questionnaire arrives.

Frequently Asked Questions