10 ข้อผิดพลาดเรื่อง PDPA บนเว็บไซต์ที่องค์กรการเงินและธุรกิจความเสี่ยงสูงควรเลี่ยง

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

ข้อผิดพลาดด้านการเก็บข้อมูล KYC บนหน้าเว็บไซต์

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

1. เก็บเอกสาร KYC ไว้ในระบบเดียวกับข้อมูลการตลาด

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

2. ไม่มีการกำหนดระยะเวลาลบเอกสาร KYC ที่ลูกค้ายกเลิกกลางคัน

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

3. อัปโหลดเอกสารผ่านช่องทางที่ไม่เข้ารหัสระหว่างส่ง

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

ข้อผิดพลาดด้าน Audit Trail และการพิสูจน์ Consent

สามข้อถัดไปเกี่ยวข้องกับการเก็บหลักฐานว่าเกิดอะไรขึ้นกับข้อมูลบนเว็บไซต์ ซึ่งเป็นสิ่งที่ทีม Compliance ต้องใช้เมื่อมีการตรวจสอบหรือข้อร้องเรียน

4. ไม่มี Audit Trail แยกจาก Log ของระบบทั่วไป

หลายองค์กรใช้ Application Log ทั่วไปเป็นหลักฐาน Consent ทั้งที่ Log เหล่านั้นถูกเขียนทับหรือหมุนเวียนทิ้ง (Log Rotation) ภายในเวลาสั้น ทำให้ไม่มีหลักฐานเหลือเมื่อต้องย้อนดูเหตุการณ์ที่เกิดขึ้นหลายเดือนก่อน เมื่อเกิดข้อร้องเรียนจากลูกค้าที่อ้างว่าไม่เคยยินยอมให้ติดต่อทางการตลาด ทีม Compliance จึงไม่มีหลักฐานใดยืนยันได้ทั้งสองฝ่าย

5. Consent Log ไม่ผูกกับเวอร์ชันของ Privacy Notice ที่ใช้ ณ ขณะนั้น

เมื่อ Privacy Notice มีการแก้ไขหลายครั้งต่อปีตามการเปิดผลิตภัณฑ์ใหม่ แต่ Consent Log ไม่ได้บันทึกว่าลูกค้าแต่ละรายยินยอมภายใต้ Notice เวอร์ชันใด ทำให้ตอบคำถามย้อนหลังไม่ได้ว่าลูกค้ารับทราบเงื่อนไขชุดใด

6. ไม่มีใครรับผิดชอบตรวจสอบ Audit Trail เป็นประจำ

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

ข้อผิดพลาดด้านโครงสร้างการกำกับดูแลของ DPO

สองข้อนี้เกี่ยวข้องกับการที่ DPO หรือทีม Privacy ไม่ถูกดึงเข้ามาเกี่ยวข้องตั้งแต่ขั้นตอนออกแบบ

7. แผนกธุรกิจเพิ่มฟอร์มเก็บข้อมูลใหม่บนเว็บไซต์โดยไม่แจ้ง DPO

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

8. DPO ไม่มีสิทธิ์เข้าถึงหรือระงับฟีเจอร์ที่มีความเสี่ยงสูงบนเว็บไซต์

ในบางองค์กร DPO มีหน้าที่ให้คำแนะนำเท่านั้น แต่ไม่มีกลไกให้สามารถระงับการเปิดใช้งานฟีเจอร์ที่ยังไม่ผ่านการตรวจสอบความเสี่ยงด้านข้อมูล ทำให้คำแนะนำมักมาถึงหลังจากฟีเจอร์เปิดใช้งานไปแล้ว

ข้อผิดพลาดด้านข้อตกลงระหว่างแผนกและการรายงานกำกับดูแล

สองข้อสุดท้ายเกี่ยวข้องกับการส่งต่อข้อมูลระหว่างหน่วยงานภายในองค์กรเดียวกัน ซึ่งมักถูกมองข้ามเพราะดูเหมือนเป็นการใช้ข้อมูลภายในเท่านั้น

9. ส่งข้อมูลลูกค้าข้ามแผนกโดยไม่มีข้อตกลงการประมวลผลข้อมูลภายใน

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

10. เตรียมข้อมูลสำหรับรายงานต่อหน่วยงานกำกับดูแลจากหลายระบบที่ไม่ตรงกัน

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

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

ทีมที่ต้องการตรวจสอบความพร้อมเบื้องต้นของหน้าเก็บข้อมูล KYC และ Consent บนเว็บไซต์สามารถเริ่มจาก Website Trust Scan เพื่อดู Finding เบื้องต้นก่อนนำไปทบทวนร่วมกับทีม Compliance และหากต้องวางแนวทางป้องกันปัญหาเหล่านี้อย่างเป็นระบบ ควรอ่านคู่กับ Best Practices ด้าน PDPA สำหรับเว็บไซต์องค์กรการเงิน และดูภาพรวมของหมวดนี้เพิ่มเติมได้ที่ Privacy Fundamentals

เช็กลิสต์ปฏิบัติ

• แยกระบบจัดเก็บเอกสาร KYC ออกจากระบบ CRM ของทีมการตลาด
• กำหนดระยะเวลาลบข้อมูลของผู้สมัครที่ยกเลิกกลางคัน
• ผูก Consent Log กับเวอร์ชันของ Privacy Notice ที่ใช้ ณ ขณะนั้นเสมอ
• มอบหมายทีมตรวจสอบความสมบูรณ์ของ Audit Trail เป็นประจำ
• กำหนดขั้นตอนแจ้ง DPO ก่อนเปิดฟีเจอร์ที่เก็บข้อมูลใหม่บนเว็บไซต์
• จัดทำข้อตกลงการประมวลผลข้อมูลภายในก่อนส่งข้อมูลข้ามแผนก

ข้อผิดพลาดที่พบบ่อย

• เก็บเอกสาร KYC ไว้ในระบบเดียวกับข้อมูลการตลาดโดยไม่แยกสิทธิ์การเข้าถึง
• ไม่มี Audit Trail แยกจาก Log ทั่วไปที่ถูกหมุนเวียนทิ้งเร็ว
• แผนกธุรกิจเปิดฟีเจอร์เก็บข้อมูลใหม่โดยไม่แจ้ง DPO ล่วงหน้า
• ส่งข้อมูลลูกค้าข้ามแผนกโดยไม่มีข้อตกลงการประมวลผลข้อมูลภายใน
• เตรียมข้อมูลรายงานกำกับดูแลจากหลายระบบที่ตัวเลขไม่ตรงกัน

สรุป

ข้อผิดพลาดด้าน PDPA บนเว็บไซต์องค์กรการเงินส่วนใหญ่ไม่ได้เกิดจากการไม่มี Privacy Policy แต่เกิดจากช่องว่างระหว่างแผนกที่ดูแลเว็บไซต์คนละส่วนโดยไม่มีจุดกลางที่ประสานงานกัน การแก้ไขที่ยั่งยืนต้องเริ่มจากการทบทวน Data Flow ระหว่างแผนก กำหนดบทบาท DPO ให้มีอำนาจจริง และสร้าง Audit Trail ที่ตรวจสอบย้อนหลังได้จริงเมื่อจำเป็น

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

• สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC)