A company in Thailand wants to combine online bookings, customer support records and marketing information. Each team already has access to part of the data. The proposed integration seems like a technical task until someone asks whether all those records can be used together.

That question brings the purpose, legal justification, notices, access and retention arrangements into view. The organisation needs to understand both what the new system does and what the law permits.

Thailand’s PDPA provides the starting framework. A practical implementation connects its requirements to the actual services and decisions involved.

What is Thailand’s PDPA?

The formal title is the Personal Data Protection Act, B.E. 2562 (2019). B.E. 2562 is the Buddhist Era year corresponding to 2019, rather than a separate serial law number. Thailand’s Ministry of Digital Economy and Society lists the Act and related legal instruments.

The abbreviation PDPA is also used in Singapore and Malaysia, but Thailand has its own law and implementing notifications. A regional policy therefore needs country-specific checks.

The ministry provides an English translation for reference. The Thai legal text and applicable notifications should be used to resolve questions of interpretation.

Does the law reach overseas organisations?

Section 5 covers processing by controllers or processors in Thailand, including where their collection, use or disclosure takes place elsewhere. It can also apply to overseas parties when their activities involve offering goods or services to individuals in Thailand or monitoring behaviour occurring there. See the government-hosted English translation.

This means an overseas office address does not, by itself, settle applicability. Consider the activity, the people concerned and the territorial tests, together with relevant exclusions.

For the booking example, document where customers are, how the service is offered and which entities operate the platform. Include remote support and service providers in the review so that the analysis follows the actual processing arrangements.

Identify a lawful route for each purpose

Consent is one route, but the Act also provides circumstances permitting processing without consent. Section 24 addresses grounds for collecting ordinary personal data without consent; section 26 addresses sensitive information, while section 27 connects these provisions to use and disclosure. The National Research Council’s reproduction of the Act is a useful reference.

The implementation task is to identify the relevant provision and show how its conditions are satisfied. Avoid collecting consent automatically without examining whether it is appropriate for the activity.

In the booking example, distinguish processing needed to administer a reservation from optional marketing or new behavioural analysis. Write down the purpose of each activity before deciding which legal route applies. A purpose that is too broad will make later decisions about access and retention harder.

Where consent is used, examine the request and withdrawal experience from the individual’s perspective. Can someone understand what they are agreeing to? Can the organisation find the record of that choice? Will a withdrawal reach the systems that actually send messages?

Sensitive data needs additional attention

The Act gives particular treatment to categories such as health, genetic and biometric information, as well as other sensitive categories specified in section 26. Explicit consent or an applicable statutory exception needs to be considered under that provision.

A useful operational distinction is between information that is convenient to collect and information that the process actually needs. A booking service might need an accessibility arrangement without needing an unrestricted free-text medical history.

My practical recommendation is to review forms and attachments together. Restricting a few database fields will achieve little if staff routinely upload unstructured documents containing much more information. Consider access, search results, exports and support screenshots as part of the same review.

Give people information and usable request channels

A privacy notice should reflect the actual processing. Check whether it explains the relevant purposes, recipients, retention approach and contact route, and whether staff can apply what it says.

The Act provides rights including access and, in applicable circumstances, portability, objection, erasure and restriction. These rights have conditions and exceptions; a request should receive an assessment rather than an automatic promise or refusal.

For a practical test, ask a colleague to trace one fictional customer across the booking system, support inbox and marketing platform. Identify who can retrieve or correct each copy and who approves the response. This is a workflow exercise, not a reason to circulate additional real customer data.

The exercise often reveals that a well-written notice depends on undocumented manual work. Record that work and give it an owner.

Security, retention and breaches

Section 37 requires appropriate security measures and arrangements addressing retention and deletion. It also requires notification of a breach to the competent Office without delay and, where feasible, within 72 hours of awareness, unless the breach is unlikely to create a risk to individuals’ rights and freedoms. Where high risk is likely, affected individuals must also be notified without delay. Thailand’s Department of Physical Education reproduces these provisions in its controller guidelines.

A practical incident procedure should identify who assesses risk, who contacts the regulator and how suppliers report problems. Record discovery and awareness times, affected information, containment actions and the notification decision.

For retention, make deletion operational. Identify how long information remains in live systems, exported reports and archived folders, and how applicable legal exceptions will be handled. Periodically test whether the system can carry out the approved decision.

Suppliers, transfers and accountability

Overseas transfers require consideration under sections 28 and 29 and applicable implementing rules. Do not assume that the ordinary reason for collecting information also resolves the transfer question.

DPO appointment is another applicability decision. Section 41 specifies categories in which appointment is required; organisations should check the provision and related notifications against their public-authority status and core processing activities. The obligation is not a universal requirement for every business simply because it holds a customer list.

For a supplier review, ask concrete questions: where are records stored, who has support access, what additional providers are involved and what happens when the contract ends? Assign responsibility for collecting the answers and deciding whether the proposed arrangement is acceptable.

Start with one process you can improve

The following is a suggested implementation sequence:

Step	Practical result
Describe the activity	A clear purpose and map of the information flow
Review the legal route	Recorded reasoning for ordinary and sensitive information
Check the notice	An explanation that matches actual practice
Review suppliers and transfers	Documented recipients, locations and safeguards
Test requests and incidents	A response route that staff can actually follow

For the booking integration, complete these checks before joining the datasets. The result should be an approved, understandable process with clear limits and responsibilities.

That is also where privacy connects to data governance: decisions about useful information should include who may use it, for which purpose and under what safeguards.

Reviewed against the linked sources on 31 October 2026. This introductory guide is not a complete account of the Act, exemptions or implementing notifications. Consult the authoritative Thai texts for implementation.