ธุรกิจไทยส่วนใหญ่ที่นึกถึง PDPA มักนึกถึงหน้านโยบายความเป็นส่วนตัวกับช่องติ๊กขอความยินยอมบนฟอร์มสมัครสมาชิก สองสิ่งที่ทนายความช่วยเขียนไว้ครั้งเดียวแล้วเก็บเข้าแฟ้ม วันที่ 1 สิงหาคม 2568 คณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) ของไทยออกค่าปรับทางปกครอง 8 รายการใน 5 คดีแยกกัน รวมมูลค่าประมาณ 14.5 ล้านบาท เมื่ออ่านเหตุผลจริงเบื้องหลังแต่ละคดี ไม่มีคดีไหนเลยที่ถูกปรับเพราะไม่มีช่องติ๊ก
ค่าปรับมีตั้งแต่หน่วยงานรัฐที่จ่าย 153,120 บาท ไปจนถึงร้านค้าปลีกไอทีที่จ่าย 7 ล้านบาท ครอบคลุมห้าอุตสาหกรรมที่ต่างกันโดยสิ้นเชิง คือหน่วยงานรัฐ โรงพยาบาล ร้านค้าปลีกอุปกรณ์อิเล็กทรอนิกส์ บริษัทเครื่องสำอาง และบริษัทของเล่น ฟังดูเหมือนบทเรียนคือ "จัดเอกสารให้เรียบร้อย" แต่เมื่ออ่านทีละคดี รูปแบบจริงแคบกว่าและเจาะจงกว่านั้นมาก ทุกค่าปรับย้อนกลับไปที่สิ่งที่เกิดขึ้น หรือไม่เกิดขึ้น หลังจากข้อมูลรั่วไหลไปแล้ว ไม่ใช่เอกสารที่ทำไว้ก่อนหน้านั้น บทความนี้จะพาไปดูทั้ง 5 คดีทีละคดี สิ่งที่พวกมันมีร่วมกัน และความหมายจริงของช่องว่างนั้นต่อวิธีที่ธุรกิจไทยควรจัดการข้อมูลลูกค้าวันนี้
ไม่มีคดี PDPA ทั้ง 5 คดีในปี 2568 คดีไหนเลยที่ถูกปรับเพราะไม่มีช่องติ๊กขอความยินยอม ทุกคดีถูกปรับเพราะสิ่งที่เกิดขึ้น หรือไม่เกิดขึ้น ในวันหลังจากที่ข้อมูลรั่วไหลไปแล้ว
ห้าคดี อ่านไปด้วยกัน
ตาม Tilleke & Gibbins รอบการบังคับใช้กฎหมายของ PDPC วันที่ 1 สิงหาคม 2568 แบ่งได้ดังนี้
- หน่วยงานรัฐและผู้พัฒนาซอฟต์แวร์ของหน่วยงาน ถูกปรับรายละ 153,120 บาท หลังเกิดเหตุข้อมูลรั่วไหลกระทบผู้ถูกเก็บข้อมูล 200,000 ราย โดยระบุว่ารหัสผ่านอ่อนแอ ไม่มีการประเมินความเสี่ยง และไม่มีข้อตกลงประมวลผลข้อมูล (DPA) ระหว่างสองฝ่าย
- โรงพยาบาลเอกชนและผู้รับเหมา ถูกปรับ 1,210,000 บาท และ 16,940 บาท หลังเวชระเบียนรั่วไหลระหว่างการทำลายเอกสาร โดยระบุว่ามาตรการรักษาความปลอดภัยไม่เพียงพอ และไม่แจ้งเหตุข้อมูลรั่วไหล
- ร้านค้าปลีกคอมพิวเตอร์และอุปกรณ์อิเล็กทรอนิกส์ ถูกปรับ 7 ล้านบาท ค่าปรับก้อนใหญ่ที่สุดในรอบนี้ หลังข้อมูลที่รั่วไหลถูกนำไปใช้ในขบวนการหลอกลวงแบบคอลเซ็นเตอร์โดยตรง โดยระบุว่ามาตรการรักษาความปลอดภัยไม่เพียงพอ ไม่แจ้งเหตุข้อมูลรั่วไหล และไม่เคยแต่งตั้งเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO) เลย
- บริษัทเครื่องสำอาง ถูกปรับ 2.5 ล้านบาท หลังข้อมูลลูกค้ารั่วไหลไปถึงมิจฉาชีพ โดยระบุว่าไม่แจ้ง PDPC เรื่องข้อมูลรั่วไหล
- บริษัทของเล่นสะสมและผู้ประมวลผลข้อมูลของบริษัท ถูกปรับ 500,000 บาท และ 3 ล้านบาท หลังมีการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาตกระทบระเบียนราว 200,000 รายการ โดยระบุว่ามาตรการรักษาความปลอดภัยไม่เพียงพอ
ห้าอุตสาหกรรม ห้าธุรกิจขนาดต่างกันมาก แต่รูปร่างของเรื่องราวซ้ำกันตลอด
Response Infrastructure โครงสร้างตอบสนองเหตุละเมิดข้อมูล ที่แยกจากเอกสารขอความยินยอม
ขอเรียกมันว่า Response Infrastructure คือความสามารถเฉพาะเจาะจงที่ธุรกิจต้องมีในวินาทีที่ข้อมูลรั่วไหล ไม่ใช่ก่อนหน้านั้น ในทั้งห้าคดี ข้อกล่าวหาที่ระบุไม่ได้เกี่ยวกับว่าเก็บความยินยอมไว้ตั้งแต่แรกหรือเปล่า แต่เกี่ยวกับมาตรการรักษาความปลอดภัยที่ไม่มีอยู่จริง การแจ้งเหตุข้อมูลรั่วไหลที่ไม่ได้ยื่น และในกรณีร้านค้าปลีก คือเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคลที่ไม่เคยถูกแต่งตั้งเลย ธุรกิจหนึ่งอาจมีฟอร์มขอความยินยอมที่ถูกต้องตามหลักเทคนิค แต่ยังเสี่ยงอยู่ดีในทุกประเด็นเหล่านั้น เพราะ Response Infrastructure เป็นกล้ามเนื้อคนละมัดกับนโยบายความเป็นส่วนตัวโดยสิ้นเชิง
จำนวนค่าปรับเองก็บอกเล่าเรื่องราวบางส่วน คือ 153,120 บาทสำหรับคดีเล็กที่สุด และ 7 ล้านบาทสำหรับคดีใหญ่ที่สุด นั่นไม่ใช่การกระจายแบบสุ่ม แต่สะท้อนการประเมินข้อเท็จจริงเฉพาะของแต่ละคดี รวมถึงข้อมูลอะไรที่รั่วไหลและเกิดอะไรขึ้นหลังจากนั้น สิ่งที่คงที่ในทุกคดีไม่ว่าขนาดไหนก็ตาม คือช่องว่างประเภทเดียวกัน ไม่มีใครสร้างความเคยชินไว้ล่วงหน้าว่าต้องทำอะไรในชั่วโมงและวันหลังจากข้อมูลรั่วไหล เพราะไม่มีใครมอบหมายความรับผิดชอบนั้นให้ตำแหน่งใดตำแหน่งหนึ่งไว้ก่อนที่มันจะเกิดขึ้นจริง
ทำไม "เรามีช่องติ๊กขอความยินยอมแล้ว" ไม่เท่ากับ "พร้อมสำหรับ PDPA"
คดีบริษัทของเล่นควรค่าแก่การพิจารณาเป็นพิเศษ เพราะการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาตราว 200,000 รายการฟังดูเหมือนปัญหาของบริษัทใหญ่ จนกว่าจะสังเกตกลไกจริงๆ คือการเข้าถึงระบบระเบียนโดยไม่ได้รับอนุญาต ซึ่งเป็นโครงสร้างฐานข้อมูลจองหรือฐานข้อมูลลูกค้าแบบเดียวกับที่ธุรกิจบริการขนาดกลางใช้งานอยู่ทุกวัน ธุรกิจไม่จำเป็นต้องมีขนาดระดับองค์กรใหญ่ถึงจะถือข้อมูลประเภทเดียวกันที่มีความเสี่ยงประเภทเดียวกัน สิ่งที่ต้องมีคือระบบระเบียน ผู้ให้บริการภายนอกที่เข้าถึงระบบนั้นได้ และคำตอบที่ชัดเจนว่าใครรับผิดชอบสังเกตความผิดปกติที่นี่ สำหรับแนวทางที่ครบถ้วนกว่าว่าฐานข้อมูลลูกค้าที่พร้อมสำหรับ PDPA ต้องมีอะไรบ้าง อ่านคู่มือสร้างฐานข้อมูลลูกค้าที่พร้อมสำหรับ PDPAของเรา
ลองนึกภาพเชนร้านซ่อมมือถือสมมติสามสาขาชื่อ "วิทยา โมบาย รีแพร์" ที่เก็บชื่อ เบอร์โทร และหมายเลข IMEI ของเครื่องลูกค้าไว้ในแอปใบสั่งซ่อมที่ใช้ร่วมกันทั้งสามสาขา แอปมีประกาศความเป็นส่วนตัว และลูกค้าติ๊กช่องยินยอมก่อนฝากเครื่องซ่อม ถ้าวัดแค่แคบๆ แบบนั้น วิทยา โมบาย รีแพร์ ก็ดูเหมือนปฏิบัติตามกฎหมายแล้ว แต่ไม่มีใครในบริษัทถูกกำหนดให้เป็นจุดติดต่อถ้าผู้ให้บริการแอปนั้นแจ้งว่ามีข้อมูลรั่วไหล ไม่มีใครรู้ว่ามีนาฬิกา 72 ชั่วโมงที่เริ่มเดินทันทีที่พบการรั่วไหล และไม่มีใครตรวจสอบมานานกว่าหนึ่งปีแล้วว่าผู้ให้บริการยังเก็บรหัสผ่านตามที่เคยสัญญาไว้หรือเปล่า ช่องติ๊กที่ถูกติ๊กไว้ไม่เคยแก้ปัญหาเหล่านั้นเลยสักข้อ
ช่องว่างพื้นฐานแบบนี้เป็นแบบเดียวกับที่เราเคยเขียนถึงแยกไว้ต่างหาก คือธุรกิจที่ไม่เคยสร้างชั้นข้อมูลลูกค้าที่อ่านออกชุดเดียวไว้ตั้งแต่แรก มักตอบไม่ได้เหมือนกันว่า "ข้อมูลนี้อยู่ที่ไหนและใครรับผิดชอบ" ซึ่งเป็นคำถามเดียวกันเป๊ะที่เหตุการณ์ข้อมูลรั่วไหลบังคับให้ตอบภายในคืนเดียว
Playbook ของ Response Infrastructure
- Name a Data Protection Officer, Even a Part-Time One แต่งตั้ง DPO แม้จะทำงานไม่เต็มเวลา — ค่าปรับ 7 ล้านบาทของร้านค้าปลีกระบุชัดถึงการไม่มี DPO บุคคลที่ถูกกำหนดและรับผิดชอบชัดเจนคือจุดเริ่มต้นที่ทุกขั้นตอนถัดไปต้องพึ่งพา
- Know the 72-Hour Clock รู้จักนาฬิกา 72 ชั่วโมง — การไม่แจ้งเหตุข้อมูลรั่วไหลปรากฏในเกือบทุกคดีปี 2568 รู้ล่วงหน้าว่าใครเป็นคนคำนวณกรอบเวลานั้นและใครเป็นคนยื่นแจ้งเมื่อนาฬิกาเริ่มเดิน
- Security Measures Are Not a One-Time Setup มาตรการรักษาความปลอดภัยไม่ใช่การตั้งค่าครั้งเดียว — รหัสผ่านอ่อนแอและไม่มีการประเมินความเสี่ยงถูกระบุในคดีที่มีค่าปรับน้อยที่สุดของรอบนี้ พิสูจน์ว่านี่ไม่ใช่ความล้มเหลวเฉพาะระดับองค์กรใหญ่เท่านั้น
- Vendor Contracts Need a Data Processing Agreement สัญญาผู้ให้บริการต้องมีข้อตกลงประมวลผลข้อมูล — คดีหน่วยงานรัฐระบุชัดถึงการไม่มี DPA ระหว่างหน่วยงานกับผู้พัฒนา ผู้ให้บริการภายนอกที่แตะข้อมูลลูกค้าต้องมีเอกสารนี้เป็นลายลักษณ์อักษรก่อนความสัมพันธ์จะเริ่มต้น ไม่ใช่หลังเกิดเหตุแล้ว
บริษัทขนส่งเฟอร์นิเจอร์ที่เก็บที่อยู่ลูกค้าและข้อมูลการชำระเงินไว้ในสเปรดชีตที่แชร์กับพาร์ทเนอร์โลจิสติกส์ภายนอก ก็เจอความเสี่ยงแบบเดียวกับที่คดีบริษัทของเล่นเผยให้เห็น คือผู้ให้บริการภายนอกที่เข้าถึงระเบียนลูกค้าได้โดยไม่มีใครติดตาม และไม่มีข้อตกลงที่บันทึกไว้ว่าจะทำอย่างไรถ้าการเข้าถึงนั้นถูกนำไปใช้ในทางที่ผิด
Response สรุปสิ่งที่ทุกอย่างโยงมาที่จุดเดียว
ถ้าต้องเหลือคำเดียวที่แยกธุรกิจที่ถูกปรับในปี 2568 ออกจากธุรกิจที่ไม่ถูกปรับ คำนั้นคือ Response หรือ "การตอบสนอง" ไม่ใช่ขนาดของบริษัท ไม่ใช่ความยาวของนโยบายความเป็นส่วนตัว แค่ว่ามีใครสักคนตรวจจับเหตุข้อมูลรั่วไหลและลงมือทำถูกต้องได้ก่อนวันที่สามหรือเปล่า
คำถามที่ควรลองถามตัวเองคือ ถ้าธุรกิจของคุณพบพรุ่งนี้ว่าผู้ให้บริการที่เก็บข้อมูลลูกค้าของคุณถูกเจาะระบบ คุณรู้ไหมว่าใครเป็นคนคำนวณกำหนดเวลาแจ้งเหตุ และใครเป็นคนยื่นแจ้งจริงๆ ถ้าคำตอบตรงไปตรงมาต้องใช้เวลานิ่งคิดแล้วโทรถามว่าเป็นหน้าที่ใคร นั่นแหละคือช่องว่างเดียวกันเป๊ะที่สี่ในห้าคดีปี 2568 ถูกปรับ
คำถามที่พบบ่อย
ทั้งห้าบริษัทที่ถูกปรับเป็นองค์กรขนาดใหญ่ทั้งหมดหรือเปล่า
ไม่ใช่ คดีครอบคลุมหน่วยงานรัฐ โรงพยาบาล ร้านค้าปลีกไอที บริษัทเครื่องสำอาง และบริษัทของเล่น โดยค่าปรับมีตั้งแต่ 16,940 บาทไปจนถึง 7 ล้านบาท ขนาดบริษัทไม่ใช่ปัจจัยตัดสิน แต่สิ่งที่เกิดขึ้นหลังข้อมูลรั่วไหลต่างหากที่ตัดสิน
การมีนโยบายความเป็นส่วนตัวช่วยปกป้องธุรกิจจากค่าปรับแบบนี้ได้ไหม
ไม่เพียงพอในตัวมันเอง ไม่มีคดีไหนในห้าคดีปี 2568 ถูกกล่าวหาเรื่องไม่มีนโยบายความเป็นส่วนตัวหรือกลไกขอความยินยอม แต่ถูกกล่าวหาเรื่องมาตรการรักษาความปลอดภัยไม่เพียงพอ การแจ้งเหตุที่พลาดไป และในหนึ่งคดีคือไม่มีเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคลเลย
DPO คืออะไร และธุรกิจเล็กจำเป็นต้องมีจริงหรือเปล่า
เจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคลคือบุคคลที่ถูกกำหนดให้รับผิดชอบเรื่องการปฏิบัติตามกฎหมายคุ้มครองข้อมูลของธุรกิจ รวมถึงการตอบสนองเมื่อเกิดเหตุรั่วไหล ค่าปรับ 7 ล้านบาทของร้านค้าปลีกระบุชัดถึงการไม่มีตำแหน่งนี้ เป็นสัญญาณที่ชัดเจนว่า "ถ้าเกิดอะไรขึ้นค่อยหาทางแก้" ไม่ใช่จุดยืนที่ป้องกันได้เมื่อเกิดเหตุจริง
วิธีที่เร็วที่สุดในการเช็กว่าธุรกิจของเรามีช่องว่างนี้อยู่หรือเปล่าคืออะไร
ลองถามเป็นลายลักษณ์อักษรว่ามีใครในบริษัทระบุได้ไหมว่าใครจะเป็นคนแรกที่ได้รับแจ้งถ้าผู้ให้บริการฐานข้อมูลลูกค้ารายงานว่ามีข้อมูลรั่วไหลวันนี้ และคนนั้นรู้หรือเปล่าว่ามีนาฬิกาแจ้งเหตุ 72 ชั่วโมงอยู่ ถ้าไม่มีใครตอบได้อย่างมั่นใจ นั่นแหละคือช่องว่าง Response Infrastructure แบบเดียวกับที่รอบการบังคับใช้กฎหมายนี้ถูกสร้างขึ้นมาเพื่อจัดการ
หน้าตาแบบนี้เมื่อใช้ CRM จาก NAWA
ไม่มีฟีเจอร์ไหนของ CRM จาก NAWA ที่ทดแทนคำแนะนำทางกฎหมายได้ แต่การมีระเบียนลูกค้าชุดเดียวที่มองเห็นเจ้าของงานชัดเจน พร้อมไทม์ไลน์กิจกรรมที่ใช้ร่วมกัน ทำให้ง่ายขึ้นที่จะรู้ว่าข้อมูลลูกค้าอะไรมีอยู่บ้าง ใครเคยแตะต้องมันบ้าง และทีมของคุณจะตอบคำถามพื้นฐานเกี่ยวกับมันได้เร็วแค่ไหน ซึ่งเป็นความพร้อมประเภทเดียวกับที่แยกการตอบสนองที่รวดเร็วและป้องกันได้ ออกจากความเงียบที่ทำให้เหตุข้อมูลรั่วไหลกลายเป็นค่าปรับในคดีปี 2568 เหล่านี้
ถ้าคุณไม่มั่นใจว่าธุรกิจของคุณจะตอบได้ไหมวันนี้ว่า "ใครรับผิดชอบข้อมูลลูกค้าของเรา และมันอยู่ที่ไหนจริงๆ" คุยกับเราเรื่องการจัดระเบียบข้อมูลลูกค้าปัจจุบันของคุณ
แหล่งข้อมูล: Tilleke & Gibbins, "More Than a Warning: Eight Serious Fines Imposed in Thai Data Protection Cases"