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

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

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

ขั้นตอนที่ 1: ทำแผนที่การไหลของข้อมูลตั้งแต่ต้นทาง

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

ขั้นตอนที่ 2: กำหนดฐานการประมวลผลให้ตรงกับสิ่งที่แจ้งลูกค้าจริง

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

ขั้นตอนที่ 3: จำกัดสิทธิ์เข้าถึงข้อมูลอัตลักษณ์ระดับหนังสือเดินทาง

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

ขั้นตอนที่ 4: ตั้งอายุการเก็บข้อมูลให้ผูกกับสัญญาหรือกรมธรรม์ ไม่ใช่เก็บไว้เผื่อ

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

ขั้นตอนที่ 5: ตรวจสอบเงื่อนไขการส่งต่อข้อมูลให้พันธมิตรบุคคลที่สาม

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

ขั้นตอนที่ 6: ตั้งรอบตรวจสอบซ้ำ ไม่ใช่ทำครั้งเดียวจบ

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

ตัวอย่างการนำหกขั้นตอนนี้ไปใช้จริงในองค์กรประกันภัย

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

ข้อผิดพลาดที่พบบ่อยเมื่อวางระบบนี้

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

สรุป: ระบบที่ใช้ได้จริงต้องตอบคำถามได้ทุกจุด ไม่ใช่แค่มีนโยบาย

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

แหล่งข้อมูลอ้างอิงและลิงก์ที่เกี่ยวข้อง

ดูภาพรวมทั้งคลัสเตอร์ได้ที่คู่มือ PDPA สำหรับโรงแรมและท่องเที่ยว สำหรับองค์กรการเงินและประกันภัยและดูหมวดความรู้อื่นเพิ่มเติมที่ ศูนย์ความรู้ธุรกิจและ SEO

• สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) — pdpc.or.th
• ข้อตกลงการประมวลผลข้อมูลกับพันธมิตรโรงแรม/OTA ที่ใช้งานจริง
• ตารางกำหนดอายุการเก็บข้อมูลอัตลักษณ์แยกตามประเภทผลิตภัณฑ์ขององค์กร