แก้ปัญหา PDPA บนเว็บไซต์องค์กรการเงิน เมื่อพบช่องโหว่ระหว่างตรวจสอบภายใน

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

อาการ: Audit Trail ขาดช่วงหลังย้ายระบบหรืออัปเกรดเว็บไซต์

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

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

อาการ: ข้อมูล KYC ถูกส่งข้ามแผนกโดยไม่มีข้อตกลงรองรับ

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

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

อาการ: DPO ไม่ทราบว่ามีฟอร์มเก็บข้อมูลใหม่บนเว็บไซต์

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

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

อาการ: แต่ละแผนกใช้ระบบเก็บ Consent คนละชุดจนข้อมูลไม่ตรงกัน

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

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

อาการ: ข้อมูลที่ใช้จัดทำรายงานกำกับดูแลไม่ตรงกันระหว่างแผนก

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

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

อาการ: หน้าเว็บไซต์ใช้ Tracking Script ที่ไม่ตรงกับสิ่งที่ Privacy Notice ระบุไว้

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

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

วิธีป้องกันไม่ให้ปัญหาเหล่านี้เกิดซ้ำ

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

องค์กรที่ต้องการตรวจสอบว่าเว็บไซต์ปัจจุบันมีจุดเก็บข้อมูลใดที่ยังไม่ได้บันทึกไว้ในเอกสาร Compliance สามารถเริ่มจาก Website Trust Scan เพื่อสำรวจฟอร์มและ Script บนเว็บไซต์ทั้งหมด และควรอ่านคู่กับ ตัวอย่าง Template PDPA สำหรับเว็บไซต์องค์กรการเงิน เพื่อนำ Template ไปใช้ป้องกันปัญหาซ้ำ รวมถึงดูภาพรวมของหมวดนี้ที่ Privacy Fundamentals

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

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

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

• ลบระบบเดิมทิ้งทันทีหลังย้ายระบบโดยไม่ตรวจสอบว่าข้อมูลสำรองครบถ้วนหรือไม่
• ปล่อยให้ทีม Engineering เชื่อมต่อระบบระหว่างแผนกโดยไม่ผ่านการตรวจสอบจากฝ่ายกฎหมาย
• มีแบบฟอร์มขออนุมัติจาก DPO แต่ทีม Product ไม่ใช้งานจริงเพราะขั้นตอนช้าเกินไป
• ปล่อยให้แต่ละแผนกเก็บสถานะ Consent แยกกันโดยไม่มีระบบ Sync ข้อมูล
• ไม่กำหนดนิยามการนับข้อมูลร่วมกันก่อนจัดทำรายงานกำกับดูแล จนตัวเลขไม่ตรงกัน

สรุป

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

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

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