Thai Hotel PDPA, Passport, TM30: 7-Point Checklist

A passport image is not just another attachment. It can contain a name, photograph, nationality, date of birth, document number and other information that deserves deliberate handling.

Thailand welcomed more than 18.5 million foreign tourists between 1 January and 1 August 2026, according to the Ministry of Tourism and Sports—and under Section 38 of the Immigration Act, essentially every one of those stays at a hotel triggers a TM30 notification obligation within 24 hours. That's 18.5 million passport images, names, and stay records that had to move through some hotel's check-in process this year alone, digital or not.

It sounds like a legal compliance checklist—collect the required fields, file the required form, done. It is actually a data-minimization design problem: the goal is not to collect every field a scanner can detect. It is to support a lawful hotel process with the least unnecessary exposure.

This article walks through seven practical points for handling passport data safely, from mapping why each field is collected through to incident response—plus a pre-launch checklist you can run before going live.

Collect what the hotel genuinely needs, protect it while needed, and prove who used it.

This article is an operational checklist, not legal advice. Have your legal or privacy adviser confirm the lawful basis, notices and retention periods for your property. For the broader implementation—guest journey, integrations, and ROI—see our 2026 guide to hotel self-check-in in Thailand.

1. Minimum Viable Capture: map why each field is collected

Before anything else, apply what's worth calling Minimum Viable Capture—the discipline of collecting only the fields a specific, documented purpose actually requires, rather than everything a scanner or form builder makes technically possible.

Create a simple register with the field, purpose, legal or contractual basis, source, system, access roles, recipient and retention rule. Do this for passport image, passport number, nationality, birth date, address, contact details, signature, payment reference and stay record. "The old form asked for it" is not a purpose.

Separate information needed for accommodation operations from information wanted for future marketing. A guest completing check-in should not be forced into unrelated promotion permission.

2. Give a clear privacy notice

The guest should understand who controls the data, why it is used, who may receive it, how long it is kept, how it is protected at a practical level and how to exercise applicable rights.

Write for a tired traveller on a phone. Use layered information: a short summary before collection and a full notice one tap away. Provide Thai and English, then prioritize other languages based on guest mix and review them with fluent editors.

The Government Platform for PDPA Compliance (GPPC) publishes privacy-notice materials that can help teams understand the structure, but a hotel still needs a notice fitted to its own processing. GPPC: Government Platform for PDPA Compliance

3. Design the TM30 responsibility explicitly

Under Section 38 of Thailand's Immigration Act, a hotel manager accommodating a foreign national must notify local immigration authorities within 24 hours of arrival, and the Immigration Bureau's online system supports both individual notification and spreadsheet import. Thailand Immigration Bureau: TM30 online system

Document who checks the guest information, who corrects scanner errors, who prepares or imports the notification, who confirms successful submission, and who stores evidence and handles failed submissions. Do not claim that a vendor integrates directly with TM30 unless the integration and operating responsibility are verified—requirements and interfaces can change, so verify the current official system before publication or implementation.

4. Protect capture and transmission

Whether you capture this on a lobby kiosk or a guest's own phone changes the risk profile—see our comparison of self-check-in kiosk vs mobile check-in for the trade-offs up front.

Use an encrypted connection and a short-lived, reservation-specific link. Do not ask guests to send passport photographs through ordinary email or chat when a controlled upload is available. The capture screen should prevent accidental exposure in a lobby. Mask sensitive values after confirmation. Avoid storing images on a shared tablet, photo gallery, downloads folder or receptionist's personal device.

Validate extracted fields, but do not assume optical character recognition is always correct. A wrong document number submitted faster is still wrong.

5. Limit staff access

Reception may need to review arrival details. Marketing usually does not need passport images. Technology support may need logs without seeing the underlying document.

Use role-based access, individual accounts and multi-factor authentication where available. Remove access promptly when roles change. Record viewing, editing, exporting and deletion of sensitive records. Shared passwords feel convenient until nobody can explain who exported 300 documents on Tuesday.

6. Set retention and deletion rules

Retention should follow verified legal, tax, contractual and dispute requirements—not storage capacity. Define different periods for raw passport images, extracted fields, registration records, operational logs and marketing data.

Automate deletion only after testing legal holds, failed jobs, backups and connected systems. A deletion button that removes the visible record but leaves five exports is a user-interface feature, not a retention program.

7. Prepare for incidents and guest requests

Write a short playbook for a lost device, exposed link, suspicious export, wrong-recipient message or compromised staff account. Include containment, evidence preservation, internal escalation, assessment and required communications.

Picture a hypothetical 36-room boutique hotel in Hua Hin called Baan Rak Talay—a fictional property, used only to illustrate the point. During a Minimum Viable Capture review, Baan Rak Talay discovered its check-in flow was still capturing a full passport photo page for every guest, even though its TM30 filing and identity verification only ever used four fields from it: name, nationality, passport number, and date of birth. Nobody had decided to over-collect—the field had simply never been switched off after being copied from a template built for a different property. That single unused field, sitting untouched in storage for months, was the exact kind of exposure a genuine incident playbook exists to have prevented from mattering.

Also define how staff recognize, route and complete data-subject requests. Keep identity verification proportionate; do not solve a privacy request by collecting another unnecessary passport copy.

The Minimum Viable Capture Playbook

Justify Every Field — if you can't write one sentence explaining why a field is collected, it shouldn't be on the form; that's how Baan Rak Talay found its unused passport page.
Shrink Before You Secure — encryption and access control matter, but the cheapest protection for a field is not collecting it in the first place.
Review on a Schedule, Not Just at Launch — templates copied between properties or vendors quietly drift; put a repeat date on the field-by-field review, not just a one-time audit.
Apply Minimum Viable Capture Beyond Passports — the same discipline applies to any form; a spa intake form that asks for a client's full medical history when it only ever uses "known allergies" and "current medications" is collecting the same kind of unnecessary exposure a passport scanner does.

Minimum: the one word this comes down to

If there's one word for handling passport data responsibly, it's Minimum—not the most secure-sounding vendor, not the most impressive-looking form, just the smallest set of fields that still does the job.

So here's the question worth sitting with: pull up your own check-in form right now and count the fields. For each one, could you say in one sentence why it's there—or would some of them survive only because nobody has asked yet?

Frequently asked questions

Is scanning a passport always required for Thai hotel check-in?

The hotel needs enough information to support TM30 notification and its own registration process, but that doesn't automatically mean storing a full image forever—confirm with your legal adviser exactly which fields and retention period your process actually requires.

Who is legally responsible if a TM30 notification is late or wrong?

The obligation sits with the hotel manager or accommodation provider, not a software vendor. A vendor can prepare data and exports, but verified human responsibility for checking and submitting should stay assigned to a named role.

Can we store passport images indefinitely "just in case"?

No—retention should follow documented legal, tax, contractual and dispute requirements, not open-ended convenience. Longer storage is more exposure, not more protection.

Does mobile check-in or a kiosk change our PDPA obligations?

The underlying obligations are the same, but the risk profile differs by channel—a kiosk in a public lobby and a guest's personal phone need different safeguards against accidental exposure.

What's the fastest way to reduce our privacy risk this month?

Run the Minimum Viable Capture review first: list every field your current form collects and cut anything without a one-sentence justification, before you spend time on encryption or access policy for fields you didn't need to collect at all.

Not sure where your own data exposure actually sits? NAWA's hotel self-check-in product is designed around clear consent and secure handling by default, rather than scattered spreadsheets and shared tablets—which covers a meaningful part of points 4 and 5 above. Talk to us about a data-flow review to map where guest information enters, moves, waits, and leaves your check-in workflow.

Sources reviewed

Information and links were reviewed on 12 August 2026.

PDPA, Passport Data, and TM30: A 7-Point Digital Check-in Checklist for Thai Hotels