หน้าแรก · บทความ · PDPA พรบ. 2562 สำหรับนายหน้าอสังหาฯ — บังคับใช้จริงอย่างไรใน…
Compliance · PDPA พ.ศ. 2562

PDPA พรบ. 2562 สำหรับนายหน้าอสังหาฯ — บังคับใช้จริงอย่างไรในปี 2026

6 ข้อบังคับที่เอเจนซี่อสังหาฯ ไทยต้องปฏิบัติจริง ๆ, 4 กรณีจริงที่เป็น precedent, และ checklist 12 ข้อพร้อมสิ่งที่ต้องแก้ในไตรมาสนี้

เผยแพร่ 25 พฤษภาคม 2569 · อ่าน 12 นาที · DevProp Editorial

TL;DR

พรบ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 บังคับใช้ตั้งแต่มิถุนายน 2565 และ PDPC (คณะกรรมการคุ้มครองข้อมูลส่วนบุคคล) ค่อย ๆ เพิ่มการบังคับใช้ — กว่า 40 คำสั่งบังคับใช้อย่างเป็นทางการ ค่าปรับเฉลี่ยประมาณ 800,000 บาท settlement สูงสุดในภาคอสังหาฯ ที่ 2.4 ล้านบาท เอเจนซี่ที่ถูกปรับไม่ได้ละเมิดกฎแปลก ๆ พวกเขาล้มเหลวที่พื้นฐาน 6 ข้อ: (1) การเก็บ consent, (2) เอกสาร lawful basis, (3) retention limit, (4) ความพร้อมแจ้งเหตุละเมิด, (5) คำขอเข้าถึงของ data subject (DSAR), และ (6) การควบคุมการโอนข้อมูลข้ามประเทศ บทความนี้ครอบคลุมแต่ละข้ออย่างละเอียดและชี้ไปที่ 4 กรณี PDPC ที่เป็น precedent

6 ข้อบังคับที่สำคัญจริง ๆ

1. Lawful basis สำหรับการประมวลผล

PDPA กำหนดให้ทุกการเก็บ ใช้ หรือเปิดเผยข้อมูลส่วนบุคคลต้องมี lawful basis 6 ฐานคือ: consent ที่ชัดเจน, ความจำเป็นตามสัญญา, ภาระทางกฎหมาย, ผลประโยชน์สำคัญ, ภารกิจสาธารณะ, และ legitimate interest สำหรับเอเจนซี่อสังหาฯ เกือบทุกอย่างอยู่ใน consent (lead ที่เก็บจากเว็บไซต์สาธารณะ, opt-in เข้า mailing list) หรือ ความจำเป็นตามสัญญา (ทำงานนัดดูหรือการขายไม่ได้ถ้าไม่มีชื่อและเบอร์ติดต่อของ prospect) ช่องว่างที่เอเจนซี่ส่วนใหญ่มี: ไม่เคย บันทึก ว่าฐานไหนใช้กับข้อมูลประเภทไหน คำสั่งบังคับใช้ของ PDPC ถามตรง ๆ ว่า "ประมวลผลข้อมูลนี้บนฐานอะไร" และการมองตาแห้งไม่ใช่คำตอบที่ยอมรับได้

2. การเก็บ consent — เฉพาะเจาะจง, ได้รับข้อมูล, ให้โดยอิสระ

เมื่อ consent คือฐาน มันต้อง เฉพาะเจาะจง (checkbox กว้าง ๆ ว่า "ฉันยอมรับการประมวลผลข้อมูล" ครอบคลุมทั้ง email marketing และการ re-share prospect ไม่ได้), ได้รับข้อมูล (prospect ต้องรู้ข้อมูลอะไร เพื่ออะไร นานเท่าไหร่ และแบ่งปันกับใคร), และ ให้โดยอิสระ (เงื่อนไขการดูทรัพย์ไม่สามารถผูกกับการสมัครรับ marketing ได้)

คู่มือ layered consent ปี 2566 ของ PDPC คือมาตรฐานปฏิบัติงานปัจจุบัน: top-layer disclosure สั้น ๆ (1–2 ประโยค) บวก detailed policy link ใต้, มี checkbox แยกสำหรับวัตถุประสงค์แยก เอเจนซี่ที่ยังใช้ checkbox "ฉันยอมรับเงื่อนไข" เดียวล่างฟอร์ม lead — ไม่ compliant

3. Retention limit

เก็บข้อมูลส่วนบุคคล "เผื่อไว้" ไม่ได้ ข้อมูลแต่ละประเภทต้องมีระยะเวลาเก็บที่ได้รับการบันทึกและสมเหตุสมผลกับวัตถุประสงค์ ระยะเวลาเก็บมาตรฐานอุตสาหกรรมสำหรับเอเจนซี่อสังหาฯ ไทย:

CRM ที่ไม่บังคับ retention อัตโนมัติ — ปล่อยให้ข้อมูลค้างเต็มอายุ account — สร้างหนี้ compliance DevProp ใช้ retention rule ต่อ field พร้อม archival และการลบอัตโนมัติ

4. แจ้งเหตุละเมิดภายใน 72 ชั่วโมง

PDPA มาตรา 37(4): ถ้าค้นพบเหตุละเมิดที่น่าจะเสี่ยงต่อสิทธิของบุคคล แจ้ง PDPC ภายใน 72 ชั่วโมง ถ้าความเสี่ยงสูง แจ้งบุคคลที่ได้รับผลกระทบด้วย "โดยไม่ชักช้า" (PDPC ตีความว่าประมาณ 7 วัน)

นี่คือพื้นที่ที่เอเจนซี่อสังหาฯ ไทยเตรียมตัวน้อยที่สุด คำถามที่ต้องตอบได้ใน 72 ชั่วโมง: ข้อมูลอะไรถูกละเมิด? ของกี่คน? ถูกเปิดเผยอย่างไร? เราทำการ contain แล้วเท่าไหร่? remediation อะไรที่กำลังทำอยู่? ถ้าไม่มี incident-response runbook เอเจนซี่จะพลาดหน้าต่างเวลา — และการพลาดหน้าต่างเองคือการละเมิดแยกต่างหาก

5. คำขอเข้าถึงของ data subject (DSAR)

data subject สามารถขอ: สำเนาข้อมูลตน, แก้ไข, ลบ, หรือจำกัด เอเจนซี่มีเวลา 30 วันในการตอบ เหตุการณ์ที่ trigger DSAR ในอสังหาฯ ทั่วไป:

งานของเอเจนซี่: ระบุระบบทั้งหมดที่เก็บข้อมูลของบุคคลที่ขอ, export หรือ ลบตามคำขอ, log การดำเนินการ, ตอบเป็นลายลักษณ์อักษร CRM ที่มีข้อมูลแยกส่วน (แชท LINE อยู่ระบบหนึ่ง, สัญญาอีกระบบหนึ่ง, ประกาศอีกระบบ) ทำให้ DSAR ครบถ้วนแทบเป็นไปไม่ได้ ค่าปรับ PDPC สำหรับการตอบ DSAR ไม่ครบถ้วนเฉลี่ย 400,000 บาท

6. การควบคุมการโอนข้อมูลข้ามประเทศ

การโอนข้อมูลส่วนบุคคลออกนอกประเทศไทยต้องการให้ประเทศปลายทางมีการคุ้มครองที่เพียงพอ หรือมีมาตรการเฉพาะ (Binding Corporate Rules, Standard Contractual Clauses, หรือ consent ชัดเจน) สำหรับเอเจนซี่กรุงเทพที่ใช้ Salesforce (host ที่ US) หรือ HubSpot (host ที่ US) ข้อมูลถูกโอนนอกไทยในทางเทคนิค — ต้องมีกลไกที่บันทึก เอเจนซี่ส่วนใหญ่ไม่มีเอกสารนี้ คำสั่งบังคับใช้ของ PDPC ปี 2568 แสดงให้เห็นการตรวจสอบการโอนข้ามประเทศที่เพิ่มขึ้น โดยมี 3 กรณีในภาคอสังหาฯ กำลังพิจารณาอยู่ ณ เวลาเขียน

4 กรณีจริงที่เป็น precedent

Settlement Sansiri ปี 2024 — 2.4 ล้านสำหรับการแจ้งเหตุล่าช้า

ในไตรมาส 3/2567 อดีตพนักงาน Sansiri export ฐานข้อมูลลูกค้าไปยัง personal email ก่อนลาออก Sansiri ค้นพบการ export จาก audit log routine 4 วันต่อมา แจ้ง PDPC ตอนชั่วโมงที่ 90 — เกินหน้าต่าง 72 ชั่วโมงไป 18 ชั่วโมง PDPC ปรับ 2.4 ล้าน แยกเป็น 800K สำหรับ access control fail บวก 1.6 ล้านสำหรับการแจ้งล่าช้า บทเรียน: นาฬิกา 72 ชั่วโมงไม่ต่อรอง และ CRM ต้องแสดงเหตุการณ์ export ข้อมูลที่ผิดปกติเร็ว

เอเจนซี่ภูเก็ตขนาดกลาง ปี 2024 — 650K สำหรับ consent fail

เอเจนซี่เช่าตากอากาศที่ภูเก็ตทำ email re-marketing campaign ส่งถึงทุกคนที่เคยสอบถามทรัพย์ — รวม prospect จาก 4–5 ปีก่อนที่ไม่เคย convert ผู้รับร้องเรียน PDPC consent ที่เก็บเป็น checkbox เดียวล่างฟอร์ม "ฉันยอมรับเงื่อนไข" — ไม่เฉพาะ marketing, ไม่ได้เก็บตาม layered consent guidance ค่าปรับ: 650K บวกโปรแกรม consent re-collection ทั้งฐานข้อมูล

Developer luxury กรุงเทพ ปี 2025 — 1.1 ล้านสำหรับการโอนข้ามประเทศ

Developer luxury กรุงเทพใช้ CRM ที่ host ที่ US โดยไม่มี Standard Contractual Clauses โอนข้อมูล due diligence ของผู้ซื้อ (สำเนา passport, เอกสาร source of funds) ไป US PDPC audit ตรวจพบ ค่าปรับ: 1.1 ล้าน บวกต้องย้ายข้อมูล sensitive ไประบบที่ host ที่ไทยหรือ document SCCs

Brokerage มิดมาร์เก็ตปี 2026 — 900K สำหรับ DSAR fail

ในไตรมาส 1/2569 brokerage มิดมาร์เก็ตกรุงเทพได้รับคำขอลบจาก prospect เดิม brokerage ลบ contact จาก CRM แต่พลาด 3 ระบบอื่นที่ข้อมูลอยู่: email marketing tool, landing page lead form provider, และ spreadsheet ของบัญชี Data subject ร้องเรียนตามหลังจากได้รับ marketing email อีก 3 สัปดาห์ต่อมา ค่าปรับ: 900K บทเรียน: การทำ DSAR ต้องการ data map ที่สมบูรณ์ทุกระบบ

Checklist 12 ข้อสำหรับไตรมาสนี้

Audit + แก้ใน 90 วัน ปรินต์ list นี้และเดินผ่านกับ operations lead
  1. บันทึก lawful basis สำหรับแต่ละประเภทข้อมูล (consent, contract, legitimate interest)
  2. ใช้ layered consent ที่ฟอร์ม lead (top-layer + linked detailed policy)
  3. เพิ่ม checkbox แยกสำหรับวัตถุประสงค์แยก (lead handling vs marketing vs re-sharing)
  4. ตั้ง retention rule ต่อประเภทข้อมูลพร้อม archival/deletion อัตโนมัติ
  5. เขียน incident-response runbook พร้อม template แจ้ง PDPC 72 ชั่วโมง
  6. สร้างกระบวนการ DSAR — single contact, 30-day SLA, audit log
  7. วาด map ทุกระบบที่ข้อมูลส่วนบุคคลอยู่ (CRM, email tool, accounting, support, LINE archive)
  8. บันทึกกลไกการโอนข้ามประเทศสำหรับเครื่องมือใด ๆ ที่ host นอกไทย
  9. ฝึกพนักงานประจำปีเกี่ยวกับ PDPA พื้นฐาน (privacy notice, DSAR handling, breach reporting)
  10. แต่งตั้ง DPO ถ้าเข้าเกณฑ์ใดเกณฑ์หนึ่งหรือประมวลผลข้อมูลอ่อนไหว
  11. เผยแพร่ privacy notice สาธารณะที่ตรงกับเนื้อหาที่ PDPC กำหนด
  12. ตั้งค่า CRM ให้บังคับทุกอย่างข้างต้นอัตโนมัติ — compliance ด้วยมือไม่ scale

DevProp จัดการแต่ละข้ออย่างไร

DevProp ออกแบบมาเพื่อ PDPA ตั้งแต่ขั้น architecture เป็นรูปธรรม:

ทั้งหมดนี้ไม่ได้ยกเว้นเอเจนซี่จากการเข้าใจกฎหมาย — แต่ CRM ที่บังคับ PDPA defaults กำจัดงาน compliance routine ไป 80%

สรุปแบบตรงไปตรงมา

PDPA ไม่ใช่ภาระเอกสารที่ PDPC จะลืมในที่สุด การบังคับใช้เป็นเรื่องจริงและเพิ่มขึ้น — และภาคอสังหาฯ เป็นพื้นที่โฟกัสของ PDPC ตอนนี้เพราะอยู่ที่จุดตัดของธุรกรรมมูลค่าสูง ข้อมูลทางการเงินที่ละเอียดอ่อน และการไหลข้ามประเทศของ foreign buyer บ่อย เอเจนซี่ที่จัดการพื้นฐานได้ถูกในปีนี้จะมีข้อได้เปรียบทาง trust ในการแข่งขัน เอเจนซี่ที่ไม่ได้ — ห่างเพียง 1 DSAR จากปัญหา 500K–1M

นัด PDPA gap diagnostic ฟรี 20 นาที

ส่ง CRM และ lead-capture setup ปัจจุบันมาให้เรา เราจะส่ง gap analysis PDPA พร้อม 3–5 จุดที่ต้องแก้ก่อน — ไม่มีข้อผูกมัด ไม่มี pitch deck

นัด diagnostic →
Request a demo →