บทนำ
กรณี “หมอพร้อม” และ TSD กำลังกลายเป็นอีกหนึ่งบททดสอบสำคัญของการบังคับใช้ PDPA ในไทย เพราะสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) ยังอยู่ระหว่างขอข้อมูลและหลักฐานเพิ่มเติมจากหน่วยงานที่เกี่ยวข้อง ไม่ได้จบเพียงการประกาศว่าเกิดเหตุข้อมูลผิดปกติแล้ว
สำหรับธุรกิจไทย สิ่งที่น่าสนใจกว่าตัวเลข 200,000 ราย คือคำถามว่า ถ้าวันหนึ่งบริษัทของเราเกิดเหตุแบบเดียวกัน เราจะพิสูจน์ได้หรือไม่ว่า “เรารับมืออย่างถูกต้องแล้ว”
“Data Breach ไม่ได้จบตอนปิดช่องโหว่ แต่เริ่มเข้าสู่บททดสอบจริงตอนองค์กรต้องพิสูจน์ว่า หลังรู้เหตุแล้วทำอะไรไปบ้าง”
สิ่งที่ PDPC กำลังตรวจ ไม่ได้มีแค่คำว่า “ข้อมูลรั่ว”
ในช่วงปลายเดือนกรกฎาคม 2569 PDPC เร่งติดตามสองกรณีที่เกี่ยวข้องกับข้อมูลส่วนบุคคลจำนวนมาก ได้แก่ ประเด็นข้อมูลในระบบที่เกี่ยวข้องกับ “หมอพร้อม” ซึ่งมีประชาชนร้องเรียนมากกว่า 30 ราย และเหตุการเข้าถึงข้อมูลในระบบ TSD Investor Portal โดยไม่ได้รับอนุญาต ซึ่ง TSD ระบุว่ากระทบผู้ใช้บริการประมาณ 200,000 ราย จากบัญชีในระบบประมาณ 5 ล้านบัญชี
สำหรับ TSD ข้อมูลที่อาจได้รับผลกระทบครอบคลุมข้อมูลหลายประเภท เช่น ชื่อ วันเดือนปีเกิด เลขประจำตัวประชาชน ที่อยู่ โทรศัพท์ อีเมล ข้อมูลบริษัทหลักทรัพย์ เลขบัญชีซื้อขายหลักทรัพย์ รวมถึงข้อมูลธนาคารบางส่วน อย่างไรก็ตาม มีการรายงานว่ายังไม่พบผลกระทบต่อข้อมูลการถือครองหลักทรัพย์ ข้อมูลธุรกรรมซื้อขาย หรือความเสียหายทางการเงินที่เชื่อมโยงกับเหตุการณ์ดังกล่าวในเวลานั้น
จุดสำคัญคือ PDPC ขอให้หน่วยงานที่เกี่ยวข้องชี้แจงมากกว่าการบอกว่า “เกิดเหตุแล้ว”
สิ่งที่ต้องตรวจสอบรวมถึงแหล่งที่มาของข้อมูล ประเภทและจำนวนข้อมูลที่ได้รับผลกระทบ การเข้าถึงหรือเปิดเผยโดยไม่ได้รับอนุญาต มาตรการรักษาความปลอดภัย การตรวจสอบช่องโหว่ บันทึกการเข้าถึง การจำกัดเหตุ การประเมินความเสี่ยง ตลอดจนการแจ้งเหตุและการแจ้งเจ้าของข้อมูลตามกฎหมาย
ส่วนกรณี TSD มีการระบุว่าตรวจพบความผิดปกติในช่วงเย็นวันที่ 25 กรกฎาคม และยืนยันในวันที่ 26 กรกฎาคม 2569 ว่ามีข้อมูลบางส่วนถูกเข้าถึง นี่ทำให้เห็นภาพหนึ่งอย่างชัดเจน:
“หลังเกิดเหตุ สิ่งที่มีค่าพอๆ กับการปิดช่องโหว่ คือ หลักฐานว่าองค์กรรู้เรื่องเมื่อไร และตัดสินใจอะไรหลังจากนั้น”
ผลกระทบต่อธุรกิจในประเทศไทย
สำหรับบริษัทไทย ประเด็นนี้ควรเปลี่ยนวิธีคิดเรื่อง Data Breach จาก “ฝ่าย IT แก้ระบบแล้วจบ” เป็น “องค์กรต้องสร้างหลักฐานการรับมือเหตุให้ครบตั้งแต่ต้นจนจบ”
ลองนึกภาพบริษัทอีคอมเมิร์ซแห่งหนึ่งตรวจพบว่ามีบัญชีผู้ใช้งานถูกเข้าถึงผิดปกติ เวลา 10.15 น. ฝ่าย IT ปิดช่องทางดังกล่าวเวลา 10.30 น. แต่ไม่มีใครบันทึกว่า 10.15 น. ใครเป็นคนพบเหตุ ไม่มีหลักฐานว่ามีข้อมูลประเภทใดถูกเข้าถึง ไม่มีการบันทึกว่าประเมินความเสี่ยงอย่างไร และไม่มีเอกสารว่าทำไมบริษัทจึงเลือกแจ้งหรือไม่แจ้งในช่วงเวลานั้น
ในมุมเทคโนโลยี บริษัทอาจพูดได้ว่า “เราปิดช่องโหว่แล้ว” แต่ในมุม Governance คำถามจะกลายเป็นว่า “แล้วคุณพิสูจน์ได้อย่างไรว่าองค์กรทำสิ่งที่ควรทำหลังเกิดเหตุแล้ว?” นี่คือจุดที่เรื่องนี้ มีผลกับธุรกิจไทยโดยตรง
องค์กรควรมี Incident Response Playbook ที่เชื่อม IT + DPO/Privacy + Legal + Management เข้าด้วยกัน ไม่ใช่ปล่อยให้แต่ละฝ่ายทำงานแยกกัน เพราะข้อมูลที่ฝ่าย IT มี เช่น Log และเวลาที่ตรวจพบเหตุ อาจกลายเป็นข้อมูลสำคัญสำหรับฝ่ายกฎหมายในการประเมินหน้าที่ตาม PDPA
ยิ่งข้อมูลมีความอ่อนไหว หรือ สามารถเชื่อมโยงกับตัวบุคคลได้มาก ความเสี่ยงก็ไม่ได้มีเพียงค่าปรับ หรือ ความรับผิดทางกฎหมาย แต่ยังรวมถึงความเสียหายต่อชื่อเสียง การสูญเสียความเชื่อมั่น การหลอกลวงต่อเนื่อง และต้นทุนในการเยียวยาลูกค้า
อีกเรื่องที่ธุรกิจไม่ควรมองข้ามคือ Vendor Risk เวลาที่เราจ้างบริษัทอื่นมาทำระบบ ซื้อซอฟต์แวร์ หรือ เช่าคลาวด์/AI มาใช้งาน เราไม่ได้แค่ซื้อบริการของเขามา แต่เรากำลัง “เอาความปลอดภัยของธุรกิจเราไปผูกไว้กับเขาด้วย
หากข้อมูลอยู่บนระบบของผู้ให้บริการภายนอก การตอบคำถามว่า “ใครเป็นคนทำข้อมูลรั่ว” อาจไม่สำคัญเท่ากับการตอบให้ได้ว่า องค์กรของเรามีวิธีควบคุม ตรวจสอบ และกำหนดหน้าที่ของผู้ให้บริการรายนั้นไว้อย่างไร
ดังนั้น Case นี้ไม่ควรถูกมองเป็นเพียงข่าวของหน่วยงานรัฐหรือบริษัทในตลาดทุน แต่ควรนำมาใช้เป็น Stress Test ของระบบรับมือ Data Breach ของทุกองค์กร
5 อย่าง ที่องค์กรควรตรวจวันนี้
1. สร้าง “Incident Timeline” ให้ได้ภายในไม่กี่ชั่วโมง
บันทึกตั้งแต่ตรวจพบความผิดปกติ ใครพบ เมื่อไร ใครได้รับแจ้ง ใครอนุมัติการตัดสินใจ และแต่ละขั้นตอนทำอะไรไปแล้ว
2. ตรวจว่า Log ตอบคำถามสำคัญได้หรือไม่
อย่างน้อยต้องตอบให้ได้ว่า ใคร / เข้าถึงอะไร / เมื่อไร / จากที่ไหน / ทำอะไรกับข้อมูล
3. แยก “การแก้ระบบ” ออกจาก “การประเมินหน้าที่ตาม PDPA”
การปิดช่องโหว่เป็นเรื่อง IT แต่การพิจารณาความเสี่ยง การแจ้งเหตุ การแจ้งเจ้าของข้อมูล และการเก็บหลักฐาน เป็นเรื่องที่ต้องประสานหลายฝ่าย
4. ตรวจสัญญากับ Vendor
ดูว่าเมื่อเกิดเหตุ ผู้ให้บริการต้องแจ้งองค์กรภายในกี่ชั่วโมง ต้องส่ง Log หรือหลักฐานอะไร และใครมีหน้าที่ประสานงานกับหน่วยงานกำกับ
5. ซ้อมเหตุจริง ไม่ใช่แค่ทบทวนนโยบาย
ให้จำลองเหตุว่า “ข้อมูลลูกค้า 200,000 รายถูกเข้าถึงตอนตี 2” แล้วดูว่าองค์กรสามารถหาคำตอบเรื่อง ใครรับผิดชอบ ใครตัดสินใจ และต้องทำอะไรต่อ ได้จริงหรือไม่
มุมมองผู้เชี่ยวชาญ
“ผมมองว่าเรื่องนี้ไม่ได้สอนแค่ว่าเราต้องป้องกันข้อมูลรั่ว แต่สอนว่า ถ้ารั่วขึ้นมาแล้ว เราต้องพิสูจน์ให้ได้ว่าเรารู้เร็วแค่ไหน ทำอะไรไปบ้าง และทำไมถึงตัดสินใจแบบนั้น เพราะฉะนั้น Incident Response วันนี้ไม่ใช่แค่เรื่องของฝ่าย IT แล้ว แต่มันเป็นเรื่องกฎหมายและ Governance ด้วย”
— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | เนติบัณฑิต & ทนายความ
พูดง่ายๆ คือ อย่ารอให้ข้อมูลรั่วแล้วค่อยสร้างระบบรับมือ เพราะตอนนั้นสิ่งที่หายไปอาจไม่ใช่แค่ข้อมูล แต่คือหลักฐานว่าองค์กรจัดการเหตุอย่างรับผิดชอบหรือไม่
แหล่งอ้างอิง
Thairath Money — รายงานกรณี PDPC ติดตามเหตุ “หมอพร้อม–TSD” และขอข้อมูล/หลักฐานเพิ่มเติมจากหน่วยงานที่เกี่ยวข้อง
อ่านข่าวต้นฉบับจาก Thairath Money
