วิธี Audit PDPA สำหรับอสังหาริมทรัพย์ ของธุรกิจ SaaS สตาร์ทอัพ และบริษัทเทคโนโลยี พร้อม Evidence ที่ควรเก็บ

Audit PDPA สำหรับแพลตฟอร์มอสังหาริมทรัพย์ต้องแยกตรวจข้อมูลตามช่วงของธุรกรรม ตั้งแต่ผู้สนใจสอบถาม การนัดชมทรัพย์ การยื่นใบสมัครซื้อ/เช่า ไปจนถึงสัญญา เพราะแต่ละช่วงเก็บข้อมูลต่างระดับความอ่อนไหวกัน โดยเฉพาะเอกสารการเงินและบัตรประชาชนที่ต้องมีการควบคุมการเข้าถึงและระยะเวลาเก็บรักษาที่ชัดเจนกว่าข้อมูลติดต่อทั่วไป การ Audit ที่ดีต้องมี Evidence เป็นลายลักษณ์อักษรของทุกขั้นตอน ไม่ใช่แค่คำยืนยันด้วยปาก

ทีม Product หลายบริษัทที่สร้างแพลตฟอร์มอสังหาริมทรัพย์เข้าใจผิดว่าการ Audit PDPA คือการเช็คแบนเนอร์คุกกี้กับฟอร์มสมัครสมาชิกเหมือนแอปทั่วไป ความจริงคือแพลตฟอร์มที่พาผู้ใช้ผ่านขั้นตอนตั้งแต่สนใจโครงการ นัดชมยูนิต ยื่นใบสมัครกู้หรือเช่า ไปจนถึงเซ็นสัญญา เก็บข้อมูลอย่างน้อยสามระดับความอ่อนไหวในระบบเดียวกัน ตั้งแต่ชื่อเบอร์โทรของคนโทรมาถามราคา ไปจนถึงสลิปเงินเดือน Statement บัญชี และสำเนาบัตรประชาชนของคนที่ผ่านเข้าสู่ขั้นยื่นสัญญาจริง การ Audit แบบเหมารวมทุกฟิลด์ในมาตรฐานเดียวจึงมองข้ามความเสี่ยงตรงจุดที่สำคัญที่สุด

ทำไม Audit ข้อมูลอสังหาริมทรัพย์ถึงต่างจากธุรกิจ SaaS ทั่วไป

ธุรกิจ SaaS ทั่วไปมักมีข้อมูลลูกค้าเป็นชุดเดียวที่ความอ่อนไหวใกล้เคียงกัน แต่แพลตฟอร์มอสังหาริมทรัพย์พาผู้ใช้เดินทางผ่าน funnel ที่ยาวและมีจุดเปลี่ยนสถานะชัดเจน คนที่กรอกฟอร์ม "ขอข้อมูลโครงการ" กับคนที่อัปโหลด Statement ธนาคารเพื่อขอสินเชื่อ ไม่ควรถูกจัดเก็บและควบคุมสิทธิ์การเข้าถึงในระดับเดียวกัน นอกจากนี้สัญญาเช่าหรือสัญญาซื้อขายมีอายุสัญญาหลายปี ข้อมูลที่ผูกกับสัญญาจึงต้องถูกเก็บยาวนานกว่าข้อมูลการทำธุรกรรม e-commerce ทั่วไปที่ปิดเคสได้ภายในไม่กี่สัปดาห์ การ Audit ที่ไม่ได้ออกแบบมาให้ตอบโจทย์ช่วงชีวิตของสัญญาแบบนี้จะมองข้ามความเสี่ยงตรงรอยต่อระหว่างระบบ CRM การขาย กับระบบจัดการสัญญาระยะยาว

อีกจุดที่ทีม Audit มักมองข้ามคือแพลตฟอร์มอสังหาริมทรัพย์ส่วนใหญ่ไม่ได้สร้างระบบเองทั้งหมด แต่ต่อ API เข้ากับผู้ให้บริการภายนอกหลายเจ้าพร้อมกัน ทั้งระบบยืนยันตัวตน ระบบตรวจเครดิต ระบบเซ็นสัญญาดิจิทัล และระบบชำระเงินค่ามัดจำ แต่ละจุดเชื่อมต่อคือช่องทางที่ข้อมูลอ่อนไหวไหลออกจากระบบหลัก การ Audit ที่ตรวจแค่ดาต้าเบสภายในโดยไม่ไล่ตามเส้นทางข้อมูลที่ส่งออกไปยังผู้ให้บริการเหล่านี้ จึงเห็นภาพไม่ครบว่าข้อมูลของผู้สมัครไปอยู่ที่ไหนบ้างในช่วงเวลาหนึ่ง

5 จุดที่ต้อง Audit ในระบบ Proptech SaaS

1. ขั้นตอนสอบถามและลงทะเบียนความสนใจ (Inquiry)

ตรวจว่าฟอร์มลงทะเบียนเก็บข้อมูลอะไรบ้าง ส่วนใหญ่คือชื่อ เบอร์โทร อีเมล และงบประมาณคร่าวๆ ให้ตรวจว่าทีม Sales หรือ Marketing เก็บข้อมูลเกินความจำเป็นหรือไม่ เช่น ขอเลขบัตรประชาชนตั้งแต่ขั้นตอนนี้ทั้งที่ยังไม่ถึงขั้นทำสัญญา และตรวจว่ามีการแจ้งวัตถุประสงค์การเก็บข้อมูลตั้งแต่จุดแรกที่กรอกฟอร์มหรือไม่

ประเด็นที่ควรตรวจเพิ่มเติมคือฟอร์มลงทะเบียนบางแบบซ่อนช่องกรอก "รายได้โดยประมาณ" หรือ "อาชีพ" ไว้ในขั้นตอนแรกโดยอ้างว่าใช้แนะนำโครงการที่เหมาะสม ข้อมูลลักษณะนี้ยังไม่ถึงขั้นเอกสารการเงินจริง แต่ก็เป็นข้อมูลที่บ่งชี้ฐานะทางเศรษฐกิจของบุคคล ควรตรวจว่าทีมการตลาดมีเหตุผลใช้งานที่ชัดเจนสำหรับฟิลด์เหล่านี้ หรือเก็บไว้เผื่อใช้ในอนาคตโดยไม่มีแผนใช้งานจริง ซึ่งเป็นรูปแบบการเก็บข้อมูลเกินความจำเป็นที่พบได้บ่อยในหน้าลงทะเบียนโครงการอสังหาริมทรัพย์

2. ขั้นตอนนัดชมทรัพย์และ CCTV ที่ยูนิตตัวอย่าง

โครงการอสังหาริมทรัพย์ส่วนใหญ่ติดกล้องวงจรปิดที่ห้องตัวอย่างหรือสำนักงานขาย ตรวจว่าระบบ SaaS มีการเชื่อมข้อมูลผู้เข้าชมกับภาพจากกล้องหรือไม่ ถ้ามี ต้องมีป้ายแจ้งเตือนบริเวณจุดติดตั้งกล้อง กำหนดระยะเวลาเก็บภาพที่ชัดเจน และจำกัดคนที่เข้าถึงคลิปได้เฉพาะทีมความปลอดภัยหรือทีมที่เกี่ยวข้องโดยตรง ไม่ใช่ทีม Sales ทั้งหมด

3. ขั้นตอนยื่นใบสมัครซื้อหรือเช่า

นี่คือจุดที่ข้อมูลอ่อนไหวเข้าสู่ระบบมากที่สุด ได้แก่ สำเนาบัตรประชาชนหรือพาสปอร์ต สลิปเงินเดือน หนังสือรับรองรายได้ Statement บัญชีย้อนหลัง และในบางกรณีผลตรวจเครดิตบูโร ตรวจว่าฟิลด์เหล่านี้ถูกเก็บแยกจากข้อมูลทั่วไปในดาต้าเบสหรือไม่ มีการเข้ารหัสไฟล์ที่อัปโหลดหรือไม่ และใครมีสิทธิ์ดาวน์โหลดไฟล์เหล่านี้ได้บ้าง

ในหลายระบบที่ทีมงานตรวจเจอ ไฟล์อัปโหลดของผู้สมัครถูกเก็บไว้ในบัคเก็ตเดียวกันแบบเปิด URL ตรงได้โดยไม่ผ่านการตรวจสอบสิทธิ์ ทำให้ใครก็ตามที่มีลิงก์สามารถเปิดดูสำเนาบัตรประชาชนของผู้สมัครคนอื่นได้ทันทีถ้าเดารูปแบบชื่อไฟล์ถูก จุดนี้ควรตรวจเป็นพิเศษเพราะเป็นความเสี่ยงที่พบซ้ำหลายครั้งในระบบที่เร่งพัฒนาฟีเจอร์เพื่อออกตลาดเร็ว

4. ขั้นตอนตรวจสอบและอนุมัติสินเชื่อ (Underwriting)

ขั้นตอนนี้มักมีการส่งข้อมูลออกไปยังธนาคารพันธมิตรหรือผู้ให้บริการตรวจเครดิตภายนอก ตรวจว่ามีข้อตกลงประมวลผลข้อมูล (Data Processing Agreement) กับพันธมิตรเหล่านี้หรือไม่ และตรวจว่าระบบส่งเฉพาะข้อมูลที่จำเป็นต่อการอนุมัติสินเชื่อ ไม่ใช่ส่งฐานข้อมูลทั้งก้อนออกไป

บางแพลตฟอร์มออกแบบให้เรียก API ของบริษัทตรวจเครดิตแบบเรียลไทม์ทันทีที่ผู้ใช้กดปุ่ม "ตรวจสอบวงเงินโดยประมาณ" ก่อนที่จะรู้ด้วยซ้ำว่าผู้ใช้จะยื่นสมัครจริงหรือไม่ ตรงนี้ควรตรวจว่าผู้ใช้เห็นข้อความอธิบายชัดเจนก่อนกดปุ่มว่าข้อมูลของตนกำลังจะถูกส่งออกไปตรวจกับหน่วยงานภายนอก ไม่ใช่ซ่อนอยู่ในข้อความยินยอมยาวๆ ที่ไม่มีใครอ่าน

5. ขั้นตอนหลังเซ็นสัญญาและการเก็บรักษาระยะยาว

เมื่อสัญญาเช่าหรือสัญญาซื้อขายมีผล ข้อมูลผู้เช่าหรือผู้ซื้อจะถูกอ้างอิงตลอดอายุสัญญาซึ่งอาจยาวหลายปี ตรวจว่ามีนโยบายกำหนดวันหมดอายุการเก็บข้อมูลหลังสัญญาสิ้นสุด และมีกระบวนการลบหรือทำให้ข้อมูลไม่ระบุตัวตนเมื่อพ้นระยะที่กฎหมายหรือข้อบังคับภายในกำหนด แทนที่จะปล่อยให้ข้อมูลค้างอยู่ในระบบอย่างไม่มีกำหนด

ทีมที่เคยผ่านขั้นตอนนี้เล่าให้ฟังว่าปัญหาจริงมักไม่ใช่การไม่มีนโยบาย แต่เป็นการที่นโยบายเขียนไว้ในเอกสารกลางบริษัทแต่ไม่เคยถูกนำมาผูกกับระบบจริง สัญญาหมดอายุไปแล้วหลายปีแต่ข้อมูลผู้เช่ายังอยู่ในดาต้าเบสหลักเหมือนเดิม เพราะไม่มีสคริปต์หรือกระบวนการอัตโนมัติมาตรวจสอบวันหมดอายุสัญญาแล้วแจ้งเตือนทีมให้ดำเนินการ การ Audit จึงควรถามคำถามที่ตรงจุดกว่านั้น คือมีระบบใดเชื่อมโยงวันหมดอายุสัญญาเข้ากับกระบวนการทบทวนข้อมูลจริงหรือไม่ ไม่ใช่แค่ถามว่ามีนโยบายเป็นลายลักษณ์อักษรหรือเปล่า

Evidence ที่ควรเก็บในแต่ละขั้นตอน

การแชร์ข้อมูลกับธนาคารและผู้ตรวจสอบเครดิต

แพลตฟอร์ม Proptech หลายเจ้าเสนอบริการเชื่อมต่อกับธนาคารเพื่อช่วยผู้ซื้อยื่นขอสินเชื่อในหน้าเดียวกับการสมัครซื้อบ้าน จุดนี้ควรตรวจสามเรื่อง คือผู้ใช้ให้ความยินยอมแยกต่างหากสำหรับการส่งข้อมูลไปยังธนาคารหรือไม่ มีการระบุชื่อธนาคารหรือกลุ่มพันธมิตรที่จะได้รับข้อมูลอย่างชัดเจนหรือไม่ และมีช่องทางให้ผู้ใช้ปฏิเสธการส่งข้อมูลไปยังบุคคลที่สามโดยยังใช้บริการหลักของแพลตฟอร์มต่อได้หรือไม่ ถ้าระบบบังคับให้ต้องยินยอมส่งข้อมูลให้ธนาคารก่อนถึงจะดูรายละเอียดโครงการได้ นั่นคือสัญญาณว่าการออกแบบ consent มีปัญหา

ตัวอย่างสถานการณ์ที่ทีม Audit มักเจอจริง

ทีม Growth ของแพลตฟอร์มหนึ่งเคยเพิ่มฟีเจอร์ "ประเมินวงเงินกู้ล่วงหน้าใน 30 วินาที" เพื่อดึงคนให้กรอกข้อมูลเร็วขึ้น โดยให้ผู้ใช้กรอกเลขบัตรประชาชนและเงินเดือนตั้งแต่หน้าแรกก่อนแม้แต่จะดูรายละเอียดโครงการ ผลคือมีข้อมูลอ่อนไหวจำนวนมากถูกเก็บไว้จากคนที่แค่อยากรู้ราคาคร่าวๆ แล้วไม่เคยกลับมาสมัครจริง กลายเป็นข้อมูลค้างสต๊อกที่ไม่มีใครดูแลต่อ เพราะทีม Sales มองว่าเป็น "ลีดที่ยังไม่ปิด" ไม่ใช่ "ข้อมูลอ่อนไหวที่ต้องมีคนรับผิดชอบ" อีกกรณีคือทีมเทคนิคของโครงการคอนโดแห่งหนึ่งพบว่าไฟล์วิดีโอจากกล้อง CCTV ที่ห้องตัวอย่างถูกอัปโหลดขึ้นระบบคลาวด์เดียวกับไฟล์การตลาดทั่วไป โดยไม่มีการจำกัดสิทธิ์แยกต่างหาก จนกระทั่งมีการ Audit จึงพบว่าพนักงานฝ่ายการตลาดที่ไม่เกี่ยวข้องกับความปลอดภัยเลยสามารถเปิดดูคลิปได้เช่นกัน ทั้งสองกรณีนี้ไม่ได้เกิดจากความตั้งใจทำผิด แต่เกิดจากการไม่มีใครตั้งคำถามตั้งแต่ตอนออกแบบฟีเจอร์ว่าข้อมูลที่กำลังจะเก็บนั้นควรมีใครเข้าถึงได้บ้าง

ข้อผิดพลาดที่พบบ่อยเมื่อ Audit PDPA อสังหาริมทรัพย์

• เก็บสำเนาบัตรประชาชนไว้ในโฟลเดอร์เดียวกับข้อมูลลงทะเบียนทั่วไป โดยไม่มีการเข้ารหัสหรือแยกสิทธิ์การเข้าถึง
• ทีม Sales ทั้งทีมเข้าถึง Statement การเงินของผู้สมัครทุกคนได้ ทั้งที่ควรจำกัดเฉพาะทีมสินเชื่อ
• ไม่มีการกำหนดวันลบข้อมูลหลังสัญญาสิ้นสุด ทำให้ข้อมูลผู้เช่าเก่าค้างอยู่ในระบบเป็นสิบปี
• ส่งข้อมูลให้ธนาคารพันธมิตรโดยไม่มีข้อตกลงประมวลผลข้อมูลเป็นลายลักษณ์อักษร
• ติดกล้อง CCTV ที่ห้องตัวอย่างโดยไม่มีป้ายแจ้งเตือน หรือเก็บภาพไว้นานเกินความจำเป็น

สรุป: Audit ต้องเป็นรอบ ไม่ใช่ครั้งเดียวจบ

การ Audit PDPA สำหรับแพลตฟอร์มอสังหาริมทรัพย์ควรทำเป็นรอบสม่ำเสมอ เพราะทุกครั้งที่มีฟีเจอร์ใหม่ เช่น เพิ่มการเชื่อมต่อธนาคารใหม่ หรือเพิ่มขั้นตอนตรวจเครดิตอัตโนมัติ จุดเสี่ยงใหม่จะเกิดขึ้นตามมา ทีม Privacy ควรกำหนดรอบ Audit อย่างน้อยทุกหกเดือน และทุกครั้งที่มีการเปลี่ยนแปลงขั้นตอนสำคัญในระบบ การเก็บ Evidence ไว้เป็นลายลักษณ์อักษรตลอดทางช่วยให้ทีมตอบคำถามได้เร็วเมื่อผู้บริหารหรือคู่ค้าถามถึงแนวทางจัดการข้อมูล และช่วยให้เห็นจุดที่ต้องปรับปรุงก่อนที่จะกลายเป็นปัญหาจริง

สิ่งที่ทีมควรทำต่อจากการ Audit ครั้งแรกคือกำหนดเจ้าของงานให้ชัดเจนสำหรับแต่ละจุดเสี่ยง เช่น ให้ทีม Engineering รับผิดชอบเรื่องสิทธิ์การเข้าถึงไฟล์และการเข้ารหัส ให้ทีม Legal หรือ Compliance รับผิดชอบเรื่องข้อตกลงกับธนาคารและผู้ให้บริการภายนอก และให้ทีม Operations รับผิดชอบเรื่องกำหนดวันลบข้อมูลหลังสัญญาสิ้นสุด การกระจายความรับผิดชอบแบบนี้ทำให้ Audit รอบถัดไปเร็วขึ้น เพราะแต่ละทีมรู้อยู่แล้วว่าต้องเตรียม Evidence ส่วนไหนมาแสดง แทนที่จะต้องไล่ตามหาคำตอบใหม่ทุกครั้งที่มีคนถาม

อ่านเพิ่มเติมเกี่ยวกับการวางระบบตั้งแต่ต้นได้ที่ วิธีวางระบบ PDPA สำหรับอสังหาริมทรัพย์ในแพลตฟอร์ม SaaS และดูรายการตรวจสอบก่อนเปิดใช้งานฟีเจอร์ใหม่ได้ที่ เช็กลิสต์ PDPA สำหรับอสังหาริมทรัพย์

แหล่งข้อมูลอ้างอิง

แนวทางในบทความนี้อ้างอิงหลักการทั่วไปจากสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) ทีม Privacy ควรตรวจสอบประกาศและแนวปฏิบัติล่าสุดจากเว็บไซต์ PDPC โดยตรงก่อนนำไปปรับใช้ในสัญญาและนโยบายภายในของบริษัท และดูภาพรวมกฎเกณฑ์อื่นที่เกี่ยวข้องกับธุรกิจได้ที่ หมวดความรู้ธุรกิจและอุตสาหกรรม