การตั้งค่า PDPA — consent การเก็บรักษา การส่งออก การลบ

PDPA ต้องการอะไรจริงจากคุณ

พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) ของไทยมีผลบังคับใช้กลางปี 2565 และอยู่ในการบังคับใช้อย่างจริงจังตั้งแต่ปี 2567 PDPC (คณะกรรมการคุ้มครองข้อมูลส่วนบุคคล) ออกค่าระงับ Sansiri ฿2.4M ในปี 2567 — ค่าปรับ PDPA ภาคอสังหาฯ ที่ใหญ่ที่สุดถึงปัจจุบัน

ภาระหน้าที่หลัก 6 ของเอเจนซี่คุณ:

1. ฐานทางกฎหมาย — สำหรับข้อมูลส่วนบุคคลทุกชิ้นที่คุณถือ คุณต้องชี้ฐานทางกฎหมายได้ (consent สัญญา ภาระทางกฎหมาย ผลประโยชน์สำคัญ ผลประโยชน์สาธารณะ หรือผลประโยชน์ที่ชอบด้วยกฎหมาย)
2. การจับ consent — เมื่อ consent เป็นฐาน คุณต้องมีหลักฐานว่า data subject ตกลงกับวัตถุประสงค์เฉพาะพร้อมระยะเวลาเก็บและกลไกการถอนอธิบาย
3. การจำกัดวัตถุประสงค์ — คุณไม่สามารถใช้ข้อมูลสำหรับวัตถุประสงค์เกินกว่าที่ data subject ตกลง
4. ขีดจำกัดการเก็บรักษา — คุณต้องลบข้อมูลส่วนบุคคลเมื่อระยะเวลาเก็บสิ้นสุดหรือวัตถุประสงค์บรรลุ
5. สิทธิ data subject — คุณต้องตอบสนองคำขอเข้าถึง แก้ไข ลบ และพกพาภายใน 30 วัน
6. ความปลอดภัย — มาตรการทางเทคนิคและองค์กรที่เหมาะสมเพื่อป้องกันการเข้าถึงโดยไม่ได้รับอนุญาตหรือสูญหาย

วิธี DevProp จัดการแต่ละภาระหน้าที่โดยดีฟอลต์

1. ฐานทางกฎหมาย — ฟิลด์ข้อมูลส่วนบุคคลทุกฟิลด์ tag กับฐานที่ระดับ schema อีเมลลูกค้า = ผลประโยชน์ที่ชอบด้วยกฎหมาย (ติดต่อ) ชื่อแสดง LINE = consent บัตรประชาชนไทย = การปฏิบัติตามสัญญา (จำเป็นสำหรับสัญญา ETA)
2. การจับ consent — เมื่อลีดเข้ามาผ่าน LINE/web form สตริง consent ถูกจับด้วย timestamp, IP, วัตถุประสงค์ และเวอร์ชันของ privacy policy ของคุณตอนนั้น เก็บใน audit log ของลีด
3. การจำกัดวัตถุประสงค์ — การ export และรายงานเคารพ tag วัตถุประสงค์ คุณไม่สามารถ export รายการลีดที่ตกลงเฉพาะ "ติดต่อเกี่ยวกับประกาศสุขุมวิท" สำหรับ "แคมเปญ marketing ภูเก็ต"
4. ขีดจำกัดการเก็บรักษา — Settings → PDPA → Retention rules ดีฟอลต์: 3 ปีจากการติดต่อล่าสุดสำหรับลีด active 1 ปีสำหรับลีดเย็น 7 ปีสำหรับดีลที่ปิด (จำเป็นโดยกฎหมายบัญชีไทย) หลังการเก็บรักษา record ถูก anonymize อัตโนมัติหรือลบ
5. สิทธิ data subject — การเข้าถึง/ส่งออก/ลบคลิกเดียวจาก record ลีด (ดู Step 3 ด้านล่าง)
6. ความปลอดภัย — การเข้ารหัส 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 จุดจับดีฟอลต์:

1. ฟอร์มติดต่อเว็บไซต์ — checkbox "ฉันยินยอมให้ [เอเจนซี่] ติดต่อเกี่ยวกับโอกาสอสังหาฯ ที่ตรงเกณฑ์ของฉัน" บันทึก IP + ข้อมูลฟอร์ม + เวอร์ชัน policy
2. ข้อความ LINE OA ครั้งแรก — Nisa ส่งอัตโนมัติ "ยินดีต้อนรับ! ก่อนเราดำเนินการต่อ โปรดยืนยันคุณตกลงนโยบายความเป็นส่วนตัวของเรา: [link] ตอบ YES เพื่อดำเนินการต่อ" บันทึก LINE user ID + timestamp + ข้อความตอบ
3. การถามทางโทรศัพท์ — เอเจนต์อ่าน disclosure ตามสคริปต์ ("การโทรนี้อาจถูกบันทึก คุณยินยอมให้ฉันเก็บรายละเอียดติดต่อของคุณเพื่อติดตามคำถามของคุณหรือไม่?") และคลิก Confirm บันทึกชื่อเอเจนต์ + timestamp + ชื่อลีด
4. การเข้าชมเดินเข้ามา — แท็บเล็ตหรือฟอร์มกระดาษ เอเจนต์ติ๊ก box แทนลีด บันทึกชื่อเอเจนต์ + timestamp + ลายเซ็นลีด (ถ้ากระดาษ สแกน)

ขั้นตอนที่ 3 — ตอบสนองคำขอ data subject

เมื่อมีคนส่งข้อความถึงคุณ "คุณมีข้อมูลอะไรเกี่ยวกับฉัน และโปรดลบ" ไปที่ record ลีด → Actions → PDPA request สามตัวเลือก:

1. เข้าถึง — สร้าง PDF ที่มีฟิลด์ทุกอัน รายการ log ทุกอัน ข้อความทุกอัน สัญญาทุกอัน ส่งให้ data subject
2. แก้ไข — พวกเขาบอกอะไรผิด คุณแก้ฟิลด์และ audit log จับ ใคร เมื่อไร และอะไรเปลี่ยน
3. การลบ — ยืนยันว่าการลบเป็นไปได้ทางกฎหมาย (คุณลบ record ที่เกี่ยวกับสัญญา active หรือภาระทางกฎหมายต่อเนื่องไม่ได้) ถ้าอนุญาต ลบทันที + log การลบ + ส่งอีเมลยืนยันให้ data subject

การกระทำทั้งหมด log ถ้าผู้กำกับถาม "พิสูจน์ว่าคุณตอบสนองคำขอของ data subject นี้ภายใน 30 วัน" log แสดง timestamp คำขอที่ได้รับ timestamp การกระทำ timestamp การตอบส่ง และพนักงานที่ประมวลผล

ขั้นตอนที่ 4 — Auto-purge การเก็บรักษา

วันละครั้งตอน 3 โมงเช้าเวลากรุงเทพ DevProp run การ purge การเก็บรักษา:

1. ลีดที่ไม่มีการติดต่อใน 3 ปี → anonymize (ชื่อ/โทรศัพท์/อีเมลแทนด้วย hash เนื้อหาข้อความเก็บเฉพาะสำหรับสถิติรวม)
2. ลีดที่ไม่มีการติดต่อใน 5 ปี → ลบเต็ม
3. สัญญาเก่ากว่า 7 ปี → archive ไปยัง PDF/A ข้อมูล raw ลบ
4. ดีลที่ปิดเก่ากว่า 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

การลงโทษโดยย่อ

1. ล้มเหลวที่ได้ consent ที่ถูกต้อง: ค่าปรับการบริหารสูงสุด ฿3,000,000 ต่อการละเมิด
2. ล้มเหลวที่ตอบสนองคำขอ data subject ภายใน 30 วัน: สูงสุด ฿1,000,000
3. ล้มเหลวที่รายงานการรั่วไหลข้อมูลภายใน 72 ชั่วโมง: สูงสุด ฿5,000,000
4. การละเมิดข้อมูลที่ละเอียดอ่อน (การแพทย์ ศาสนา ฯลฯ): สูงสุด ฿5,000,000 ต่ออัน

PDPC เร่งการบังคับใช้ในปี 2567-68; คาดว่าจะมีคดีภาคอสังหาฯ มากขึ้นจนถึงปี 2569 โมดูล PDPA ของ DevProp ออกแบบให้เอเจนซี่ของคุณอยู่ฝั่งปลอดภัยของแต่ละภาระหน้าที่เหล่านี้โดยดีฟอลต์