Help us improve
Share bugs, ideas, or general feedback.
From claude-thai-skills
Use this skill for tasks involving Thailand's PDPA (พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562). Trigger whenever the user asks to: draft a Thai privacy notice, write a PDPA consent banner, prepare a data subject rights notice, draft a 72-hour breach notification to the PDPC, decide if a DPO is required, list lawful bases, handle cross-border transfers, or audit a notice against PDPA. Also trigger for "เขียน privacy policy", "PDPA", "ขอความยินยอม", "นโยบายความเป็นส่วนตัว", "consent banner ไทย", "Thai privacy notice", "PDPA compliance", "DPO Thailand", "ประกาศการละเมิดข้อมูล", or any variation. If the task involves Thai personal data law, consent, or notice drafting, use this skill.
npx claudepluginhub boom-vitt/claude-thai-skills --plugin thai-invoiceHow this skill is triggered — by the user, by Claude, or both
Slash command
/claude-thai-skills:thai-pdpaThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA, effective 1 June 2022) ใกล้เคียงกับ GDPR แต่ไม่เหมือนกัน. Copy-pasting a GDPR notice into Thai is the #1 reason notices fail audits — references to "Article 6 GDPR" make the notice non-compliant on its face. Always re-anchor citations to PDPA sections.
Guides developers on Thailand PDPA compliance: consent framework, DPO requirements, lawful processing bases, cross-border transfers, data subject rights.
Navigates GDPR and CCPA privacy regulations, reviews DPAs, and handles data subject requests. Useful for compliance assessments, vendor agreements, cross-border transfers, and DSAR responses.
Implements and audits privacy controls (GDPR, CCPA, LGPD, PIPEDA) in code, data, and infrastructure. Covers data minimization, DSARs, DPIAs, consent management, breach notification timing, and right-to-be-forgotten across backups and caches.
Share bugs, ideas, or general feedback.
พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA, effective 1 June 2022) ใกล้เคียงกับ GDPR แต่ไม่เหมือนกัน. Copy-pasting a GDPR notice into Thai is the #1 reason notices fail audits — references to "Article 6 GDPR" make the notice non-compliant on its face. Always re-anchor citations to PDPA sections.
| Topic | GDPR | PDPA (พ.ร.บ.) |
|---|---|---|
| Consent | Opt-in, freely given | Opt-in, freely given (Sec 19); no pre-checked boxes |
| Reject button | Recommended | Required equal-weight under PDPC consent guidance |
| Breach notice to regulator | 72h to DPA | 72h to PDPC (Sec 37) |
| Subject rights | 8 rights | Same 8 rights (Sec 30–36): access, rectify, erase, restrict, port, object, withdraw, complain |
| DPO trigger | Large-scale systematic monitoring or special-category data | Same trigger + state agencies (Sec 41) |
| Cross-border | Adequacy or safeguards | Adequacy or safeguards; PDPC keeps adequacy list (Sec 28) |
| Sensitive data | Art 9 categories | Sec 26: race, ethnicity, political opinion, religion/philosophy, sexual behavior, criminal record, health, disability, trade union, genetic, biometric, others as prescribed |
| Penalties | Up to 4% global turnover | Admin fines up to ฿5M; criminal up to ฿1M + 1 yr imprisonment; civil punitive up to 2x damages |
A compliant Thai notice must state, in plain Thai:
See templates/privacy-notice-th.md for the full bilingual skeleton.
See templates/consent-banner.md for the HTML mockup and Thai copy.
Notify the PDPC within 72 hours of becoming aware, unless the breach is unlikely to result in risk to rights and freedoms. Notify affected data subjects without undue delay if high risk. Include:
Required when:
The DPO must report directly to top management, cannot have a conflict of interest, and their contact must be published in the notice.
PDPC issued two notifications in the Royal Gazette on 25 ธ.ค. 2566 (eff. 24 มี.ค. 2567): one under Sec 28 (adequacy / "whitelist" route) and one under Sec 29 (appropriate safeguards incl. BCR and standard contractual clauses / สัญญามาตรฐาน). Check the current PDPC notification text before quoting numbers — these are the controlling sub-regulations.
Practical state: PDPC has not yet published an adequacy whitelist. In practice, almost every transfer (Cloudflare, AWS, GCP, Azure, Slack, HubSpot, Zendesk, parent-company HR systems) needs a Sec 29 safeguard.
Lawful routes under Sec 28/29:
| Route | Source | When to use |
|---|---|---|
| Adequacy | Sec 28 + Whitelist Notification | Only if destination is on the PDPC whitelist (none as of writing) |
| BCR (binding corporate rules) | Sec 29 + Safeguards Notification | Intra-group transfers; must be pre-approved by the PDPC |
| SCC (สัญญามาตรฐาน) | Sec 29 + Safeguards Notification | Most third-party processor/controller transfers; clauses must meet PDPC minimum content |
| Certification | Sec 29 + Safeguards Notification | Where a PDPC-recognized certification scheme exists |
| Explicit consent | Sec 28(1) | Data subject informed of inadequate protection and consents — fragile, not for routine use |
| Contractual necessity | Sec 28(3)/(4) | Transfer needed to perform a contract with / in the interest of the data subject |
| Vital interest / legal claim / public interest | Sec 28(2)/(5)/(6) | Narrow exceptions |
What to write in the privacy notice (Sec 23(5)+(6) anchor):
Important framing: PDPA does not have a GDPR-style Article 35 "DPIA is mandatory" provision. What it does have:
When to run a DPIA (ประเมินผลกระทบด้านการคุ้มครองข้อมูลส่วนบุคคล) even though not statutorily required:
Minimum DPIA content (align with PDPC expectations and EU sub-processor due-diligence):
There is no PDPA equivalent of GDPR's "prior consultation" duty, but where residual risk is high and you cannot mitigate, the prudent path is to consult the PDPC before launch and document the consultation.
PDPA is the floor. Sector regulators add stricter obligations and sometimes carve out specific data types from PDPA entirely. Always check the sector rule on top of PDPA.
| Sector | Regulator | Overlay (non-exhaustive) |
|---|---|---|
| Banking / financial institutions | Bank of Thailand (ธปท.) | BoT Data Governance Guidelines (2564 / 2021); IT-risk and outsourcing notifications; incident reporting to BoT and TB-CERT in parallel with PDPC |
| Credit bureau data | OFIPC / Credit Information Business Act | CIBA governs credit information; credit-bureau operations are largely outside PDPA scope — consent and disclosure rules come from CIBA, not Sec 19 |
| Capital markets / securities / digital assets | สำนักงาน ก.ล.ต. (SEC) | Client-data confidentiality under SEC Act and digital-asset notifications; KYC/AML retention duties may override "delete on request" |
| Insurance | คปภ. (OIC) | Insurance-specific customer-data and claims-data rules layered on PDPA |
| Telecom | กสทช. (NBTC) | NBTC notification on protection of telecom users' personal data, privacy, and freedom of communication (replaced the 2549/2006 notification) — extra duties for CDR, location, traffic data |
| Digital ID / e-transactions | MDES, ETDA | Electronic Transactions Act, digital-ID framework; ETDA notifications on trusted service providers |
| Healthcare | กระทรวงสาธารณสุข (MOPH), NHSO, Medical Council | Patient confidentiality under the National Health Act (พ.ร.บ. สุขภาพแห่งชาติ) Sec 7, Medical Profession Act ethics, and MOPH circulars; health data is also Sec 26 sensitive data under PDPA |
| Cybersecurity for CII | สกมช. (NCSA) | Cybersecurity Act 2562 incident reporting for critical information infrastructure — runs in parallel with PDPC breach notice |
When drafting a privacy notice for a regulated entity, state the sector regulator alongside PDPC in the rights / complaints section, and acknowledge sector-specific retention duties (e.g. "5 years under AML / 10 years under SEC rules") rather than promising deletion on request.
PDPA codifies two roles, not three:
Joint controllership is not a codified concept in PDPA the way GDPR Art 26 codifies it. PDPC sub-regulations recognize "affiliated business / group of undertakings" — e.g. allowing a shared DPO — but there is no PDPA "joint controller" article that allocates liability between co-controllers. Practical implication: if two entities jointly determine purposes (กำหนดร่วมกัน), each is a controller in its own right and each carries full controller liability to the data subject. Allocate responsibility in a contract, but assume the data subject can sue either of you.
Data processing agreement (DPA / สัญญาประมวลผลข้อมูล) requirements — Sec 40 sets the duty; PDPC has not published a fixed DPA template, but a defensible DPA should include:
Liability to the data subject (who gets sued):
What to put in the privacy notice: