Concrete compliance setup for hotels using WhatsApp — Meta's data flows, GDPR lawful basis, PCI-scope avoidance, retention rules, and the contracts you actually need.
Every European hotel group we speak to lands on the same question within ten minutes of any WhatsApp conversation: "is this even legal?" Yes, with conditions. WhatsApp can be operated inside GDPR and PCI rules. It needs the right contracts, the right data flows, and a few hard rules staff are not allowed to break.
What's at stake is not theoretical. The Irish DPC fined Meta €1.2bn in 2023 over Schrems II transfers. Booking.com was fined €475,000 by the Dutch DPA in 2021 for late breach disclosure. Hotels themselves rarely get headline fines. They regularly fail audits, lose corporate accounts that require GDPR attestation, and end up with PCI scope they did not budget for. A bad WhatsApp setup can also bleed into ICO, CNIL or Garante complaints from a single guest who feels their messages were mishandled.
This is a playbook, not legal advice. Run the checklist past your DPO or counsel before anything goes live. We've written it for GMs, IT leads and group ops directors who want a concrete document to hand to legal, rather than a vague "we use a compliant vendor" reassurance. For the broader cost picture, see our WhatsApp costs for hotels pillar.
Before any compliance discussion, list the data. In a typical European hotel WhatsApp setup, the channel carries:
Allergies and accessibility data are special category data under GDPR Article 9. Passport images are identity documents. Complaints about a sick child are health data. WhatsApp is not a low-stakes channel just because it feels casual to guests.
For how this data interacts with the rest of your stack, see integrations and APIs in the hotel tech stack. The PMS, the messaging vendor, and any AI layer all touch this data, and your record of processing activities (Article 30) needs to reflect that.
The most common mistake we see is hotels claiming consent (Article 6(1)(a)) for everything. Consent is the weakest basis. It must be freely given, specific, informed and unambiguous, and the guest can withdraw it at any time. If you're sending a check-in message to someone who just booked through Booking.com, consent is the wrong basis.
Use this for transactional messaging tied to the reservation. Check-in instructions, key code delivery, room-ready notifications, departure reminders, invoice links. The guest entered into a contract by booking. Sending the messages required to fulfil that contract is lawful without separate consent.
Use this for service-improvement messages, post-stay feedback requests, and operational alerts that are not strictly contractual but are reasonably expected. Run a Legitimate Interests Assessment (LIA) and document it. Guests must be able to object easily.
Reserve consent for marketing. Promotional offers, newsletter-style content, retargeting messages: these need an explicit opt-in, captured before the message goes out, with a clear withdrawal mechanism. Pre-ticked boxes do not work. The 2020 Planet49 ruling killed that pattern.
Hotels that try to run everything under consent end up with low opt-in rates and operational pain when guests withdraw. Splitting bases by message type is more work upfront and far less work in production.
WhatsApp itself is operated by Meta Platforms Ireland Limited for European users. You also use a Business Solution Provider (BSP) like Twilio, 360dialog or MessageBird. If you're running an AI layer, that's another processor.
Meta acts as a processor for the message content sent through WhatsApp Business API. Their terms include data processing terms by reference. You don't sign a separate paper DPA with Meta. The agreement is your BSP terms plus Meta's WhatsApp Business Solution Terms. Keep a copy of both versions you accepted.
Twilio, 360dialog and MessageBird all publish their own DPAs. Sign them. Confirm sub-processors (they will list AWS, GCP, sometimes Azure regions). Check whether the BSP processes your data inside the EU or routes through the US. 360dialog is an EU-headquartered option that some hotels prefer for residency reasons.
If you run an AI Operator like Viqal on top of WhatsApp, you need a DPA with that vendor too. Look for: EU data residency, named sub-processors (the LLM provider matters here), retention defaults, and the deletion process. Read more in our data security and compliance guide.
A guest emails your DPO asking for all their personal data. WhatsApp logs are now in your BSP, the AI vendor's database, possibly your CRM, and Meta's servers. Article 15 (access), Article 17 (deletion) and Article 20 (portability) all apply.
Build a DSAR runbook before you need it. Steps that work:
Deletion is harder. You can't purge the WhatsApp thread on the guest's device. Make that limitation clear in your privacy notice. You delete server-side, but the guest's phone still holds the thread until they delete it themselves.
One more rights issue: Article 22 on automated decision-making. If your AI Operator is making decisions that affect the guest (price changes, room assignments, refusals), flag that in the privacy notice and offer a human-review path. Most hotel AI use is assistive rather than fully automated, but check with your DPO. The line between "AI drafts a reply, human approves" and "AI sends a reply directly" matters.
The PCI DSS rule is simple: if cardholder data passes through your systems, those systems are in scope. WhatsApp is not different. If a guest types a 16-digit card number into a chat and your staff or BSP can read it, you've just expanded PCI scope to cover WhatsApp, your BSP, your AI layer, and any agent who saw the thread.
This is why the single most important rule in any hotel WhatsApp policy is: never accept card numbers in chat. Not from guests, not from staff. If a guest sends one, treat it like a security incident. Delete server-side, ask the guest to use a payment link, and document the event.
The pattern that works: send a link to a hosted payment page run by a PCI-compliant provider. Mews Payments, Stripe, Adyen, Worldline and Stripe-equivalent regional gateways all support this. The guest's card data goes directly to the gateway, never touches WhatsApp, never touches your BSP, never touches your AI vendor. You receive a token or a payment confirmation back via webhook.
Done right, this keeps you on SAQ A — the lightest PCI self-assessment questionnaire. Done wrong (where staff occasionally type card numbers into chat to "help" guests) you slide into SAQ A-EP or worse, and your QSA will not be amused.
You have three retention clocks to reconcile:
A workable pattern: keep the live message log in your BSP for 90 days, archive structured records (guest name, dates, amounts, reservation reference) in your PMS for the legal retention period, and purge free-text content after 12 months unless a dispute is open. Document the schedule. Article 5(1)(e) requires storage limitation; "we keep everything forever" is not a defensible position.
Schrems II killed Privacy Shield in 2020. Standard Contractual Clauses (SCCs) plus a transfer impact assessment are now the working pattern for any data flow to the US. Meta's 2023 fine was about exactly this issue.
What changed in 2024: Meta brought EU user data into European data centres for several Meta products. WhatsApp Business message content routing has shifted, but it's not a one-line answer — check the current Meta data residency documentation for your specific BSP setup. Don't assume EU residency without confirming.
For your AI layer, ask three questions: where is the application hosted, where is the LLM inference run, and is any training done on your guest data? "No training on customer data" should be in the contract. Inference region matters because some providers route to US regions by default.
Run through this with your DPO before launch. Each item should have an owner and a documented answer.
| # | Item | Owner |
|---|---|---|
| 1 | WhatsApp Business Solution Terms accepted and version archived | IT |
| 2 | BSP DPA signed (Twilio / 360dialog / MessageBird) | Legal |
| 3 | AI vendor DPA signed with named sub-processors | Legal |
| 4 | Sub-processor list maintained and reviewed quarterly | DPO |
| 5 | Article 30 record of processing updated to include WhatsApp flows | DPO |
| 6 | Lawful basis mapped per message type (contractual, LI, consent) | DPO |
| 7 | Legitimate Interests Assessment documented for 6(1)(f) messages | DPO |
| 8 | Privacy notice updated, mentions WhatsApp explicitly | Marketing & DPO |
| 9 | Opt-out mechanism tested (STOP keyword honoured) | Ops |
| 10 | DSAR runbook covering BSP and AI vendor exports | DPO |
| 11 | Deletion runbook with vendor APIs documented | IT |
| 12 | Retention schedule for message content (e.g., 12 months) | DPO |
| 13 | Staff training: never accept card numbers in chat | GM |
| 14 | Payment link flow uses PCI-compliant gateway (Mews / Stripe / Adyen) | Finance |
| 15 | SAQ A confirmed with acquirer | Finance |
| 16 | Incident response plan covers WhatsApp data breach scenarios | IT & DPO |
| 17 | EU data residency confirmed for BSP and AI vendor | IT |
| 18 | SCCs + Transfer Impact Assessment on file for any non-EU flows | Legal |
| 19 | Templates approved by Meta and reviewed for compliance language (see WhatsApp templates for hotels) | Marketing |
| 20 | Annual review scheduled with DPO and IT | DPO |
Long list. Every item is something an auditor or a curious DPA inspector might ask about. Having the answer ready in a folder beats finding out during an investigation that nobody documented the LIA two years ago. Property-level GMs are usually fine with the rules. It's keeping the front-desk muscle memory aligned that takes ongoing work. Run the card-numbers-in-chat training every six months, not once at onboarding.
We built Viqal with European hotels in mind. EU hosting, named sub-processors, no training on guest data, retention controls you set per property, and a DSAR export endpoint that returns a structured per-guest record. We've also published our security and compliance position, which is Part 10 of our hotel tech stack series.
None of that removes your obligations as the data controller. You still own the lawful basis decisions, the privacy notice, and the DSAR responses. What we try to do is reduce the contractual and technical surface area you have to worry about, so the WhatsApp channel feels like a normal supplier relationship rather than a compliance landmine.
For the broader operational and cost picture, the WhatsApp costs for hotels pillar walks through pricing, conversation categories and ROI maths. Compliance and cost are two sides of the same setup decision. Get the contracts right and the rest follows.
.avif)
Not always. Transactional messages tied to the reservation (check-in, key codes, departure reminders) sit under GDPR Article 6(1)(b), performance of a contract. Service messages can sit under 6(1)(f) legitimate interest with a documented LIA. Reserve explicit consent under 6(1)(a) for marketing and promotional content, with a clear opt-in and easy withdrawal.
No. Accepting raw card data in chat drags WhatsApp, your BSP and your AI layer into PCI scope. Use tokenised payment links instead, sent via WhatsApp but pointing to a hosted page run by Mews Payments, Stripe, Adyen or a similar PCI-compliant gateway. Train staff to never type card numbers into chat, even when guests ask.
It depends on the message type. Booking confirmations and check-in instructions usually rely on Article 6(1)(b) contractual necessity. Operational alerts and feedback requests often work under 6(1)(f) legitimate interest with a Legitimate Interests Assessment on file. Marketing requires Article 6(1)(a) consent with a specific opt-in. Map each message type to a basis and document it.
Three clocks apply: Meta's own retention defaults, your operational needs (typically 90 days to 12 months), and tax-law obligations on invoice records (7–10 years depending on jurisdiction). A common pattern is 90 days live in the BSP, 12 months for free-text content, and structured invoice data archived in the PMS for the statutory period. Document the schedule.
Yes. Twilio, 360dialog, MessageBird and other Business Solution Providers each publish their own DPA, separate from Meta's WhatsApp Business Solution Terms. Sign it, confirm the sub-processor list, check the data residency, and keep both documents on file. If you also use an AI vendor on top, that's a third DPA. Your DPO needs all three.
Meta moved more EU user data into European data centres during 2024, partly in response to the €1.2bn Schrems II fine in 2023. WhatsApp Business routing has shifted, but the picture varies by BSP setup. Don't assume full EU residency. Check the current Meta data residency documentation, your BSP's processing locations, and update your transfer impact assessment accordingly.
.avif){kind=spacer}
