- หน้าแรก
- บทความ
- กฎหมาย PDPA และภาษี
- แจ้งเหตุข้อมูลรั่ว 72 ชั่วโมง: ร้านควรทำอะไรเมื่อข้อมูลลูกค้ารั่ว
แจ้งเหตุข้อมูลรั่ว 72 ชั่วโมง: ร้านควรทำอะไรเมื่อข้อมูลลูกค้ารั่ว
แจ้งเหตุข้อมูลรั่ว 72 ชั่วโมงตาม PDPA คืออะไร เมื่อโทรศัพท์หาย ไฟล์ลูกค้าหลุด หรือบัญชีพนักงานถูกเจาะ ร้านต้องหยุดความเสียหายและแจ้งใครบ้าง

สารบัญ 13
- อะไรนับเป็น "เหตุละเมิดข้อมูลส่วนบุคคล"
- หน้าที่ตามกฎหมายโดยสรุป
- แผนรับมือและแจ้งเหตุข้อมูลรั่ว 72 ชั่วโมง
- ชั่วโมงที่ 0–2: หยุดความเสียหาย
- ชั่วโมงที่ 2–24: ประเมินขอบเขต
- ชั่วโมงที่ 24–48: ตัดสินใจเรื่องการแจ้ง
- ชั่วโมงที่ 48–72: แจ้งและบันทึก
- หลังเหตุการณ์: ป้องกันไม่ให้เกิดซ้ำ
- ตัวอย่าง: ร้านเสริมสวยส่งไฟล์ผิดกลุ่ม
- บทบาทของผู้ให้บริการระบบ
- เช็กลิสต์เตรียมพร้อมล่วงหน้า
- สิ่งที่ไม่ควรทำเมื่อเกิดเหตุ
- สรุป
บทความนี้เป็นข้อมูลทั่วไป ไม่ใช่คำปรึกษาทางกฎหมาย เมื่อเกิดเหตุจริง ควรตรวจแนวปฏิบัติและช่องทางแจ้งเหตุล่าสุดที่ สคส. และปรึกษาผู้เชี่ยวชาญ
โทรศัพท์ร้านที่มีรายชื่อลูกค้าหายในร้านกาแฟ ไฟล์ Excel ประวัติลูกค้าถูกส่งผิดกลุ่ม LINE บัญชีพนักงานที่ลาออกไปแล้วยังเข้าระบบได้ เหตุการณ์แบบนี้เกิดได้กับทุกร้าน สิ่งสำคัญคือรู้ว่าต้องทำอะไรในชั่วโมงแรก ๆ และเข้าใจหน้าที่แจ้งเหตุข้อมูลรั่ว 72 ชั่วโมงตาม PDPA บทความนี้สรุปเป็นขั้นตอนที่ร้านเล็กทำได้จริง
อะไรนับเป็น "เหตุละเมิดข้อมูลส่วนบุคคล"
เหตุละเมิดไม่ได้หมายถึงแฮกเกอร์เท่านั้น แต่รวมถึงเหตุที่ทำให้ข้อมูลถูกเข้าถึง เปิดเผย เปลี่ยนแปลง หรือสูญหายโดยไม่ได้รับอนุญาต ตัวอย่างในร้านบริการ
- โทรศัพท์หรือแท็บเล็ตที่เปิดระบบหลังร้านค้างไว้หาย
- ส่งไฟล์รายชื่อลูกค้าผิดคน
- พนักงานถ่ายภาพหน้าจอข้อมูลลูกค้าไปใช้ส่วนตัว
- รหัสผ่านอีเมลร้านหลุด ทำให้คนอื่นเห็นอีเมลยืนยันการจอง
- สมุดนัดที่มีเบอร์โทรและอาการลูกค้าหาย
หน้าที่ตามกฎหมายโดยสรุป
| ผู้เกี่ยวข้อง | หน้าที่ |
|---|---|
| ร้าน (ผู้ควบคุมข้อมูล) | แจ้ง สคส. โดยไม่ชักช้าภายใน 72 ชั่วโมงนับแต่ทราบเหตุ เว้นแต่ไม่มีความเสี่ยงที่จะกระทบสิทธิเสรีภาพของบุคคล (PDPA มาตรา 37(4)) |
| ร้าน (กรณีความเสี่ยงสูง) | แจ้งเจ้าของข้อมูลพร้อมแนวทางเยียวยาโดยไม่ชักช้า |
| ผู้ให้บริการระบบ (ผู้ประมวลผล) | แจ้งร้านเมื่อเกิดเหตุละเมิด เพื่อให้ร้านดำเนินการต่อได้ |
ตัวบทกฎหมายดูได้จาก ราชกิจจานุเบกษา ส่วนแบบฟอร์มและช่องทางแจ้งเหตุให้ตรวจจากเว็บไซต์ สคส. ณ วันที่เกิดเหตุ
แผนรับมือและแจ้งเหตุข้อมูลรั่ว 72 ชั่วโมง
ชั่วโมงที่ 0–2: หยุดความเสียหาย
- ออกจากระบบทุกอุปกรณ์ที่สงสัย หรือยกเลิกสิทธิ์บัญชีที่เกี่ยวข้อง
- ถ้าเป็นโทรศัพท์หาย ใช้ฟังก์ชันล็อกหรือล้างเครื่องจากระยะไกล
- ถ้าส่งไฟล์ผิด ขอให้ผู้รับลบและยืนยันกลับ
- เปลี่ยนรหัสผ่านอีเมลร้านและบัญชีที่ใช้ร่วมกัน
ชั่วโมงที่ 2–24: ประเมินขอบเขต
ตอบคำถามให้ได้มากที่สุด
- ข้อมูลอะไรรั่ว ชื่อ เบอร์ LINE หรือข้อมูลสุขภาพด้วย
- ลูกค้าได้รับผลกระทบประมาณกี่คน
- ใครอาจเห็นข้อมูลนั้น
- ข้อมูลถูกเข้ารหัสหรือไม่
- เหตุเกิดเมื่อไร รู้เมื่อไร
ชั่วโมงที่ 24–48: ตัดสินใจเรื่องการแจ้ง
ประเมินความเสี่ยงต่อลูกค้า ตัวอย่างการพิจารณา
| สถานการณ์ | ระดับความเสี่ยงโดยทั่วไป |
|---|---|
| แท็บเล็ตหาย แต่ล็อกด้วยรหัสและข้อมูลอยู่บนระบบคลาวด์ที่ออกจากระบบแล้ว | ต่ำ |
| ไฟล์ชื่อและเบอร์ลูกค้า 500 คนถูกส่งเข้ากลุ่มสาธารณะ | สูง |
| ข้อมูลประวัติแพ้ยาหรือโรคประจำตัวรั่ว | สูงมาก |
ถ้ามีความเสี่ยง ให้เตรียมรายงานแจ้ง สคส. ถ้าความเสี่ยงสูง เตรียมข้อความแจ้งลูกค้าด้วย ภาษาที่ใช้ควรตรงไปตรงมา บอกว่าเกิดอะไร ข้อมูลใดได้รับผลกระทบ ร้านทำอะไรไปแล้ว และลูกค้าควรระวังอะไร เช่น ระวังข้อความหลอกลวงที่อ้างชื่อร้าน
ชั่วโมงที่ 48–72: แจ้งและบันทึก
- แจ้ง สคส. ตามช่องทางที่กำหนด ภายในกรอบเวลา
- แจ้งลูกค้าในกรณีความเสี่ยงสูง
- บันทึกเหตุการณ์ การประเมิน และสิ่งที่ทำ แม้จะตัดสินว่าไม่ต้องแจ้งก็ตาม
หลังเหตุการณ์: ป้องกันไม่ให้เกิดซ้ำ
- ทบทวนว่าใครเข้าถึงข้อมูลอะไรได้บ้าง ลดสิทธิ์ที่เกินจำเป็น
- เลิกใช้ไฟล์และแชทที่ไม่มีการควบคุมสำหรับข้อมูลลูกค้า
- ตั้งให้พนักงานใช้บัญชีของตัวเอง และปิดบัญชีทันทีเมื่อลาออก
- อบรมพนักงานสั้น ๆ ว่าอะไรคือเหตุละเมิดและต้องแจ้งใคร
ตัวอย่าง: ร้านเสริมสวยส่งไฟล์ผิดกลุ่ม
ตัวอย่าง พนักงานตั้งใจส่งรายชื่อลูกค้าที่นัดสัปดาห์หน้าให้ช่างในกลุ่มภายใน แต่ส่งผิดเข้ากลุ่มชุมชนที่มีสมาชิกกว่า 200 คน ไฟล์มีชื่อ เบอร์ และบริการที่จอง
- นาทีที่ 10 เจ้าของร้านเห็น ยกเลิกข้อความในกลุ่ม และขอให้แอดมินกลุ่มช่วยลบ
- ชั่วโมงที่ 3 ประเมินว่ามีลูกค้า 40 คน ข้อมูลไม่มีเรื่องสุขภาพ แต่เบอร์โทรถูกเปิดเผยต่อคนจำนวนมาก
- ชั่วโมงที่ 24 ตัดสินว่ามีความเสี่ยง เตรียมรายงานแจ้ง สคส. และส่งข้อความขอโทษพร้อมคำแนะนำให้ลูกค้าระวังข้อความแอบอ้าง
- หลังจากนั้น ร้านเลิกส่งรายชื่อเป็นไฟล์ ให้ช่างดูตารางของตัวเองผ่านระบบแทน
บทบาทของผู้ให้บริการระบบ
ถ้าข้อมูลลูกค้าเก็บในระบบจองของผู้ให้บริการ ผู้ให้บริการมีหน้าที่แจ้งร้านเมื่อเกิดเหตุฝั่งระบบ สำหรับ NadQ ข้อตกลงการประมวลผลข้อมูลกำหนดเป้าหมายแจ้งร้านภายใน 24 ชั่วโมงหลังทราบเหตุ พร้อมข้อมูลที่ร้านต้องใช้ในการแจ้ง สคส. เพื่อให้ร้านยังเหลือเวลาภายในกรอบ 72 ชั่วโมง ส่วนเหตุที่เกี่ยวกับข้อมูลที่ NadQ เป็นผู้ควบคุมเอง เช่น บัญชีเจ้าของร้าน NadQ เป็นผู้แจ้งเอง อ่านเรื่องบทบาทได้ใน ผู้ควบคุมข้อมูล vs ผู้ประมวลผล
มาตรการที่ช่วยลดโอกาสเกิดเหตุในระบบ NadQ ได้แก่ การแยกข้อมูลแต่ละร้านด้วยการควบคุมระดับฐานข้อมูล สิทธิ์ตามบทบาท การเข้ารหัสข้อมูลสุขภาพระดับฟิลด์ และการบันทึกการเข้าถึง ร้านยังควรดูแลฝั่งตัวเอง เช่น จัดการสิทธิ์พนักงานตามคู่มือ เชิญทีมงานและกำหนดสิทธิ์
เช็กลิสต์เตรียมพร้อมล่วงหน้า
- มีรายชื่อผู้ติดต่อฉุกเฉิน เจ้าของร้าน ผู้จัดการ และผู้ให้บริการระบบ
- รู้วิธีปิดสิทธิ์บัญชีพนักงานในไม่กี่นาที
- มีแบบฟอร์มบันทึกเหตุการณ์
- มีร่างข้อความแจ้งลูกค้าที่ปรับใช้ได้
- รู้ช่องทางแจ้ง สคส.
สิ่งที่ไม่ควรทำเมื่อเกิดเหตุ
อย่าลบหลักฐานเพื่อปกปิดเหตุการณ์ อย่าโทษพนักงานต่อหน้าลูกค้า และอย่ารอจนแน่ใจทุกรายละเอียดก่อนเริ่มประเมิน เพราะกรอบเวลา 72 ชั่วโมงเดินอยู่ตลอด ให้บันทึกสิ่งที่รู้ ณ ขณะนั้น แล้วอัปเดตเพิ่มเมื่อได้ข้อมูลใหม่
สรุป
หน้าที่แจ้งเหตุข้อมูลรั่ว 72 ชั่วโมงไม่ได้มีไว้ลงโทษร้าน แต่เพื่อให้ความเสียหายต่อลูกค้าน้อยที่สุด ร้านที่มีแผนรับมือ รู้ว่าข้อมูลอยู่ที่ไหน และใช้ระบบที่จำกัดสิทธิ์ได้ จะผ่านเหตุการณ์ได้เร็วและรักษาความเชื่อใจของลูกค้าไว้ได้
ลดความเสี่ยงตั้งแต่วันนี้ด้วยการย้ายข้อมูลลูกค้าจากไฟล์และแชทเข้าสู่ระบบที่ควบคุมสิทธิ์ได้
คำถามที่พบบ่อย
ทุกเหตุข้อมูลรั่วต้องแจ้ง สคส. หรือไม่
ไม่ทุกกรณี PDPA กำหนดให้แจ้งภายใน 72 ชั่วโมงนับแต่ทราบเหตุ เว้นแต่เหตุนั้นไม่มีความเสี่ยงที่จะกระทบสิทธิเสรีภาพของบุคคล แต่ร้านควรบันทึกทุกเหตุการณ์ไว้แม้ไม่ต้องแจ้ง
ถ้าเหตุเกิดที่ระบบของผู้ให้บริการ ใครต้องแจ้ง
ผู้ให้บริการในฐานะผู้ประมวลผลต้องแจ้งร้านโดยไม่ชักช้า และร้านในฐานะผู้ควบคุมข้อมูลเป็นผู้ประเมินและแจ้ง สคส. ตามกรอบเวลา


