Your data, their booking: privacy law across the guest journey

Same data, four systems, three distinct legal regimes. Let's take them one at a time.

GDPR: the EU's data protection law

GDPR (General Data Protection Regulation) is the EU regulation governing personal data of anyone in the EU, regardless of where the company processing it is based. It applies because our guest is a German resident, even though the hotel is in Miami. This extraterritorial reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → is GDPR's defining feature and the one hospitality companies most often underestimate.

Key obligations relevant to the booking chain:

• Lawful basis for processing. The hotel needs a legal reason to hold her passport number (typically "legal obligation," since many countries require guest ID logging) or "contract performance" for the booking itself.
• Data minimization. Collect only what's needed. A passport number for a domestic US guest booking domestically is usually unjustifiable; requesting it anyway invites regulatory risk.
• Right to erasure and access. She can request her data be deleted or ask what's held, and the hotel and OTA must respond, typically within one month.
• Cross-border transfer rules. Moving her data from an EU-based OTA server to a US-based loyalty database triggers additional safeguards (standard contractual clauses, adequacy assessments).
• Breach notification. A leak must be reported to the relevant supervisory authority within 72 hours.

Enforcement sits with national Data Protection Authorities (DPAs), like Ireland's Data Protection Commission, which oversees many US tech and travel platforms with EU operations. Fines can reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → up to 4% of global annual revenue, a figure that has produced real, multi-million-euro penalties against major platforms in past cases (see the European Data Protection Board's enforcement records).

CCPA: California's parallel but different regime

CCPA (California Consumer Privacy Act, amended and expanded by the CPRA, California Privacy Rights Act) governs personal data of California residents. If our traveler were a Californian instead of a German, this is the law in play once the hotel or OTA meets revenue or data-volume thresholds.

CCPA differs from GDPR in important ways professionals should not blur:

• It's an opt-out model for data sales/sharing, not GDPR's opt-in consent standard. The hotel can process her data by default; she must actively exercise rights to stop certain uses (like sale to third-party marketers).
• Right to know and delete exist, similar in spirit to GDPR, but procedural mechanics differ (verified consumer requests, specific response windows).
• No single strict cross-border transfer regime like GDPR's; the concern is more about disclosure to third parties and sale of data, relevant if the hotel shares her loyalty profile with an ad-tech partner.
• Enforcement comes from the California Privacy Protection Agency (CPPA), a dedicated regulator created by CPRA, distinct from the more generalized US Federal Trade Commission (FTC), which handles privacy issues nationally where no state-specific law applies.

Practical effect for a hotel chain: the same loyalty database often needs two separate consent and disclosure workflows, one GDPR-compliant for EU guests, one CCPA-compliant for California guests, because neither law treats the other as sufficient in isolation.

PCI-DSS: the card number's own rulebook

PCI-DSS (Payment Card Industry Data Security Standard) is not government law. It's an industry-mandated security standard, enforced through contracts with card networks (Visa, Mastercard, Amex) rather than through DPAs or attorneys general. Any entity that stores, processes, or transmits card data, OTA, hotel, payment gateway, must comply.

Core requirements relevant to our booking:

• Never store the CVV (card verification value) after authorization, full stop.
• Encrypt card data in transit and at rest.
• Restrict access to card data on a need-to-know basis (a front-desk agent shouldn't be able to query the full card database).
• Regular vulnerability scanning and penetration testing of any system touching card data.
• Tokenization, replacing the actual card number with a surrogate tokentokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.View full definition → wherever possible, so the PMS and loyalty database never need to hold the real number at all.

Compliance is validated through Self-Assessment Questionnaires (SAQs) for smaller merchants or annual audits by a Qualified Security Assessor (QSA) for large-volume processors. Non-compliance doesn't bring government fines; it brings card network penalties, increased transaction fees, and potential loss of the ability to accept cards at all, an existential threat for any hotel or OTA.

The PCI Security Standards Council publishes the current standard (PCI-DSS v4.0, phased in through 2025) and self-assessment tools free of charge.

Where the three regimes collide

The passport number is GDPR's concern (personal data, EU rules on necessity and retention). The card number is PCI-DSS's concern (security standard, no personal-data threshold). The email and stay history in the loyalty database can be either GDPR's or CCPA's concern, depending on guest residency, often both if the chain operates globally.

A single data breach at the PMS level, say, an unencrypted database exposed to the internet, can trigger all three regimes simultaneously: GDPR breach notification to a DPA, CCPA notification to affected California residents, and a PCI forensic investigation by the card networks. Three different regulators, three different timelines, three different penalty structures, one incident.

Practical takeaways for hospitality operators

For a compliance-minded revenue manager or GMGMGross margin is the share of revenue left after subtracting the direct cost of producing goods or services, expressed as a percentage of revenue.View full definition →, the sector-specific playbook looks like this:

• Map data flows, not just data fields. Know not just what you collect but which system it lands in and which jurisdiction that system sits in.
• Tokenize early. The less raw card data your PMS and CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.View full definition → actually touch, the smaller your PCI-DSS audit scope.
• Segment consent by residency. A single "accept cookies" banner cannot satisfy both GDPR's opt-in standard and CCPA's opt-out model; global chains run parallel consent logic.
• Treat passport and ID data as high-risk, not routine. It's often collected for local hotel registration laws but rarely needs to sit in a loyalty database years later.

🎬 [VIDEO: "GDPR Explained in Simple Terms" - youtube.com/results?search_query=gdpr+explained+simple+terms - a plain-language walkthrough of GDPR's core principles, useful as a refresher before applying them to booking data flows]

Key Takeaways

• GDPR governs personal data of EU-based individuals globally, requires a lawful basis and minimization, and is enforced by national DPAs with fines up to 4% of global revenue.
• CCPA/CPRA governs California residents' data under an opt-out model, enforced by the CPPA, and is procedurally distinct from GDPR even when protecting similar rights.
• PCI-DSS is an industry standard, not law, applying to card data specifically regardless of guest nationality, enforced through card network contracts rather than regulators.
• A single reservation routes personal and payment data through OTA, PMS, and loyalty systems, each potentially subject to a different regime, so one breach can trigger multiple simultaneous compliance obligations.
• The practical fix is architectural: tokenize card data, minimize retention of sensitive fields like passport numbers, and run jurisdiction-aware consent logic rather than a single global privacy policy.