Thailand’s Personal Data Protection Act (PDPA) turned data privacy from soft practice into binding law. Since the PDPA came into force and the Personal Data Protection Committee (PDPC) began issuing sub-regulations and guidance, organizations that collect, use or disclose personal data about people in Thailand must treat privacy as an operational, legal and board-level risk. Below is a practical, detail-rich guide you can use to design or audit a PDPA compliance program: scope and extraterritorial reach, legal bases and special categories, data subject rights, cross-border transfer rules, breach-notification practice, enforcement trends and a ready 30/60/90-day compliance plan.
Quick snapshot — what changed and why it matters
The PDPA (enacted 2019; fully enforced from mid-2022 with subsequent subordinate rules) adopts many GDPR-style concepts (lawful bases, rights, controllers/processors) but with Thai-specific mechanics (PDPC oversight, local sub-regulations on transfers, and administrative enforcement powers). Noncompliance now carries real administrative fines and public corrective orders.
Who the law covers — scope and extraterritoriality
The PDPA applies to personal data processed by controllers and processors in Thailand and reaches many foreign organizations that target or monitor individuals in Thailand. If you offer goods/services to Thai residents, or track behaviors of people in Thailand (cookies, targeted ads), you are likely inside scope and must comply with PDPA duties and documentation.
Core duties — lawful bases, controller/processor roles and governance
Practical PDPA compliance begins with mapping processing and documenting legal bases:
-
Lawful bases: consent, performance of a contract, legal obligation, vital interests, public task, legitimate interest or other PDPC-recognized grounds. Controllers must record the basis for each processing activity and be ready to show it on inspection.
-
Controller vs processor: controllers set purposes and must ensure processors act only on documented instructions and meet security obligations in contract. The controller retains primary responsibility for compliance.
-
Governance: appoint a data-protection lead (or DPO where recommended), maintain a record of processing activities (ROPA), and run data-protection impact assessments (DPIAs) for high-risk processing. Policies, training and vendor due diligence are mandatory operational controls.
Sensitive data & minimization — a higher bar
The PDPA treats sensitive personal data (health, biometric identifiers, racial/ethnic origin, sexual life, criminal records, etc.) with extra caution. Processing these categories commonly requires explicit consent or a narrow statutory exception, and organizations must apply stronger technical and contractual protections (encryption, stricter access controls, shorter retention). Always ask: can you achieve the business aim with less data? If not, document the DPIA and extra safeguards.
Data subject rights — operational SLAs you must meet
Thai data subjects have rights to access, correct, erase (in specific cases), object, restrict processing, portability and to be informed. Build an operational Subject Access Request (SAR) workflow that:
-
Verifies identity robustly but fairly,
-
Logs receipt and response deadlines, and
-
Produces an auditable trail (what was returned, who approved redactions).
The PDPC expects timely, documented responses and will scrutinize weak verification or blanket denials.
Cross-border transfers — rules, SCCs, adequacy and recent sub-regulations
Cross-border transfers are tightly regulated. The PDPC published sub-regulations in 2024 clarifying how transfers may be made to adequate jurisdictions and how controllers can rely on appropriate safeguards (standard contractual clauses, binding corporate rules, certifications and other mechanisms). The PDPC also set out criteria for “adequacy” and accepts SCCs aligned with international models (ASEAN/EU style clauses) provided they meet Thai standards for purpose limitation and data-subject rights. Maintain a transfer register and impact assessments for each flow.
Breach notification — the 72-hour practical rule
The PDPC requires controllers to notify the regulator without undue delay and, where feasible, within 72 hours of becoming aware of a personal-data breach that poses risk to individuals — unless a documented assessment shows no risk. Notifications should include a description of the incident, data categories involved, mitigation steps and contact points. If you cannot produce a full report in 72 hours, send a timely preliminary notification and follow up with details as available. Practical playbook: detection → containment → risk assessment (documented) → PDPC notification (72-hour window) → data-subject communications as required.
Enforcement landscape & penalties — real money and public measures
The PDPC has moved from advisory activity to active enforcement. Administrative fines and corrective orders have been imposed (multi-million-baht penalties have occurred), and regulators now publish cases and lessons learned. Expect regulatory audits, public naming and reputational remedies in addition to fines. Factor enforcement risk into your board reporting and vendor contracts.
Practical controls — what to implement now (technical + organizational)
-
Data mapping & inventories: identify where personal data enters, where it leaves and who has access.
-
DPIAs for high-risk processing: e.g., health, behavioral profiling, AI/automated decisions and large-scale cross-border transfers.
-
Vendor management: standard PDPA-compliant contracts, security questionnaires and audit rights.
-
Security measures: encryption at rest/in transit, role-based access, MFA for privileged accounts, logging and retention rules.
-
Incident response: tabletop exercises, PDPC notification templates, forensic readiness and a legal intake process for requests/orders.
-
Training & culture: define minimum training for developers, product managers and customer-facing teams.
These controls are the operational minimum the PDPC expects during inspections.
Sectoral nuances & pragmatic examples
-
Healthcare: treat health data as highly sensitive — use explicit consent, tight access logs and purpose-specific retention.
-
Fintech/e-commerce: prepare for frequent cross-border flows (payment processors, fraud vendors) — maintain SCCs and transfer logs.
-
Marketing/ads: cookie banners and pre-ticked opt-ins are risky — use granular consent, clear withdrawal paths and record consent metadata.
30/60/90-day compliance sprint (actionable)
0–30 days
-
Map critical personal-data flows (top 3 systems) and appoint PD lead/DPO.
-
Publish/update privacy notice and SAR contact.
30–60 days
-
Run DPIAs for 2 highest-risk activities (e.g., customer profiling, HR health records).
-
Update vendor contracts with SCCs or approved safeguards; start transfer-register.
60–90 days
-
Test incident response with a tabletop breach, produce PDPC notification template, and train teams on SAR handling.
Final note — integrate privacy into product & contracts
Treat PDPA compliance as product design plus legal discipline: bake privacy into requirements, contractually bind suppliers, and keep clear records (ROPA, DPIA, transfer register).