A Thai company with a foreign parent or affiliate regularly receives emails like these: "Please send the staff list with salaries to HQ." "We need a login to the CRM for all Thai customers." "The internal audit team is flying in; send the personnel files and customer contracts in advance." Accounting or HR often complies because it is an instruction from above. Legally, though, the Thai company is the data controller answerable to its employees and customers. Being in the same group is not a reason that lets the data go.
The core answer
Before sending employee or customer data to the parent, the Thai company must be able to answer five questions. What is the purpose of the request? Is the data requested really necessary for that purpose? What is the parent's role (a separate controller, a joint controller, or a processor)? What is the lawful basis for each purpose? And once the data leaves Thailand, which route under section 28 or section 29 of the Personal Data Protection Act B.E. 2562 (2019) applies? Also read the customer contracts for confidentiality clauses, because those bind the Thai company separately from the PDPA.
The safest answer is rarely "send or don't send". It is "how much, and how". For example, send totals or de-identified data instead of individual records, open access only to the fields and people who need it, and sign an intra-group data transfer agreement before the first data set leaves Thailand.
Our practical view. The problem we see most often is not bad intent. It is data sent first and paperwork found afterwards. When an employee complains or a customer asks where their data went, the Thai company cannot say why it was sent or who can see it. A one-page data map before replying to HQ helps more than a long agreement drafted later.
1. Start by mapping the request: what, whose, why
Do not start with "can we send it?". Ask HQ to state the request in writing, then have the Thai company complete this table before deciding.
| Item | Question to answer |
|---|---|
| What data | Which fields (name, ID number, salary, health record, address, purchase history)? Is any of it sensitive? |
| Whose | Current employees, former employees, applicants, individual customers, contacts at corporate customers? |
| Why | Group payroll, financial reporting, internal audit, regional HR, cross-border sales? |
| Who sees it | Which parent team, how many people, in which country, any subcontractors or cloud providers? |
| Where stored | Whose servers or cloud, in which country? |
| How long | Until when? When is it deleted or returned, and who confirms deletion? |
Many requests cannot answer "why" clearly, for example "just in case" or "group policy". If it cannot be answered, treat it as not yet time to send. The law allows collection only as necessary for a lawful purpose (section 22) and use or disclosure only for the purposes notified when the data was collected (section 21).
2. What are the roles of the Thai company and the parent?
The PDPA distinguishes the "data controller", who decides on collection, use or disclosure, from the "data processor", who acts on the controller's instructions. Roles follow the facts of who sets the purposes and means, not the labels in a contract.
- The Thai company is the controller of the employee and customer data it already holds, whether or not HQ asks.
- The parent can be one of three things, depending on what it actually does.
| Role | Typical pattern | Effect on documents |
|---|---|---|
| Separate controller | HQ takes the data for its own purposes, such as group labour-cost analysis or regional promotion decisions | HQ needs its own lawful basis and duties; employees and customers must be told about the recipient |
| Joint controller | The Thai company and HQ jointly decide what is collected and how it is used, for example a shared HR or CRM system whose terms both set | Agree in writing who gives notice to data subjects, who handles requests, and who is responsible for a breach |
| Processor | HQ only hosts a system or runs payroll on the Thai company's instructions | A data processing agreement is needed; the processor must act only on instructions, secure the data, report breaches and keep records (section 40). If it acts outside instructions, it is treated as a controller for that processing |
One point can change the answer. If HQ uses Thai employees' data for its own goals while the contract calls it a processor, the facts point to a separate controller, and a wrongly labelled document does not protect the Thai company.
3. Which lawful basis fits each purpose?
The basis must be fixed per purpose, not one basis for the whole request. Section 24 sets out bases for collection without consent: contract, legal compliance, legitimate interests of the controller or another person (unless overridden by the data subject's fundamental rights), protecting life, public-interest tasks, and historical or research purposes. Section 19 deals with consent.
| Purpose | Basis that often works | Caution |
|---|---|---|
| Paying salary, tax, social security for Thai staff | Employment contract and legal compliance | This is already done in Thailand; it does not mean individual records must go to HQ |
| HQ prepares group labour-cost reports | Legitimate interests of the group | Balance against employee rights; aggregate data is often enough |
| Group internal or financial audit | Legitimate interests | Limit the sample and the period; scope only as needed for the audit |
| Central HR system used across countries | Contract or legitimate interests | Name the recipients and destination countries in the privacy notice |
| HQ uses customer data for group marketing | Usually the customer's consent | Using data for a new purpose requires notice and fresh consent unless a law allows it (section 21) |
| Customer orders and the parent delivers part of the service | Contract with the customer | Send only what the contract needs |
Employee consent needs special care. Section 19 requires the controller to respect the person's freedom to decide and bars making consent a condition of a contract for data not necessary to it. The data subject can also withdraw consent at any time. If consent is the only basis and some employees withdraw, the company is stranded. Use another basis as the main one where possible.
4. Send the minimum: aggregate payroll, not individual payroll
Data minimisation is the cheapest and most effective tool. Many HQ requests do not need individual data at all.
| HQ needs | Full version (higher risk) | Minimised version |
|---|---|---|
| Labour cost for group accounts | Salary by person with name and ID number | Totals by department or grade, averages |
| Pay structure analysis | Individual records with names | Employee code instead of name; drop ID number, address, full birth date |
| Internal audit that salaries were paid correctly | Copies of whole files | A limited random sample, viewed in the Thai company's data room |
| Attrition report | List of leavers with individual reasons | Counts and rates by reason category |
Truly anonymised data is not personal data. Data that is only pseudonymised (a code replaces the name) can remain personal data if HQ can reverse it, for example where a code-to-name key exists. Keep the key only at the Thai company, and check whether the data set is small enough to identify someone from position or salary, such as a department of one.
Sensitive data. Section 26 lists health data, criminal records, biometric data, genetic data, disability, trade union membership and more, and prohibits collecting them without explicit consent unless an exception applies, such as what is necessary to comply with labour protection or social security law, or to establish legal claims. Workplace examples are sick-leave medical certificates, annual health check results, fingerprint time-clock data, and pre-employment criminal background checks. The starting position should be not to send these to HQ. If a summary will do, such as "passed background check", send only the summary.
5. When data leaves Thailand: sections 28 and 29
Letting HQ view data stored in Thailand from abroad, or sending files across borders, is a transfer of personal data abroad. The controller has four main routes.
Route 1: the destination has adequate protection (section 28). Section 28 requires the destination country or international organisation to have adequate data protection standards under criteria announced by the Personal Data Protection Committee. The 2023 notifications on sections 28 and 29 took effect on 24 March 2024. Under them, the destination needs legal measures consistent with the PDPA and a supervisory authority, and the Committee may decide case by case. Before relying on this route, check whether HQ's country has been accepted as adequate; do not assume.
Route 2: certified intra-group policy, or BCR (section 29). It applies to transfers to a recipient in the same group of undertakings or business, where both sides' policies have been reviewed and certified by the Committee Office. The policy must bind all group companies and staff, guarantee data subject rights and complaint handling, and meet minimum security standards. BCR suits large groups with frequent exchanges that can invest in the certification process. If HQ has no certified BCR, this route is not available.
Route 3: appropriate safeguards (section 29, second paragraph). Where there is no adequacy decision and no certified BCR, a transfer can still proceed with appropriate safeguards that let data subjects enforce their rights and give effective legal remedies. Under the notification, one form is contractual clauses: either standard clauses the notification accepts, such as the ASEAN Model Contractual Clauses or the EU Standard Contractual Clauses, or a contract drafted by the parties with the minimum content the notification requires. Another form is certification of the sender's or recipient's practices. The Personal Data Protection Committee Office publishes model contracts on its website. In practice, this is the fastest route for a Thai subsidiary of a foreign group.
Route 4: section 28 exceptions. Even without the first three, a transfer can proceed in cases such as compliance with law, consent given after being told that the destination's protection standards are inadequate, necessity to perform a contract to which the data subject is a party, or protecting life. These exceptions are read narrowly and rarely fit routine transfers.
- Consent is hard to use with employees for the reasons in section 3, and the destination's risks must be explained first.
- Contract necessity applies when the transfer is genuinely needed for the contract, for example an employee seconded to the parent whose data is needed there. Paying Thai staff under their employment contracts does not normally require HQ to hold individual records, so this ground is not an easy basis for reports to HQ.
Remember that sections 28 and 29 solve only the "leaving the country" problem. A lawful basis under section 24 or 19 for disclosing to HQ is still needed, and data subjects must be told.
6. Do the customer contracts forbid disclosure?
What the PDPA permits is not necessarily what the contract permits. Many corporate customers, especially banks, hospitals, government bodies and listed companies, put confidentiality clauses, restrictions on subcontractors, or data-residency requirements in their contracts. Before opening the CRM to HQ, check:
- Is the customer's data defined as "confidential information", and is disclosure to affiliates prohibited?
- Is written approval required before a third party gets access, and is the parent a third party?
- Is storing or processing data outside Thailand prohibited?
- Are there security standards, audit rights or incident notices that HQ would have to follow?
If a restriction applies, the options are to obtain the customer's written consent, to send only data unrelated to that customer, or to have the Thai team do the work. Breaching a confidentiality clause is a breach of contract that can lead to damages and termination, whether or not the PDPA is satisfied.
7. Does the privacy notice already cover sending to HQ?
Section 23 requires telling the data subject, before or at collection, about the purpose, the data collected and retention period, the categories of persons to whom data may be disclosed, the controller's details, and their rights. Check whether the notices already given to employees and customers say:
- that data may be disclosed to the parent and group companies, and for what purposes;
- that data may be sent to or stored abroad, naming the country or region where possible;
- what safeguards apply, such as standard contractual clauses.
If not, notify them again before sending. If the new purpose differs from the one originally notified, section 21 applies: give notice of the new purpose and obtain consent first unless a law allows it. Adding broad wording to the policy after the data was collected may not be enough.
8. After sending: access, records and deletion
The Thai company's duties do not end at sending. Section 37 requires security measures, steps to stop a recipient who is not a controller from using or disclosing data unlawfully, and a system to delete or destroy data when the retention period ends or it is no longer needed. In practice, set:
- Need-to-know access. List HQ users, give read-only access and only the fields needed, and disable download or export where it is not needed.
- Access logs. Keep a record of who viewed what and when, and review it periodically.
- No onward transfer. HQ must not pass the data to other companies or contractors without the Thai company's permission.
- Audit: delete afterwards. Require HQ to delete or return copies by a set date once the audit ends, and to confirm in writing.
- Breach reporting. HQ must tell the Thai company at once, because the Thai company as controller must notify the Office without undue delay and, where possible, within 72 hours of becoming aware, unless the breach is unlikely to put individuals' rights and freedoms at risk (section 37). See the response plan in the guide on a customer data leak.
The Thai company, as controller, must also keep records of processing under section 39, including the data held, purposes, retention periods, recipients and security measures. Transfers to HQ should appear in those records.
9. Documents to prepare
| Document | When | Key content |
|---|---|---|
| Intra-group data transfer agreement | HQ is a separate or joint controller | Purpose, data types, who has access, section 29 standard clauses, data subject rights, onward transfer, breach notice, deletion, governing law and courts |
| Data processing agreement | HQ is a processor | Instructions only, security measures, breach notice, sub-processors, return or deletion (section 40) |
| Transfer record | Each time a new data set is sent | Date, data set, recipient, lawful basis, section 28/29 route, approver |
| Short risk note (DPIA-style) | Sensitive data, large volumes or wide access | Necessity, less intrusive options, risks to data subjects, mitigations |
| Updated privacy notice | Where the existing notice does not cover it | Recipients, purposes, destination country, safeguards |
| Customer consent letter | Customer contract forbids disclosure | Data, recipient, scope, duration |
All documents should be signed by an authorised director of the Thai company and kept in one file that can be produced if an employee complains or an authority asks.
10. Decision table by scenario
| Scenario | Safer approach | What you need |
|---|---|---|
| Sending payroll data to HQ for group accounts | Send totals by department, or individual records with codes instead of names; omit ID numbers and health data | Legitimate interests or contract basis, intra-group data transfer agreement, notice to employees |
| Giving HQ access to the CRM to view Thai customers | Read-only access limited to needed fields and teams; disable export; check customer contracts first | Transfer agreement or processing agreement, access logs, customer consent if the contract forbids it |
| Overseas team runs an internal audit | View in the Thai company's data room or by screen share; random sample; do not send whole files | Written audit scope, confidentiality undertaking and deletion after the audit |
| HQ runs a central HR system holding Thai employee data | Define which fields go on the system; keep sensitive data in Thailand | Transfer agreement or joint controller terms, risk note, new privacy notice |
| HQ asks for health data or criminal records | Send only a summary result, not original documents | Check the section 26 exceptions first; explicit consent where needed |
| HQ wants customer data for cross-border marketing | Obtain separate customer consent | Consent basis, a way to withdraw, notice of the recipient |
11. Common mistakes
- Assuming group companies may exchange data without paperwork. The PDPA has no automatic exception for parents and subsidiaries. The one directly relevant mechanism is certified BCR under section 29.
- Relying on employee consent alone. Consent can be withdrawn, and the employer-employee imbalance puts its freedom in doubt.
- Sending the full set because HQ asked. Many requests can be met with aggregate data. Ask first what HQ will do with it.
- Calling HQ a processor on paper when HQ uses the data for itself. Actual role outweighs the contract label.
- Forgetting the customer contracts. The PDPA check passes but a confidentiality clause is breached.
- Sending files by email or private chat. There are no logs, no control over forwarding, and no way to recall them.
- Setting no deletion date after the audit. The data stays at HQ indefinitely.
- Not telling employees and customers. The existing privacy notice says nothing about the parent or about foreign recipients.
12. Checklist before replying to HQ
- Ask HQ to state the request in writing: what data, whose, why, who sees it, where stored, how long
- Check that the data is really necessary for the purpose, and whether totals or codes instead of names would do
- Identify HQ's role as it actually operates: separate controller, joint controller or processor
- Set the lawful basis per purpose, and do not rely on employee consent alone
- Remove sensitive data (health, criminal, biometric and so on) or send only a summary result
- Choose the cross-border route: adequate destination, BCR, standard contractual clauses, or a section 28 exception
- Read key customer contracts: confidentiality, third-party access limits, data-residency terms
- Check that the privacy notice covers the parent and foreign recipients; if not, notify again
- Sign the data transfer agreement or processing agreement before the first data set is sent
- Limit access, switch on logs, bar onward transfer, and set a date to delete or return the data
- Record the transfer in the processing records (section 39) and keep all documents in one file
Further reading
- A foreign company with no legal team in Thailand: managing the Thai subsidiary — reporting lines and approvals between HQ and the Thai subsidiary
- A customer data leak: what to do first — the 72-hour response plan if data sent to HQ is exposed
- Employees using ChatGPT with customer data: the AI policy a company needs — controlling customer data that goes to outside tools
- A former employee takes the customer list — trade secrets and the documents to have in place beforehand
Before sending employee or customer data to the parent, be able to say why, send only what is necessary, know the parent's role, name the section 28 or 29 route you rely on, and confirm the customer contracts allow it. Finish the paperwork before the first data set leaves Thailand.
We help Thai companies with foreign parents draft intra-group data transfer agreements and data processing agreements, review customer contracts that restrict disclosure, update privacy notices, and set a way to answer HQ requests. For an initial consultation, call +66 92 254 2045 or send us the details. See also PDPA compliance and contracts and documents.
This guide is published by Suwanvara Law Firm — a Khon Kaen law firm established in 1986. General information only, not legal advice on a specific matter.
