The Transfer Mechanism Is Only Part of the Compliance
Multinational groups often treat foreign back-end processing as a technical matter rather than a legal one. A local business collects customer data in Thailand, and some of that data is then sent to an overseas group company, manufacturer, cloud provider, software vendor, or regional support hub for quality review, troubleshooting, warranty support, analytics, system maintenance, or product improvement.
Under Thailand’s Personal Data Protection Act B.E. 2562 (2019) (PDPA), that structure raises three linked questions: whether the transfer outside Thailand rests on a valid legal mechanism, whether the overseas recipient is acting as a controller or a processor, and whether the foreign entity’s activities trigger Thailand’s extraterritorial and representative rules.
These questions cannot be answered in isolation. A transfer clause cannot fix an inaccurate role analysis. A privacy notice cannot cure a mismatch between the contract documents and the actual data flows. And a representative appointment should not be drafted so broadly that it unintentionally suggests controller-level responsibility where the overseas entity is meant to act only as a processor.
1. Start with Sections 28 and 29
Section 28 is the starting point for any cross-border transfer. It requires that the destination country or international organization receiving the personal data maintain an adequate data protection standard, assessed under criteria prescribed by the Personal Data Protection Committee (PDPC). It also sets out exceptions: compliance with law, informed consent, contract necessity, a contract for the benefit of the data subject, vital interests, and substantial public interest.
Consent deserves its own scrutiny. Under Section 28, a transfer may rely on consent only where the data subject has first been informed that the destination country or organization does not maintain an adequate protection standard, and that consent must also meet the PDPA’s general requirements: it must be clear, freely given, distinguishable from other matters, and as easy to withdraw as it was to give. Those conditions make consent better suited to a specific or occasional transfer than to the repeated operational transfers typical of multinational data flows.
Section 29 provides the main alternatives for intra-group and safeguard-based transfers. It recognizes a certified personal data protection policy for transfers within the same affiliated business or group of undertakings, and, absent an adequacy finding or a certified intra-group policy, permits transfers under suitable protection measures that still allow data subjects to enforce their rights and obtain effective legal remedies.
As discussed in our earlier article, Thailand’s PDPA: Enforcement in Action and Cross-Border Data Transfers, the PDPC’s cross-border transfer framework clarified the Section 28 adequacy route and the Section 29 safeguard route, including Binding Corporate Rules for intra-group transfers and contractual safeguards based on recognized model clauses, such as the ASEAN Model Contractual Clauses or the EU Standard Contractual Clauses, subject to the conditions and adaptations required under Thai law.
2. EU SCCs may help, but they do not complete the Thai compliance
Many companies already have EU Standard Contractual Clauses in place and want to extend them to Thai data flows. That can work, provided the clauses and their schedules actually cover the Thai transfer, but the question is not simply whether the group has SCCs somewhere in its files.
A proper Thai law review confirms the actual transfer path: the parties’ roles, the categories of personal data involved, the purposes notified to data subjects, the overseas recipients or recipient categories, the security controls, onward transfer restrictions, breach cooperation terms, handling of data subject rights, and the allocation of liability and remediation.
A Thai addendum to an existing SCC framework should not restate the PDPA wholesale. Its job is to close the specific gaps between the existing contract and Thai law, for example by confirming that the transfer relies on Section 29 appropriate safeguards, identifying the Thai data exporter and the foreign recipient, confirming processor-only use where that is the intended structure, and ensuring Thai data subjects retain enforceable protection.
This is consistent with the broader point made in our GDPR vs. Thailand PDPA comparison: the Thai PDPA resembles the GDPR structurally, but it is not the GDPR. Existing GDPR documentation may be useful, but it should not be assumed to solve the Thai analysis without checking the Thai statutory framework and the actual data flow.
3. Role characterization is a legal and operational question, not a label
The PDPA defines a data controller as the person or juristic person with the power and duty to decide the purposes and means of collecting, using, or disclosing personal data. A data processor, by contrast, acts on the controller’s instructions and is expressly not the controller.
That distinction is not settled by what the contract calls each party. An overseas entity is more plausibly a processor when it receives Thai customer data solely to perform a defined support function under documented instructions. The position weakens the moment the entity determines the purposes of its analysis, combines the data with other datasets for its own product development, independently controls retention, shares the data further for its own business reasons, or engages in independent analytics or customer-facing activity.
The practical test asks who decides why the data is collected, who decides that it will be transferred abroad, who controls what the overseas recipient may do with it, and whether that recipient can use the data for its own purposes. Role characterization should therefore precede the drafting of the documents. If the parties misstate the operating model at the outset, the privacy notice, data processing agreement, transfer clauses, records, and representative appointment can all inherit the same flaw.
4. Back-end processing is not automatically “monitoring”
Section 5 extends the PDPA to controllers or processors located outside Thailand when their activities involve offering goods or services to data subjects in Thailand, or monitoring the behavior of data subjects in Thailand. Not every foreign technical-support function meets that threshold. Processing personal data relating to data subjects in Thailand does not, by itself, constitute monitoring of their behavior.
The assessment must focus on whether the foreign entity’s relevant collection, use, or disclosure of personal data is carried out in connection with either: (i) offering goods or services to data subjects in Thailand, whether or not payment is required; or (ii) monitoring the behavior of data subjects where that behavior takes place in Thailand.
A foreign entity that does not sell to Thai customers, does not contract with them, does not market to them, and acts only on another party’s instructions may have a stronger argument that it is not independently offering goods or services into Thailand or monitoring behavior there. But those facts are relevant rather than determinative, particularly because Section 5 expressly applies to both controllers and processors.
The likelihood that processing constitutes monitoring increases where the overseas entity receives ongoing usage, diagnostic, location, behavioral, device, or interaction data and uses that data to track or evaluate individuals, including for profiling, prediction, personalization, targeted services, product analytics, or other independent commercial purposes.
This distinction will matter more as multinational groups adopt AI-enabled support tools and analytics systems. As noted in our article on Artificial Intelligence, Machine Learning, and Big Data in Thailand, cross-border transfers for AI training or analytics purposes must still be assessed under Sections 28 and 29. Calling something “technical processing” does not remove the need to examine what the system actually does with Thai personal data.
5. The representative question follows the Section 5 compliance, not the other way around
Section 37(5) requires a foreign controller subject to Section 5, paragraph two, to designate a written representative in Thailand with authority to act on the controller’s behalf. Section 38 then extends elements of that representative framework, with certain exemptions, to a processor of that foreign controller, applied mutatis mutandis.
The sequencing matters: the representative question should be answered only after the territorial-scope and role analysis is complete, not before.
A representative appointment does not, by itself, convert a foreign processor into a controller. But loosely drafted appointment language can create real ambiguity if it reads as though the processor has assumed controller-level obligations it was never meant to carry. The appointment should be drafted to reflect the actual PDPA role: if the overseas recipient is a processor, the appointment should not casually describe it as making controller-level decisions; if the overseas entity does make independent decisions about Thai personal data, the documents should confront that directly rather than attempt to solve it through wording.
6. Records and processor agreements should reflect the compliance role
Section 39 requires controllers to maintain records covering the personal data collected, the purposes of collection, the controller’s details, retention periods, access rights, certain uses or disclosures, any rejected requests or objections, and security measures. That obligation extends to the Thai representative of a foreign controller.
Section 40 imposes the corresponding processor duties: acting only on the controller’s instructions, maintaining appropriate security measures, notifying the controller of breaches, and preparing processing activity records in the form prescribed by the PDPC. It also requires a controller-processor agreement governing the processor’s activities. This provision carries particular weight, since a processor that acts outside the controller’s instructions may itself be treated as a controller for that collection, use, or disclosure.
This is where documentation most often drifts out of alignment. The privacy notice describes one role allocation, the data processing agreement describes another, the technical architecture reflects a third, and the representative appointment implies a fourth. PDPA compliance depends on closing those gaps so the documents describe what the system actually does.
This is part of the broader move from formal PDPA documentation to operational accountability, as discussed in Thailand PDPA in Its Second Phase: What Recent Developments Really Indicate. The question is no longer only whether documentation exists, but whether the organization can show how the documented structure functions in practice.
7. The breach scenario tests the structure
Cross-border arrangements often look acceptable until something goes wrong.
If a breach occurs, the controller must be able to identify which Thai data subjects are affected, where the data was transferred, which entity controlled the data at each stage, what the processor was instructed to do, whether any onward transfers occurred, and who is responsible for notification, investigation, containment, and remediation.
That is why transfer clauses, processor agreements, and representative arrangements should not be treated as disconnected documents. In a live incident, they become part of the same accountability structure.
As discussed in our article, From Awareness to Accountability: Breach Notification Under Thailand’s PDPA, breach notification is not merely a countdown exercise. It requires factual awareness, risk assessment, and the ability to explain who controlled the relevant processing. Cross-border structures make that analysis harder if roles and records were not clear before the incident occurred.
The practical point
Cross-border processing of Thai customer data should not begin and end with the question: “Can we use the same GDPR paperwork?”
The better question is: what is the actual data flow, who is deciding the purposes and essential means of processing, what transfer mechanism applies, what has been disclosed to data subjects, and do the contracts, records, and representative arrangements reflect that reality?
For routine, instruction-only support processing, a processor structure may hold up. For broader analytics, behavioral monitoring, product development, or independent commercial use of the data, the analysis changes — and likely the outcome too.
A GDPR-style compliance programme may be appropriate in many respects, but cross-border transfers under the Thai PDPA require their own analysis and documentation. The transfer mechanism should not be assumed to work simply because the wider compliance framework is based on the GDPR.
© 2026 Formichella & Sritawat Attorneys at Law. All rights reserved.
The comments herein are provided for discussion and informational purposes only and may not reflect the most current legal developments. Nothing contained in this publication should be relied upon as legal advice.
