PDPA สำหรับอสังหาริมทรัพย์ คืออะไร? คู่มือสำหรับธุรกิจ SaaS สตาร์ทอัพ และบริษัทเทคโนโลยี

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

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

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

ข้อมูลอะไรบ้างที่ธุรกิจ SaaS ด้านอสังหาฯ เก็บในแต่ละขั้นตอน

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

ช่วงที่สามคือการยื่นใบสมัครเช่าหรือซื้อ (application) ซึ่งเป็นจุดที่ระดับความอ่อนไหวพุ่งขึ้นทันที เพราะต้องขอสำเนาบัตรประชาชนหรือพาสปอร์ตสำหรับกระบวนการคล้าย KYC ของการจดทะเบียนทรัพย์ ขอสลิปเงินเดือนหรือหนังสือรับรองรายได้ และในหลายกรณีขอความยินยอมให้ตรวจเครดิตบูโรผ่านธนาคารพันธมิตร ช่วงสุดท้ายคือสัญญา (contract) ที่ข้อมูลทั้งหมดถูกผูกเข้ากับเอกสารสัญญาเช่าหรือสัญญาซื้อขายและต้องเก็บต่อเนื่องตลอดอายุสัญญา ทีม Product ควรทำแผนที่ข้อมูล (data map) แยกตามสี่ช่วงนี้ เพื่อให้เห็นชัดว่าจุดไหนต้องยกระดับการป้องกันมากกว่าจุดอื่น

• ช่วงสอบถาม: ชื่อ เบอร์โทร งบประมาณ ความเสี่ยงต่ำ
• ช่วงนัดชม: ตารางนัด ภาพกล้องวงจรปิดบริเวณส่วนกลาง
• ช่วงยื่นใบสมัคร: บัตรประชาชน สลิปเงินเดือน ผลตรวจเครดิต
• ช่วงสัญญา: เอกสารผูกกับสัญญาเช่าหรือซื้อขายระยะยาว

เอกสารการเงินและบัตรประชาชนต้องเข้มงวดกว่าข้อมูลติดต่อทั่วไปอย่างไร

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

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

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

แพลตฟอร์ม proptech จำนวนมากมีจุดเชื่อมกับธนาคารพันธมิตรสำหรับส่งต่อคำขอสินเชื่อ หรือกับผู้ให้บริการตรวจสอบประวัติสำหรับคัดกรองผู้เช่า จุดนี้คือจุดที่ข้อมูลออกจากการควบคุมของแพลตฟอร์มเองไปสู่บุคคลที่สาม ทีม Engineering ควรมีข้อตกลงประมวลผลข้อมูล (data processing agreement) ที่ระบุชัดว่าธนาคารหรือผู้ให้บริการตรวจสอบประวัตินำข้อมูลไปใช้เพื่อวัตถุประสงค์ใดเท่านั้น ไม่ใช่นำไปใช้ทำการตลาดต่อ

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

วงจรชีวิตของสัญญาเช่าหรือสัญญาซื้อขายกับระยะเวลาการเก็บข้อมูล

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

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

ตัวอย่างบริบทธุรกิจที่แตะข้อมูลอสังหาริมทรัพย์แบบเดียวกัน

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

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

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

จะตรวจสอบระบบนี้อย่างต่อเนื่องได้อย่างไร: How-to Audit Checklist และ Freshness Update

คู่มือฉบับนี้เป็นภาพรวมของคลัสเตอร์ ทีมที่ต้องการลงมือทำจริงสามารถแยกไปตามงานที่ต้องทำ บทความแบบ How-to จะพาไล่ทีละขั้นตอนตั้งแต่ทำแผนที่ข้อมูลไปจนถึงตั้งค่าสิทธิ์เข้าถึง บทความแบบ Audit Guide จะโฟกัสที่การตรวจทานเป็นรอบ เช่น ไตรมาสละครั้ง ว่าสิทธิ์เข้าถึงเอกสารการเงินยังจำกัดตามที่ออกแบบไว้จริงหรือไม่ บทความแบบ Checklist จะให้รายการตรวจก่อนเปิดฟีเจอร์ใหม่ที่แตะข้อมูลผู้เช่าหรือผู้ซื้อ และบทความแบบ Freshness Update จะสรุปว่าปีนี้มีอะไรเปลี่ยนไปที่ทีมควรตรวจทานซ้ำ

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

ข้อผิดพลาดที่พบบ่อยของทีม Product และ Engineering สาย Proptech

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

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

ข้อผิดพลาดที่ห้าซึ่งเกิดขึ้นบ่อยกับทีมที่โตเร็วคือการเปิด API scope ให้พันธมิตรภายนอก เช่น เอเจนซี่การตลาดหรือผู้ให้บริการขนย้าย กว้างเกินกว่าขั้นตอนที่พันธมิตรรายนั้นควรเห็นจริง เพราะช่วงเริ่มต้นทีม Engineering มักออกแบบ endpoint เดียวให้ทุกฝ่ายเรียกใช้เพื่อความสะดวกในการพัฒนา แล้วลืมกลับมาตัดสิทธิ์ให้แคบลงเมื่อระบบใช้งานจริงในวงกว้างขึ้น

สรุป: จุดเริ่มต้นสำหรับทีม SaaS อสังหาฯ

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

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

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