IMY ปรับ Miljödata คือคำสั่งของหน่วยงานคุ้มครองข้อมูลสวีเดน (IMY) ที่ปรับ Miljödata ผู้ให้บริการไอทีรายหนึ่ง 1,800,000 โครน (ราว 160,000 ยูโร) ฐานรักษาความปลอดภัยการประมวลผลข้อมูลไม่เพียงพอ ตามที่ EDPB เผยแพร่เมื่อ 8 ตุลาคม 2569 บทความนี้เหมาะกับบริษัทที่ให้บริการระบบแก่องค์กรอื่นและบริษัทที่จ้างระบบจากภายนอก อ่านแล้วจะรู้ว่าสัญญาและระบบเฝ้าระวังควรมีอะไร
ลองนึกภาพบริษัทไทยที่จ้างผู้ให้บริการภายนอกเก็บข้อมูลลาป่วยและข้อมูลสุขภาพของพนักงานหลายร้อยคน วันหนึ่งผู้ให้บริการถูกเจาะและข้อมูลไปโผล่บนดาร์กเว็บ (ตัวอย่างสมมติ) คำถามคือใครต้องรับผิด คำสั่งของ IMY ตอบข้อนี้ในมุมสวีเดนว่า หน่วยงานปรับที่ผู้ให้บริการโดยตรง
สรุปสั้น: IMY ปรับ Miljödata 1,800,000 โครน ตามคำสั่งลงวันที่ 22 กันยายน 2569 ฐานละเมิดมาตรา 32(1) GDPR เรื่องความปลอดภัยในการประมวลผล โดยถือว่าประมาท หลังข้อมูลของผู้ได้รับผลกระทบ 2.2 ล้านคน (ตามที่บริษัทระบุ) รั่วเมื่อเดือนสิงหาคม 2568 ลูกค้าไม่ถูกปรับ บริษัทไทยควรเขียนสัญญา vendor ให้ตรวจสอบและแจ้งเหตุได้ และผู้ให้บริการควรมีระบบเฝ้าระวัง
IMY ปรับ Miljödata เพราะอะไร และเกิดอะไรขึ้น
IMY ปรับ Miljödata เพราะเห็นว่าบริษัทรักษาความปลอดภัยของการประมวลผลข้อมูลไม่เพียงพอ ซึ่งฝ่าฝืนมาตรา 32(1) ของ GDPR และถือว่าเป็นความประมาท หน่วยงานระบุข้อบกพร่อง 2 เรื่อง คือการตรวจสอบไม่เพียงพอเมื่อติดตั้งซอฟต์แวร์ใหม่ และไม่มีระบบเฝ้าระวังอัตโนมัติแบบเรียลไทม์
เหตุเกิดเมื่อเดือนสิงหาคม 2568 ผู้โจมตีเข้าถึงข้อมูลจำนวนมากแล้วเผยแพร่บนดาร์กเว็บ จำนวนผู้ได้รับผลกระทบ 2.2 ล้านคนเป็นตัวเลขตามที่บริษัทระบุ ข้อมูลที่รั่วมีเลขประจำตัว ข้อมูลลาป่วย ข้อมูลการฟื้นฟู และเหตุการณ์ที่เกี่ยวกับนักเรียน
| ประเด็น | ข้อเท็จจริงตามรายงาน |
|---|---|
| ผู้ถูกปรับ | Miljödata ผู้ให้บริการไอที (ไม่ใช่ลูกค้า) |
| ค่าปรับ | 1,800,000 โครน (ราว 160,000 ยูโร) |
| ฐานความผิด | GDPR มาตรา 32(1) ความปลอดภัยในการประมวลผล ถือว่าประมาท |
| วันที่ | คำสั่ง 22 ก.ย. 2569 · EDPB เผยแพร่ 8 ต.ค. 2569 |
| ผู้ได้รับผลกระทบ | 2.2 ล้านคน ตามที่บริษัทระบุ |
| ข้อบกพร่อง | ตรวจสอบไม่พอตอนติดตั้งซอฟต์แวร์ใหม่ · ไม่มีการเฝ้าระวังอัตโนมัติแบบเรียลไทม์ |
ลูกค้าของ Miljödata ส่วนใหญ่เป็นเทศบาล ภูมิภาค หน่วยงานรัฐ และภาคเอกชน ซึ่งไม่ถูกปรับในคำสั่งนี้ ข้อมูลทั้งหมดอ้างตามประกาศของ EDPB
IMY ปรับ Miljödata กระทบธุรกิจไทยอย่างไร
IMY ปรับ Miljödata กระทบธุรกิจไทยตรงที่แสดงว่าหน่วยงานกำกับดูแลมองผู้ให้บริการเป็นเป้าหมายโดยตรง ไม่ได้ปรับเฉพาะองค์กรที่เป็นเจ้าของข้อมูล ส่วนนี้เป็นการวิเคราะห์ของผู้เขียน ค่าปรับ 1,800,000 โครนถือว่าต่ำเมื่อเทียบกับผู้ได้รับผลกระทบ 2.2 ล้านคน แต่สัญญาณเรื่องตัวผู้ให้บริการสำคัญกว่าตัวเลข
ความประมาทหรือเจตนายังเป็นหัวใจของการกำหนดค่าปรับ ดูหลักการได้ใน EDPB ออกร่างแนวทางค่าปรับ GDPR 04/2026 ต้องมีเจตนาหรือประมาทก่อนปรับ รับฟังความเห็นถึง 13 พ.ย. องค์กรไทยที่เข้าเขต GDPR ต้องเตรียมหลักฐานอะไร
ผู้ให้บริการ SaaS และระบบบุคคลของไทยเสี่ยงอะไร
ผู้ให้บริการระบบบุคคล เงินเดือน หรือสวัสดิการที่ถือข้อมูลของหน่วยงานรัฐและเอกชนไทยเสี่ยงรูปแบบเดียวกับ Miljödata คือข้อมูลของคนจำนวนมากอยู่ในระบบเดียว การติดตั้งซอฟต์แวร์ใหม่ที่ตรวจไม่รัดกุมหรือไม่มีใครเฝ้าดูตลอดเวลาเป็นช่องที่ผู้โจมตีใช้ได้ PDPA วางหน้าที่รักษาความปลอดภัยไว้ทั้งกับผู้ควบคุมและผู้ประมวลผลข้อมูล ผู้ให้บริการจึงอ้างไม่ได้ว่าเป็นเรื่องของลูกค้าฝ่ายเดียว
กรณีติดตั้งและแพตช์ที่ไม่ได้ควบคุมดูเพิ่มได้ใน FBI ปลดผู้รับจ้างของ Accenture เพราะไม่ลงแพตช์ องค์กรไทยที่จ้างดูแลระบบ HR ต้องเขียน Patch SLA ลงสัญญาอย่างไร
ลูกค้าที่จ้างระบบจากภายนอกต้องมีสิทธิอะไรในสัญญา
ลูกค้าควรมีสิทธิตรวจสอบผู้ให้บริการ สิทธิรับแจ้งเหตุภายในเวลาที่กำหนด และสิทธิให้ผู้ให้บริการแสดงหลักฐานว่ามีระบบเฝ้าระวัง
สัญญาแบบนี้ควรเป็นข้อตกลงประมวลผลข้อมูลที่ชัดเจน ดูองค์ประกอบได้ที่ สัญญาประมวลผลข้อมูลส่วนบุคคล (ผู้ควบคุม–ผู้ประมวลผล) ต้องมีอะไรบ้าง
ถึงลูกค้าไม่ถูกปรับในคำสั่งของสวีเดน ลูกค้าก็ยังเสียหายด้านชื่อเสียงและต้องจัดการกับเจ้าของข้อมูล ข้อสังเกตเรื่องสัญญา DPA ในกรณีข้อมูลรั่วต่อเนื่องของญี่ปุ่นอยู่ใน ญี่ปุ่นข้อมูลรั่วต่อเนื่อง skyticket 14.6 ล้าน คาราโอเกะ 8.7 ล้าน Lawson 2.16 ล้าน รัฐเรียกประชุมฉุกเฉิน สัญญา DPA ของธุรกิจไทยต้องมีข้อไหน
ผู้ประมวลผลข้อมูลไทยถูกลงโทษเองได้หรือไม่
PDPA กำหนดหน้าที่ของผู้ประมวลผลข้อมูลไว้โดยตรง เช่น ต้องรักษาความปลอดภัยและแจ้งผู้ควบคุมข้อมูลเมื่อเกิดเหตุละเมิด ดังนั้นผู้ประมวลผลมีความเสี่ยงของตัวเองเช่นกัน ไม่ได้รับผิดผ่านลูกค้าเท่านั้น
ถ้าไม่ทำอะไรเลย ผู้ให้บริการและลูกค้าเสี่ยงอะไร
ถ้าไม่ทำอะไร ผู้ให้บริการเสี่ยงถูกตั้งคำถามจากหน่วยงานกำกับดูแลโดยตรงเมื่อระบบรั่ว ส่วนลูกค้าเสี่ยงอีกแบบ คือต้องรับมือเจ้าของข้อมูลและแจ้ง สคส. ภายใน 72 ชั่วโมงตามมาตรา 37(4) ของ PDPA โดยไม่มีข้อมูลจากผู้ให้บริการ เพราะสัญญาไม่ได้กำหนดเวลาแจ้งเหตุ
ผู้ให้บริการและลูกค้าควรทำอะไรตอนนี้
ผู้ให้บริการระบบและลูกค้าที่จ้างระบบจากภายนอกควรทำ 4 เรื่องนี้ก่อนเกิดเหตุจริง
- 1. เพิ่มสิทธิตรวจสอบ vendor และ SLA แจ้งเหตุในสัญญา กำหนดเวลาแจ้งเหตุให้เร็วพอที่ลูกค้าจะทัน 72 ชั่วโมง และสิทธิขอหลักฐานด้านความปลอดภัย
- 2. ตรวจระบบเฝ้าระวังของผู้ให้บริการ ขอดูว่ามีการเฝ้าระวังอัตโนมัติและการแจ้งเตือนผิดปกติหรือไม่ ไม่ใช่รับคำยืนยันปากเปล่า
- 3. ใช้ change control กับทุกการติดตั้งและแพตช์ ผู้ให้บริการควรทดสอบก่อนขึ้นระบบจริงและบันทึกว่าใครอนุมัติ
- 4. ทำทะเบียนผู้ประมวลผลและแผนแจ้งเหตุ ลูกค้าควรรู้ว่าข้อมูลส่วนบุคคลอยู่กับ vendor รายใดบ้าง และใครต้องแจ้ง สคส. เมื่อ vendor รายงานเหตุ
ถ้าต้องการคนช่วยทบทวนสัญญาและแผนแจ้งเหตุ ดูได้ที่ บริการ AI Governance และ PDPA ของ Kooru
มุมมองผู้เชี่ยวชาญ
ข้อสังเกตเชิงวิชาชีพของผมคือ หลายองค์กรคิดว่าส่งข้อมูลให้ vendor ดูแลแล้วความเสี่ยงก็ย้ายไปด้วย แต่คำสั่งของ IMY บอกว่าคนที่ถือข้อมูลต้องรับผิดชอบเรื่องความปลอดภัยของตัวเอง จ้างคนอื่นดูแลข้อมูล ย้ายงานได้ แต่ย้ายความรับผิดชอบทั้งหมดไม่ได้ จุดที่องค์กรมักพลาดคือไม่มีสิทธิตรวจสอบ vendor ในสัญญา และไม่มีใครรู้ว่าระบบนอกเฝ้าระวังอยู่หรือเปล่าจนกว่าจะเกิดเหตุ
— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | Thai Barrister & Attorney-at-Law
คำถามที่พบบ่อยเกี่ยวกับ IMY ปรับ Miljödata
IMY ปรับ Miljödata เท่าไร และใช้มาตราไหนของ GDPR
IMY ปรับ Miljödata 1,800,000 โครน (ราว 160,000 ยูโร) ฐานละเมิดมาตรา 32(1) ของ GDPR เรื่องความปลอดภัยในการประมวลผล โดยถือว่าประมาท คำสั่งลงวันที่ 22 กันยายน 2569 และ EDPB เผยแพร่เมื่อ 8 ตุลาคม 2569
ลูกค้าของ Miljödata ถูกปรับด้วยหรือไม่
ไม่ถูกปรับตามที่ EDPB รายงาน ลูกค้าส่วนใหญ่เป็นเทศบาล ภูมิภาค หน่วยงานรัฐ และภาคเอกชน คำสั่งนี้ปรับเฉพาะ Miljödata ในฐานะผู้ให้บริการ
บริษัทไทยที่จ้างระบบจากภายนอกควรเริ่มตรวจอะไร
เริ่มจากสัญญา ตรวจว่ามีสิทธิตรวจสอบ vendor เวลาแจ้งเหตุ และหน้าที่เฝ้าระวังหรือไม่ แล้วจึงทำทะเบียนว่าข้อมูลส่วนบุคคลอยู่กับ vendor รายใด ข้อตกลงประมวลผลข้อมูล (DPA) คือเอกสารที่ควรมีก่อนส่งข้อมูลให้ vendor
อ่านต่อ: ความรู้ที่เกี่ยวกับเรื่องนี้
- ทำสัญญาแล้วมีข้อมูลส่วนบุคคลเกี่ยวข้อง ต้องทำข้อตกลงประมวลผลข้อมูล (DPA) เมื่อไร — บอกว่าสัญญาแบบใดต้องมีข้อตกลงประมวลผลข้อมูล และดูได้จากว่าอีกฝ่ายใช้ข้อมูลตามคำสั่งของเราหรือไม่ (ok.aipdpa.com)
แหล่งอ้างอิง
- EDPB — (อ่านต้นฉบับ) — อ่านข่าวที่ EDPB
บทความนี้เป็นการสรุปข่าวและให้ข้อมูลทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย หากต้องการคำปรึกษาเฉพาะกรณีของธุรกิจคุณ ควรปรึกษาผู้เชี่ยวชาญ
