ตลอดหลายปีที่ PDPA มีผลบังคับใช้ คำถามที่ถูกถามบ่อยที่สุดคือ "กฎหมายบังคับใช้จริงหรือเปล่า?" คำถามนั้นได้รับคำตอบอย่างชัดเจนในปี 2568 เมื่อสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) สั่งปรับทางปกครองรวม 21.5 ล้านบาท ในเคสบังคับใช้จริงครั้งแรกของประเทศไทย
บทความนี้วิเคราะห์สิ่งที่เกิดขึ้น เหตุผลที่ถูกลงโทษ และบทเรียนที่ทุกองค์กรต้องนำไปปรับใช้
เกิดอะไรขึ้น
เคสนี้เริ่มจากเหตุ Data Breach ที่ข้อมูลส่วนบุคคลของลูกค้าจำนวนมากรั่วไหลออกสู่ภายนอก ข้อมูลที่รั่วไหลรวมถึงชื่อ-นามสกุล หมายเลขโทรศัพท์ อีเมล และข้อมูลการทำธุรกรรม ข้อมูลเหล่านี้ถูกนำไปเผยแพร่และซื้อขายในตลาดมืดออนไลน์ ส่งผลให้เจ้าของข้อมูลจำนวนมากตกเป็นเป้าหมายของการหลอกลวงทางโทรศัพท์และข้อความ
ใครถูกปรับ
องค์กรที่ถูกดำเนินการเป็นบริษัทเอกชนขนาดใหญ่ที่ประมวลผลข้อมูลส่วนบุคคลของลูกค้าปริมาณมาก สคส. ดำเนินการตรวจสอบหลังได้รับเรื่องร้องเรียนจากเจ้าของข้อมูลหลายราย และพบการกระทำที่ฝ่าฝืน PDPA หลายประการ
เหตุใดจึงถูกปรับ — 5 ประเด็นหลัก
1. มาตรการรักษาความปลอดภัยไม่เพียงพอ
สคส. พบว่าองค์กรไม่มีมาตรการรักษาความปลอดภัยที่เหมาะสมตามมาตรา 37(1) ระบบที่จัดเก็บข้อมูลส่วนบุคคลมีช่องโหว่ด้านความปลอดภัยที่ควรตรวจพบและแก้ไขได้ก่อนหน้านี้ ไม่มีการเข้ารหัสข้อมูล (encryption) ที่เหมาะสม การควบคุมการเข้าถึง (access control) หละหลวม และไม่มีระบบตรวจจับการบุกรุก (intrusion detection) ที่มีประสิทธิภาพ
2. ไม่แจ้งเตือนเหตุละเมิดภายใน 72 ชั่วโมง
องค์กรทราบว่าเกิด Data Breach แล้ว แต่กลับไม่แจ้ง สคส. ภายใน 72 ชั่วโมง ความล่าช้านี้ส่งผลโดยตรงต่อเจ้าของข้อมูล ที่ไม่ได้รับโอกาสป้องกันตัวเองทันท่วงที ไม่ว่าจะเป็นการเปลี่ยนรหัสผ่านหรือการระวังมิจฉาชีพ
3. ไม่แจ้งเจ้าของข้อมูลที่ได้รับผลกระทบ
ประเด็นนี้เชื่อมโยงกับข้อก่อนหน้า เหตุละเมิดมีความเสี่ยงสูงต่อสิทธิและเสรีภาพของเจ้าของข้อมูล แต่องค์กรก็ยังไม่ได้แจ้งเตือนเจ้าของข้อมูลโดยไม่ชักช้าตามหน้าที่ในมาตรา 37(4)
4. RoPA และ Data Inventory ล้าสมัย
สคส. ขอตรวจสอบ RoPA แล้วพบว่าเอกสารไม่ตรงกับการประมวลผลที่เกิดขึ้นจริง Data Inventory ก็ไม่ชัดเจน ผลคือองค์กรไม่สามารถระบุขอบเขตของเหตุละเมิดได้อย่างรวดเร็ว
5. ไม่ตอบสนองคำขอใช้สิทธิ (DSR) ตามกำหนดเวลา
หลังจากเหตุ Data Breach ถูกเปิดเผย เจ้าของข้อมูลหลายรายยื่นคำขอใช้สิทธิเข้าถึงและลบข้อมูล แต่องค์กรไม่สามารถตอบสนองได้ภายใน 30 วัน เนื่องจากไม่มีกระบวนการ DSR ที่เป็นระบบ
โครงสร้างค่าปรับ 21.5 ล้านบาท
ค่าปรับทางปกครองรวม 21.5 ล้านบาท ประกอบด้วยหลายฐานความผิด แต่ละฐานมีค่าปรับไม่เกิน 5 ล้านบาทตามที่ PDPA กำหนด เมื่อรวมหลายฐานความผิดเข้าด้วยกัน จึงได้ยอดรวมที่สูงมาก
สิ่งที่ต้องเข้าใจคือ นี่เป็นเพียงค่าปรับทางปกครอง ยังไม่รวมถึง:
- ค่าเสียหายทางแพ่ง ที่เจ้าของข้อมูลอาจฟ้องร้องเรียกค่าเสียหาย (ไม่มีเพดาน)
- โทษอาญา กรณีผู้บริหารที่มีส่วนรู้เห็น อาจถูกจำคุกสูงสุด 1 ปี และ/หรือปรับสูงสุด 1 ล้านบาท
- ความเสียหายต่อชื่อเสียง ที่ประเมินค่าเป็นตัวเงินไม่ได้
สิ่งที่เปลี่ยนไปหลังเคสนี้
องค์กรตื่นตัวมากขึ้น
เคสนี้เป็นจุดเปลี่ยนสำคัญที่ทำให้องค์กรทั่วประเทศตระหนักว่า PDPA ไม่ใช่กฎหมายที่มีไว้เพื่อให้ดูสวยงามเท่านั้น แต่มีการบังคับใช้จริงพร้อมบทลงโทษที่เจ็บปวด งบประมาณด้าน Data Protection ของหลายองค์กรเพิ่มขึ้นอย่างมีนัยสำคัญหลังจากเคสนี้
สคส. แสดงจุดยืนชัดเจน
การบังคับใช้ครั้งนี้ส่งสัญญาณว่า สคส. พร้อมดำเนินการอย่างจริงจัง และจะไม่ยอมรับข้ออ้างว่า "ไม่รู้" หรือ "ทำไม่ทัน" คาดว่าจะมีการบังคับใช้ที่เข้มข้นขึ้นในอนาคต
มาตรฐานใหม่ในอุตสาหกรรม
เคสนี้กำหนดมาตรฐานใหม่ว่าอะไรคือ "มาตรการรักษาความปลอดภัยที่เหมาะสม" องค์กรไม่สามารถอ้างว่ามีไฟร์วอลล์กับแอนตี้ไวรัสก็เพียงพอแล้ว ต้องมีมาตรการเชิงลึกตามความเสี่ยงของข้อมูลที่ประมวลผล
วิธีหลีกเลี่ยง — 7 สิ่งที่ต้องทำตอนนี้
ตรวจสอบ Security ก่อนที่คนอื่นจะตรวจให้
ทำ Security Assessment เพื่อระบุช่องโหว่ก่อนที่ผู้ไม่หวังดีจะพบ ตรวจสอบ encryption, access control, logging, patch management และ vulnerability scanning ข้อนี้เป็นพื้นฐานที่สุดแต่เป็นจุดที่องค์กรในเคสนี้พลาด
แผน Incident Response — ซ้อมก่อน ไม่ใช่คิดตอนเกิดเรื่อง
ถ้ารอถึงวันที่เกิด Breach แล้วค่อยมาคิดว่าใครทำอะไร ก็สายเกินไปแล้ว ต้องมีแผนที่ระบุชัดเจนว่าใครทำอะไร เมื่อไหร่ อย่างไร และต้องซ้อมอย่างน้อยปีละ 2 ครั้ง
เทมเพลตแจ้งเตือน 72 ชั่วโมง เตรียมไว้ก่อนได้
เมื่อเกิดเหตุจริง เวลา 72 ชั่วโมงหมดเร็วกว่าที่คิด ถ้าต้องเริ่มร่างหนังสือแจ้ง สคส. ตั้งแต่ต้นก็แทบไม่ทัน มีเทมเพลตสำเร็จรูปสำหรับแจ้ง สคส. และแจ้งเจ้าของข้อมูลพร้อมใช้จะช่วยได้มาก
RoPA กับ Data Inventory ต้องอัปเดตจริง ไม่ใช่ทำครั้งเดียวแล้ววาง
หลายองค์กรจ้างที่ปรึกษามาทำ RoPA ตอนกฎหมายเพิ่งบังคับใช้ แล้วก็ไม่เคยแตะอีก พอ สคส. มาขอดูก็ไม่ตรงกับการประมวลผลจริง ทบทวนอย่างน้อยทุก 6 เดือน หรือทุกครั้งที่กระบวนการเปลี่ยน
กระบวนการ DSR ที่มีระบบจริง
เจ้าของข้อมูลมีสิทธิขอเข้าถึง แก้ไข หรือลบข้อมูลได้ตามกฎหมาย และองค์กรต้องตอบได้ภายใน 30 วัน ถ้าไม่มีช่องทางรับคำขอที่ชัดเจน ไม่มีระบบติดตามสถานะ ก็เสี่ยงที่จะพลาดกำหนดเวลาเหมือนในเคสนี้
อบรมพนักงาน — ทุกคนที่แตะข้อมูล ไม่ใช่แค่ IT
ความเข้าใจผิดที่พบบ่อยคือคิดว่า PDPA เป็นเรื่องของฝ่าย IT กับฝ่ายกฎหมาย แต่จริงๆ พนักงานทุกคนที่สัมผัสข้อมูลส่วนบุคคลต้องรู้ว่าอะไรทำได้ อะไรทำไม่ได้
เครื่องมือที่เหมาะสม ไม่ใช่ Excel
การทำ PDPA Compliance ด้วย Excel กับ Email ไม่เพียงพอสำหรับองค์กรที่ประมวลผลข้อมูลปริมาณมาก ต้องมีระบบที่จัดการได้อย่างเป็นระบบ มี Audit Trail ที่ตรวจสอบได้ และพิสูจน์ต่อ สคส. ได้ว่าทำจริง
บทเรียนที่แพงที่สุด คือบทเรียนที่ไม่ต้องเรียนเอง
ค่าปรับ 21.5 ล้านบาท เป็นราคาที่แพงมากสำหรับบทเรียนที่หลีกเลี่ยงได้ องค์กรที่ฉลาดจะเรียนรู้จากความผิดพลาดของผู้อื่น แทนที่จะรอให้ตัวเองเป็นเคสถัดไป
PrivacyHub เป็น Privacy Governance Platform ที่ช่วยให้องค์กรจัดการ PDPA Compliance ได้อย่างครบวงจร ด้วย 6 โมดูลที่ครอบคลุมทุกประเด็นที่ สคส. ตรวจสอบ ตั้งแต่ Consent Management, DSR Management, Data Inventory, RoPA, Breach Management ไปจนถึง Vendor Management โดยไม่เก็บข้อมูลส่วนบุคคลจริง (Zero PII Storage) เก็บเฉพาะ metadata และ audit trail เท่านั้น ช่วยลดความเสี่ยงในขณะที่เพิ่มความสามารถในการพิสูจน์ตัวตนต่อ สคส.
อย่าให้องค์กรของคุณเป็นเคสถัดไป เริ่มต้นวันนี้ที่ enersys.co.th/th/products/privacyhub
