PDPA setup — consent, retention, export, delete การตั้งค่า PDPA — consent การเก็บรักษา การส่งออก การลบ
Thai PDPA B.E. 2562 is being actively enforced since 2024. How to configure DevProp so your agency is compliant by default, with one-click data subject responses. พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 บังคับใช้ตั้งแต่ปี 2567 วิธีตั้งค่า DevProp ให้เอเจนซี่ของคุณสอดคล้องตั้งแต่เริ่ม ด้วยการตอบสนอง data subject คลิกเดียว
What PDPA actually requires of you
Thailand's Personal Data Protection Act B.E. 2562 (PDPA) came into force in mid-2022 and is in active enforcement since 2024. The PDPC (Personal Data Protection Committee) issued ฿2.4M in Sansiri's settlement in 2024 — the largest property-sector PDPA fine to date.
Your agency's six core obligations:
- Lawful basis — for every piece of personal data you hold, you must be able to point to a lawful basis (consent, contract, legal obligation, vital interest, public interest, or legitimate interest).
- Consent capture — when consent is the basis, you must have evidence the data subject consented to a specific purpose with retention period and withdrawal mechanism explained.
- Purpose limitation — you cannot use the data for purposes beyond what the data subject consented to.
- Retention limit — you must delete personal data when the retention period ends or the purpose is fulfilled.
- Data subject rights — you must respond to access, correction, deletion, and portability requests within 30 days.
- Security — appropriate technical and organizational measures to prevent unauthorized access or loss.
How DevProp handles each obligation by default
- Lawful basis — every personal data field is tagged with its basis at the schema level. Customer email = legitimate interest (contact). LINE display name = consent. Thai national ID = contract performance (required for ETA contracts).
- Consent capture — when a lead enters via LINE/web form, the consent string is captured with timestamp, IP, purpose, and version of your privacy policy at that moment. Stored in the lead's audit log.
- Purpose limitation — exports and reports respect the purpose tag. You cannot export a list of leads who only consented to "contact about Sukhumvit listings" for a "Phuket marketing campaign".
- Retention limit — Settings → PDPA → Retention rules. Default: 3 years from last contact for active leads, 1 year for cold leads, 7 years for closed deals (required by Thai accounting law). After retention, records are auto-anonymized or deleted.
- Data subject rights — one-click access/export/delete from the lead record (see Step 3 below).
- Security — AES-256-GCM encryption at rest, TLS 1.3 in transit, mandatory 2FA for admin users, audit log of every access.
Step 1 — Configure your privacy policy
Settings → PDPA → Privacy policy. Upload your privacy policy in EN + TH. We provide a Thai-market template (specific to property agencies) that you can edit. The policy version is timestamped — every consent capture references the version active at that moment, so even years later you can prove what the data subject agreed to.
Step 2 — Configure consent capture points
Settings → PDPA → Consent capture. The default 4 capture points:
- Website contact form — checkbox "I agree to be contacted by [agency] about property opportunities matching my criteria." Logs IP + form data + policy version.
- LINE OA first message — Nisa auto-sends "Welcome! Before we continue, please confirm you agree to our privacy policy: [link]. Reply YES to continue." Logs LINE user ID + timestamp + reply text.
- Phone enquiry — agent reads scripted disclosure ("This call may be recorded. Do you consent to me storing your contact details to follow up on your enquiry?") and clicks Confirm. Logs agent name + timestamp + lead name.
- Walk-in visit — tablet or paper form. Agent ticks the box on the lead's behalf. Logs agent name + timestamp + lead signature (if paper, scanned).
Step 3 — Respond to a data subject request
When someone messages you "What data do you have on me, and please delete it," go to the lead record → Actions → PDPA request. Three options:
- Access — generates a PDF containing every field, every log entry, every message, every contract. Send to the data subject.
- Correction — they tell you what's wrong; you correct the field and the audit log captures who, when, and what changed.
- Deletion — confirms whether deletion is legally possible (you can't delete records related to active contracts or ongoing legal obligations). If allowed, deletes immediately + logs the deletion + sends a confirmation email to the data subject.
All actions are logged. If a regulator asks "prove you responded to this data subject's request within 30 days," the log shows the request received timestamp, the action taken timestamp, the response sent timestamp, and the staff member who processed it.
Step 4 — Retention auto-purge
Once a day at 3am Bangkok time, DevProp runs the retention purge:
- Leads with no contact in 3 years → anonymized (name/phone/email replaced with hash, message content kept for aggregate statistics only).
- Leads with no contact in 5 years → fully deleted.
- Contracts older than 7 years → archived to PDF/A, raw data deleted.
- Closed deals older than 10 years → fully deleted.
You can override these defaults per record (e.g. flag a high-value contact as "do not auto-purge" until manual review). Overrides are logged.
Step 5 — Audit logs (where regulators look first)
Reports → PDPA → Audit log. Every access to personal data is logged: who, when, what record, what action. If a regulator audits you, this is the primary evidence.
For developer-direct agencies handling hundreds of leads per month, configure access alerts (Settings → Security → Alerts). If an agent accesses >50 leads in an hour, you get a notification. This is the audit pattern that caught the Sansiri agent leaking lead data in 2023.
Penalties at a glance
- Failing to obtain valid consent: up to ฿3,000,000 administrative fine per violation.
- Failing to respond to a data subject request within 30 days: up to ฿1,000,000.
- Failing to report a data breach within 72 hours: up to ฿5,000,000.
- Sensitive data violations (medical, religious, etc.): up to ฿5,000,000 each.
The PDPC has accelerated enforcement in 2024-25; expect more property-sector cases through 2026. DevProp's PDPA module is designed to keep your agency on the safe side of every one of these obligations by default.
PDPA ต้องการอะไรจริงจากคุณ
พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) ของไทยมีผลบังคับใช้กลางปี 2565 และอยู่ในการบังคับใช้อย่างจริงจังตั้งแต่ปี 2567 PDPC (คณะกรรมการคุ้มครองข้อมูลส่วนบุคคล) ออกค่าระงับ Sansiri ฿2.4M ในปี 2567 — ค่าปรับ PDPA ภาคอสังหาฯ ที่ใหญ่ที่สุดถึงปัจจุบัน
ภาระหน้าที่หลัก 6 ของเอเจนซี่คุณ:
- ฐานทางกฎหมาย — สำหรับข้อมูลส่วนบุคคลทุกชิ้นที่คุณถือ คุณต้องชี้ฐานทางกฎหมายได้ (consent สัญญา ภาระทางกฎหมาย ผลประโยชน์สำคัญ ผลประโยชน์สาธารณะ หรือผลประโยชน์ที่ชอบด้วยกฎหมาย)
- การจับ consent — เมื่อ consent เป็นฐาน คุณต้องมีหลักฐานว่า data subject ตกลงกับวัตถุประสงค์เฉพาะพร้อมระยะเวลาเก็บและกลไกการถอนอธิบาย
- การจำกัดวัตถุประสงค์ — คุณไม่สามารถใช้ข้อมูลสำหรับวัตถุประสงค์เกินกว่าที่ data subject ตกลง
- ขีดจำกัดการเก็บรักษา — คุณต้องลบข้อมูลส่วนบุคคลเมื่อระยะเวลาเก็บสิ้นสุดหรือวัตถุประสงค์บรรลุ
- สิทธิ data subject — คุณต้องตอบสนองคำขอเข้าถึง แก้ไข ลบ และพกพาภายใน 30 วัน
- ความปลอดภัย — มาตรการทางเทคนิคและองค์กรที่เหมาะสมเพื่อป้องกันการเข้าถึงโดยไม่ได้รับอนุญาตหรือสูญหาย
วิธี DevProp จัดการแต่ละภาระหน้าที่โดยดีฟอลต์
- ฐานทางกฎหมาย — ฟิลด์ข้อมูลส่วนบุคคลทุกฟิลด์ tag กับฐานที่ระดับ schema อีเมลลูกค้า = ผลประโยชน์ที่ชอบด้วยกฎหมาย (ติดต่อ) ชื่อแสดง LINE = consent บัตรประชาชนไทย = การปฏิบัติตามสัญญา (จำเป็นสำหรับสัญญา ETA)
- การจับ consent — เมื่อลีดเข้ามาผ่าน LINE/web form สตริง consent ถูกจับด้วย timestamp, IP, วัตถุประสงค์ และเวอร์ชันของ privacy policy ของคุณตอนนั้น เก็บใน audit log ของลีด
- การจำกัดวัตถุประสงค์ — การ export และรายงานเคารพ tag วัตถุประสงค์ คุณไม่สามารถ export รายการลีดที่ตกลงเฉพาะ "ติดต่อเกี่ยวกับประกาศสุขุมวิท" สำหรับ "แคมเปญ marketing ภูเก็ต"
- ขีดจำกัดการเก็บรักษา — Settings → PDPA → Retention rules ดีฟอลต์: 3 ปีจากการติดต่อล่าสุดสำหรับลีด active 1 ปีสำหรับลีดเย็น 7 ปีสำหรับดีลที่ปิด (จำเป็นโดยกฎหมายบัญชีไทย) หลังการเก็บรักษา record ถูก anonymize อัตโนมัติหรือลบ
- สิทธิ data subject — การเข้าถึง/ส่งออก/ลบคลิกเดียวจาก record ลีด (ดู Step 3 ด้านล่าง)
- ความปลอดภัย — การเข้ารหัส AES-256-GCM ตอนเก็บ TLS 1.3 ขณะส่ง 2FA บังคับสำหรับผู้ใช้ admin audit log ของการเข้าถึงทุกครั้ง
ขั้นตอนที่ 1 — ตั้งค่า privacy policy
Settings → PDPA → Privacy policy อัปโหลด privacy policy ของคุณใน EN + TH เรามี template ตลาดไทย (เฉพาะเอเจนซี่อสังหาฯ) ที่คุณแก้ได้ เวอร์ชัน policy เป็น timestamp — การจับ consent ทุกครั้งอ้างเวอร์ชัน active ตอนนั้น ดังนั้นแม้หลายปีต่อมา คุณยังพิสูจน์ได้ว่า data subject ตกลงอะไร
ขั้นตอนที่ 2 — ตั้งค่าจุดจับ consent
Settings → PDPA → Consent capture 4 จุดจับดีฟอลต์:
- ฟอร์มติดต่อเว็บไซต์ — checkbox "ฉันยินยอมให้ [เอเจนซี่] ติดต่อเกี่ยวกับโอกาสอสังหาฯ ที่ตรงเกณฑ์ของฉัน" บันทึก IP + ข้อมูลฟอร์ม + เวอร์ชัน policy
- ข้อความ LINE OA ครั้งแรก — Nisa ส่งอัตโนมัติ "ยินดีต้อนรับ! ก่อนเราดำเนินการต่อ โปรดยืนยันคุณตกลงนโยบายความเป็นส่วนตัวของเรา: [link] ตอบ YES เพื่อดำเนินการต่อ" บันทึก LINE user ID + timestamp + ข้อความตอบ
- การถามทางโทรศัพท์ — เอเจนต์อ่าน disclosure ตามสคริปต์ ("การโทรนี้อาจถูกบันทึก คุณยินยอมให้ฉันเก็บรายละเอียดติดต่อของคุณเพื่อติดตามคำถามของคุณหรือไม่?") และคลิก Confirm บันทึกชื่อเอเจนต์ + timestamp + ชื่อลีด
- การเข้าชมเดินเข้ามา — แท็บเล็ตหรือฟอร์มกระดาษ เอเจนต์ติ๊ก box แทนลีด บันทึกชื่อเอเจนต์ + timestamp + ลายเซ็นลีด (ถ้ากระดาษ สแกน)
ขั้นตอนที่ 3 — ตอบสนองคำขอ data subject
เมื่อมีคนส่งข้อความถึงคุณ "คุณมีข้อมูลอะไรเกี่ยวกับฉัน และโปรดลบ" ไปที่ record ลีด → Actions → PDPA request สามตัวเลือก:
- เข้าถึง — สร้าง PDF ที่มีฟิลด์ทุกอัน รายการ log ทุกอัน ข้อความทุกอัน สัญญาทุกอัน ส่งให้ data subject
- แก้ไข — พวกเขาบอกอะไรผิด คุณแก้ฟิลด์และ audit log จับ ใคร เมื่อไร และอะไรเปลี่ยน
- การลบ — ยืนยันว่าการลบเป็นไปได้ทางกฎหมาย (คุณลบ record ที่เกี่ยวกับสัญญา active หรือภาระทางกฎหมายต่อเนื่องไม่ได้) ถ้าอนุญาต ลบทันที + log การลบ + ส่งอีเมลยืนยันให้ data subject
การกระทำทั้งหมด log ถ้าผู้กำกับถาม "พิสูจน์ว่าคุณตอบสนองคำขอของ data subject นี้ภายใน 30 วัน" log แสดง timestamp คำขอที่ได้รับ timestamp การกระทำ timestamp การตอบส่ง และพนักงานที่ประมวลผล
ขั้นตอนที่ 4 — Auto-purge การเก็บรักษา
วันละครั้งตอน 3 โมงเช้าเวลากรุงเทพ DevProp run การ purge การเก็บรักษา:
- ลีดที่ไม่มีการติดต่อใน 3 ปี → anonymize (ชื่อ/โทรศัพท์/อีเมลแทนด้วย hash เนื้อหาข้อความเก็บเฉพาะสำหรับสถิติรวม)
- ลีดที่ไม่มีการติดต่อใน 5 ปี → ลบเต็ม
- สัญญาเก่ากว่า 7 ปี → archive ไปยัง PDF/A ข้อมูล raw ลบ
- ดีลที่ปิดเก่ากว่า 10 ปี → ลบเต็ม
คุณ override ดีฟอลต์เหล่านี้ต่อ record (เช่น flag contact มูลค่าสูงเป็น "do not auto-purge" จนกว่าจะ review ด้วยมือ) Override log
ขั้นตอนที่ 5 — Audit log (ที่ผู้กำกับดูก่อน)
Reports → PDPA → Audit log การเข้าถึงข้อมูลส่วนบุคคลทุกครั้ง log: ใคร เมื่อไร record อะไร action อะไร ถ้าผู้กำกับ audit คุณ นี่คือหลักฐานหลัก
สำหรับเอเจนซี่ developer-direct ที่จัดการลีดหลายร้อยต่อเดือน ตั้งค่า access alerts (Settings → Security → Alerts) ถ้าเอเจนต์เข้าถึง >50 ลีดในชั่วโมง คุณได้รับการแจ้งเตือน นี่คือรูปแบบ audit ที่จับเอเจนต์ Sansiri leak ข้อมูลลีดในปี 2566
การลงโทษโดยย่อ
- ล้มเหลวที่ได้ consent ที่ถูกต้อง: ค่าปรับการบริหารสูงสุด ฿3,000,000 ต่อการละเมิด
- ล้มเหลวที่ตอบสนองคำขอ data subject ภายใน 30 วัน: สูงสุด ฿1,000,000
- ล้มเหลวที่รายงานการรั่วไหลข้อมูลภายใน 72 ชั่วโมง: สูงสุด ฿5,000,000
- การละเมิดข้อมูลที่ละเอียดอ่อน (การแพทย์ ศาสนา ฯลฯ): สูงสุด ฿5,000,000 ต่ออัน
PDPC เร่งการบังคับใช้ในปี 2567-68; คาดว่าจะมีคดีภาคอสังหาฯ มากขึ้นจนถึงปี 2569 โมดูล PDPA ของ DevProp ออกแบบให้เอเจนซี่ของคุณอยู่ฝั่งปลอดภัยของแต่ละภาระหน้าที่เหล่านี้โดยดีฟอลต์
Stuck on this step?
Book a free 20-minute call. We'll walk through it on screen-share.
Book diagnostic