Data Breach คืออะไร — ทำไมธุรกิจไทยต้องสนใจWhat Is a Personal Data Breach — Why Thai Businesses Must Care
ลองนึกภาพนี้: เช้าวันจันทร์ ทีม IT ของบริษัท A พบว่าฐานข้อมูลลูกค้ากว่า 50,000 รายถูกเข้าถึงจากภายนอกโดยไม่ได้รับอนุญาต ข้อมูลชื่อ ที่อยู่ เลขบัตรประชาชน และประวัติการสั่งซื้อถูกดาวน์โหลดออกไป นาฬิกาเริ่มเดิน — บริษัทมีเวลา 72 ชั่วโมงในการประเมินความเสี่ยงและแจ้งเหตุต่อสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) ทุกชั่วโมงที่ผ่านไปโดยไม่ดำเนินการ คือความเสี่ยงทางกฎหมายที่เพิ่มขึ้น
การละเมิดข้อมูลส่วนบุคคล (Personal Data Breach) ไม่ใช่แค่ปัญหาทาง IT อีกต่อไป แต่เป็นปัญหาทางกฎหมายและธุรกิจที่กรรมการบริษัท ผู้บริหาร และ DPO ต้องเข้าใจอย่างถ่องแท้ เพราะตั้งแต่พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) มีผลบังคับใช้เต็มรูปแบบ องค์กรที่ไม่มีกระบวนการประเมินความเสี่ยงและแจ้งเหตุที่ชัดเจน เท่ากับเปิดตัวเองให้ถูกโจมตีจากทั้งกฎหมายและชื่อเสียง
คู่มือแนวทางการประเมินความเสี่ยงและแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล เวอร์ชัน 1.0 ที่ สคส. ออกเมื่อวันที่ 15 ธันวาคม 2565 ได้วางกรอบปฏิบัติที่ชัดเจนว่าองค์กรต้องทำอะไรบ้างเมื่อเกิดเหตุ และบทความนี้จะสรุปสาระสำคัญทั้งหมดในรูปแบบที่นักกฎหมายธุรกิจและ C-Suite สามารถนำไปใช้ได้ทันที
"เมื่อข้อมูลรั่ว — สิ่งที่สำคัญที่สุดไม่ใช่ว่ารั่วอะไร แต่คือคุณตอบสนองเร็วแค่ไหนและถูกต้องแค่ไหน"
3 ประเภทของการละเมิดข้อมูลส่วนบุคคลThree Types of Personal Data Breach
ตามคู่มือแนวทางของ สคส. และสอดคล้องกับมาตรฐานสากล การละเมิดข้อมูลส่วนบุคคลแบ่งออกเป็น 3 ประเภทหลัก ซึ่งอาจเกิดขึ้นพร้อมกันในเหตุการณ์เดียวกันได้
1. Confidentiality Breach — การละเมิดด้านการรักษาความลับ
คือการเข้าถึงหรือเปิดเผยข้อมูลส่วนบุคคลโดยบุคคลที่ไม่มีอำนาจ หรือโดยวัตถุประสงค์ที่ไม่ได้รับอนุญาต เป็นประเภทที่พบบ่อยที่สุดและมักสร้างความเสียหายมากที่สุด
- แฮกเกอร์เจาะระบบและดาวน์โหลดฐานข้อมูลลูกค้า
- พนักงานส่งอีเมลที่มีข้อมูลลูกค้าไปผิดคน
- ผู้ประมวลผลข้อมูล (Data Processor) เข้าถึงข้อมูลเกินขอบเขตที่ตกลงไว้ใน DPA
- เอกสารที่มีข้อมูลส่วนบุคคลถูกทิ้งโดยไม่ทำลายอย่างเหมาะสม
2. Integrity Breach — การละเมิดด้านความถูกต้องครบถ้วน
คือการแก้ไข เปลี่ยนแปลง หรือทำลายข้อมูลส่วนบุคคลโดยไม่ได้รับอนุญาต ข้อมูลยังอยู่แต่ถูกเปลี่ยนเนื้อหา ซึ่งอาจส่งผลต่อการตัดสินใจที่ใช้ข้อมูลนั้นเป็นฐาน
- Ransomware เข้ารหัสข้อมูลแล้วเปลี่ยนแปลงเนื้อหาบางส่วนก่อนปลดล็อก
- พนักงานแก้ไขข้อมูลทางการแพทย์ของผู้ป่วยโดยไม่มีอำนาจ
- ระบบ Bug ทำให้ข้อมูลที่อยู่ของลูกค้ารายหนึ่งถูกเขียนทับด้วยข้อมูลของลูกค้ารายอื่น
3. Availability Breach — การละเมิดด้านความพร้อมใช้งาน
คือการสูญหายหรือไม่สามารถเข้าถึงข้อมูลส่วนบุคคลได้ ทั้งชั่วคราวและถาวร แม้ข้อมูลไม่ได้ถูกเปิดเผยต่อภายนอก แต่การที่องค์กรไม่สามารถเข้าถึงข้อมูลได้ก็ถือเป็นการละเมิดเช่นกัน
- ฮาร์ดดิสก์ที่เก็บข้อมูลเสียหายโดยไม่มี Backup
- Ransomware เข้ารหัสข้อมูลจนเข้าถึงไม่ได้ (แม้ไม่ได้ส่งออกนอกองค์กร)
- ไฟไหม้ Data Center ทำให้ข้อมูลสูญหายถาวร
- พนักงานลบข้อมูลโดยไม่ตั้งใจและไม่มีระบบกู้คืน
จุดสำคัญ: เหตุการณ์เดียว อาจเป็นหลายประเภท
ในทางปฏิบัติ เหตุการณ์หนึ่งมักเข้าข่ายหลายประเภทพร้อมกัน ตัวอย่างเช่น Ransomware Attack อาจเป็นทั้ง Confidentiality Breach (ถ้าแฮกเกอร์คัดลอกข้อมูลออกไปก่อนเข้ารหัส), Integrity Breach (ถ้ามีการแก้ไขข้อมูลบางส่วน) และ Availability Breach (ถ้าข้อมูลถูกเข้ารหัสจนเข้าถึงไม่ได้) การประเมินต้องพิจารณาทุกมิติ ไม่ใช่เลือกแค่ประเภทเดียว
| ประเภท | ลักษณะ | ตัวอย่างทั่วไป | ระดับความเสี่ยง |
|---|---|---|---|
| Confidentiality | เข้าถึง/เปิดเผยโดยไม่ได้รับอนุญาต | แฮก, อีเมลผิดคน, ขายข้อมูล | สูงมาก |
| Integrity | แก้ไข/เปลี่ยนแปลงโดยไม่ได้รับอนุญาต | Ransomware แก้ไขข้อมูล, Bug เขียนทับ | สูง |
| Availability | สูญหาย/เข้าถึงไม่ได้ | HDD เสีย, ไฟไหม้, ลบโดยไม่ตั้งใจ | กลาง-สูง |
กรอบกฎหมาย: มาตรา 37(4) และแนวทาง PDPCLegal Framework: Section 37(4) and PDPC Guidelines
หัวใจของหน้าที่แจ้งเหตุการละเมิดข้อมูลส่วนบุคคลอยู่ที่ พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 37(4) ซึ่งกำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคล (Data Controller) มีหน้าที่แจ้งเหตุการละเมิดข้อมูลส่วนบุคคลต่อ สคส. โดยไม่ชักช้า ภายใน 72 ชั่วโมงนับแต่ทราบเหตุ เว้นแต่การละเมิดนั้นไม่มีความเสี่ยงที่จะมีผลกระทบต่อสิทธิและเสรีภาพของบุคคล
"แจ้งเหตุการละเมิดข้อมูลส่วนบุคคลแก่สำนักงานโดยไม่ชักช้าภายในเจ็ดสิบสองชั่วโมงนับแต่ทราบเหตุเท่าที่จะสามารถกระทำได้ เว้นแต่การละเมิดดังกล่าวไม่มีความเสี่ยงที่จะมีผลกระทบต่อสิทธิและเสรีภาพของบุคคล ในกรณีที่การละเมิดมีความเสี่ยงสูงที่จะมีผลกระทบต่อสิทธิและเสรีภาพของบุคคล ให้แจ้งเหตุการละเมิดให้เจ้าของข้อมูลส่วนบุคคลทราบพร้อมกับแนวทางการเยียวยาโดยไม่ชักช้าด้วย"
มาตรานี้มีองค์ประกอบสำคัญ 3 ส่วนที่ผู้ควบคุมข้อมูลต้องเข้าใจ:
- หน้าที่แจ้ง สคส.: เป็นหน้าที่ทั่วไปที่ต้องแจ้งภายใน 72 ชั่วโมง ยกเว้นกรณีที่ไม่มีความเสี่ยง — แต่ภาระการพิสูจน์ว่า "ไม่มีความเสี่ยง" ตกอยู่กับผู้ควบคุมข้อมูล
- หน้าที่แจ้งเจ้าของข้อมูล: เป็นหน้าที่เพิ่มเติมที่เกิดขึ้นเมื่อการละเมิดมี "ความเสี่ยงสูง" ต่อสิทธิและเสรีภาพ — ต้องแจ้งพร้อมแนวทางเยียวยา
- ข้อยกเว้น: ไม่ต้องแจ้งเฉพาะกรณีที่พิสูจน์ได้ว่า "ไม่มีความเสี่ยง" — ซึ่งในทางปฏิบัติแทบเป็นไปไม่ได้สำหรับ Confidentiality Breach ที่มีข้อมูลอ่อนไหว
คู่มือแนวทาง PDPC เวอร์ชัน 1.0 (15 ธันวาคม 2565)
คู่มือนี้เป็นเอกสารอ้างอิงหลักที่ สคส. จัดทำขึ้นเพื่อช่วยให้ผู้ควบคุมข้อมูลเข้าใจและปฏิบัติตามมาตรา 37(4) ได้อย่างถูกต้อง สาระสำคัญของคู่มือครอบคลุม:
- นิยามและการจำแนกประเภทของการละเมิดข้อมูลส่วนบุคคล
- กระบวนการประเมินความเสี่ยง (Risk Assessment) อย่างเป็นระบบ
- เกณฑ์การตัดสินว่าต้องแจ้ง สคส. หรือไม่ และต้องแจ้งเจ้าของข้อมูลหรือไม่
- รูปแบบและเนื้อหาของการแจ้งเหตุ
- ตัวอย่างกรณีศึกษาพร้อมแนวทางตอบสนอง
ข้อควรระวัง: "ทราบเหตุ" กับ "เกิดเหตุ" ต่างกัน
กรอบเวลา 72 ชั่วโมงเริ่มนับจากเมื่อผู้ควบคุมข้อมูล "ทราบเหตุ" ไม่ใช่เมื่อเหตุการณ์เกิดขึ้นจริง แต่อย่าคิดว่าการไม่รู้คือข้อแก้ตัวที่ดี เพราะพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 37(1) กำหนดให้ผู้ควบคุมข้อมูลต้องจัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม ซึ่งรวมถึงระบบตรวจจับเหตุการณ์ (Detection) ที่มีประสิทธิภาพด้วย หากระบบตรวจจับไม่ดีจนทำให้รู้ช้า ก็อาจถือว่าไม่ปฏิบัติตามมาตรา 37(1) ได้อีกทาง
Risk Assessment Matrix — ประเมินความเสี่ยงอย่างเป็นระบบRisk Assessment Matrix — Systematic Risk Evaluation
การประเมินความเสี่ยงเป็นหัวใจสำคัญของกระบวนการตอบสนองต่อ Data Breach เพราะผลการประเมินจะตัดสินว่าองค์กรต้องดำเนินการใดบ้าง ตามแนวทาง PDPC การประเมินใช้ 2 มิติหลัก คือ ระดับความรุนแรง (Severity) และ ความน่าจะเป็น (Likelihood)
มิติที่ 1: ระดับความรุนแรง (Severity)
พิจารณาจากปัจจัยต่อไปนี้:
| ปัจจัย | ความรุนแรงต่ำ (1) | ความรุนแรงกลาง (2) | ความรุนแรงสูง (3) |
|---|---|---|---|
| ประเภทข้อมูล | ข้อมูลพื้นฐาน (ชื่อ, อีเมลธุรกิจ) | ข้อมูลส่วนตัว (ที่อยู่, เบอร์โทร, วันเกิด) | ข้อมูลอ่อนไหว (สุขภาพ, การเงิน, ชีวมิติ, ประวัติอาชญากรรม) |
| จำนวนเจ้าของข้อมูล | น้อยกว่า 100 ราย | 100-10,000 ราย | มากกว่า 10,000 ราย |
| ผลกระทบที่อาจเกิดขึ้น | ความไม่สะดวกเล็กน้อย | ความเสียหายทางทรัพย์สิน/ชื่อเสียง | อันตรายร้ายแรง (ฉ้อโกง, เลือกปฏิบัติ, คุกคาม) |
| กลุ่มเจ้าของข้อมูล | บุคคลทั่วไปที่ดูแลตัวเองได้ | ลูกจ้าง/ลูกค้าประจำ | เด็ก/ผู้เยาว์ ผู้ป่วย ผู้เปราะบาง |
มิติที่ 2: ความน่าจะเป็น (Likelihood)
พิจารณาจากปัจจัยต่อไปนี้:
| ปัจจัย | ต่ำ (1) | กลาง (2) | สูง (3) |
|---|---|---|---|
| ลักษณะการละเมิด | สูญหายในพื้นที่ควบคุม/ลบโดยไม่ตั้งใจ | ส่งผิดคนแต่ผู้รับน่าเชื่อถือ | แฮก/ขโมย/เผยแพร่สาธารณะ |
| การนำไปใช้จริง | ยังไม่มีหลักฐานว่านำไปใช้ | อาจนำไปใช้ได้แต่ต้องใช้ความพยายาม | มีหลักฐานว่านำไปใช้แล้ว/เผยแพร่ใน Dark Web |
| มาตรการป้องกันที่มี | ข้อมูลถูกเข้ารหัส (Encrypted) | มีการเข้ารหัสบางส่วน | ข้อมูลเป็น Plaintext ไม่มีการเข้ารหัส |
การคำนวณ Risk Score
สูตรประเมิน: Risk Score = Severity x Likelihood
| Risk Score | ระดับ | การดำเนินการ |
|---|---|---|
| 1-2 | ต่ำ (Low) | บันทึกเหตุการณ์ภายใน (Internal Record) — ไม่ต้องแจ้ง สคส. แต่ต้องมีเอกสารประกอบการตัดสินใจ |
| 3-4 | กลาง (Medium) | แจ้ง สคส. ภายใน 72 ชั่วโมง — ไม่ต้องแจ้งเจ้าของข้อมูลโดยตรง (เว้นแต่มีเหตุเฉพาะ) |
| 6-9 | สูง (High) | แจ้ง สคส. ภายใน 72 ชั่วโมง และ แจ้งเจ้าของข้อมูลส่วนบุคคลโดยไม่ชักช้า พร้อมแนวทางเยียวยา |
ข้อสังเกตสำคัญ: การตัดสินใจ "ไม่แจ้ง" มีความเสี่ยงสูงกว่าที่คิด
ในทางปฏิบัติ ผู้เชี่ยวชาญด้านกฎหมายข้อมูลส่วนบุคคลมักแนะนำให้ "เมื่อสงสัย ให้แจ้ง" (When in doubt, notify) เพราะการตัดสินใจไม่แจ้งแล้วภายหลังพบว่าควรแจ้ง มีผลร้ายแรงกว่าการแจ้งโดยไม่จำเป็น กรณีแรกอาจถูกลงโทษปรับทางปกครองและเสียชื่อเสียงซ้ำ กรณีหลังเพียงแค่สร้างภาระงานเอกสารเพิ่มเติม
72 ชั่วโมง — กรอบเวลาแจ้งเหตุที่ห้ามพลาด72-Hour Notification Timeline
กรอบเวลา 72 ชั่วโมงตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 37(4) เป็นกรอบที่แน่นมาก เมื่อเทียบกับมาตรฐานสากล (GDPR ของสหภาพยุโรปกำหนดไว้เท่ากันที่ 72 ชั่วโมง) เวลาจริงที่มีให้ทำงานจึงน้อยกว่าที่คิด เพราะต้องทำหลายอย่างพร้อมกัน
Timeline การตอบสนอง (Incident Response Timeline)
| ชั่วโมงที่ | การดำเนินการ | ผู้รับผิดชอบ |
|---|---|---|
| 0-4 | ตรวจจับ (Detection) + ยืนยันว่าเป็น Breach จริง + แจ้ง DPO + ผู้บริหาร + เริ่ม Containment | IT Security + DPO |
| 4-12 | สอบสวนเบื้องต้น: ระบุขอบเขต ประเภทข้อมูล จำนวนเจ้าของข้อมูล สาเหตุ | IT + Legal + DPO |
| 12-24 | ทำ Risk Assessment ตาม Matrix + ตัดสินใจว่าต้องแจ้ง สคส. หรือไม่ + เตรียมรายงาน | DPO + Legal |
| 24-48 | ร่างรายงานแจ้งเหตุ + ตรวจสอบความถูกต้อง + อนุมัติโดยผู้บริหาร | DPO + Management |
| 48-72 | ส่งรายงานแจ้ง สคส. + แจ้งเจ้าของข้อมูล (ถ้า High Risk) + เริ่ม Remediation | DPO + Communications |
| หลัง 72 | ส่งรายงานเพิ่มเติม (ถ้าข้อมูลยังไม่ครบ) + Post-Incident Review + ปรับปรุงมาตรการ | DPO + All Teams |
มาตรา 37(4) กำหนดให้แจ้งเหตุ "โดยไม่ชักช้าภายในเจ็ดสิบสองชั่วโมง" หน้าที่จัดทำ บันทึกเหตุผลของความล่าช้า ในกรณีที่ไม่อาจแจ้งได้ภายในกำหนดเวลามาจาก ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2565 และคู่มือแนวทาง PDPC เวอร์ชัน 1.0 — ซึ่งหมายความว่ากรอบกฎหมายยอมรับว่าบางกรณีอาจแจ้งไม่ทัน แต่ต้องมีเอกสารอธิบายเหตุผลที่ชัดเจน
เนื้อหาที่ต้องมีในรายงานแจ้งเหตุ
ตามคู่มือแนวทาง PDPC รายงานแจ้งเหตุต่อ สคส. ต้องมีเนื้อหาอย่างน้อยดังต่อไปนี้:
- ลักษณะของเหตุการณ์: เกิดอะไร เมื่อไหร่ ทราบเมื่อไหร่ ประเภทการละเมิด
- ข้อมูลที่ได้รับผลกระทบ: ประเภทข้อมูล จำนวนรายการ จำนวนเจ้าของข้อมูลที่ได้รับผลกระทบ
- ผลกระทบที่อาจเกิดขึ้น: ผลกระทบต่อสิทธิและเสรีภาพของเจ้าของข้อมูล
- มาตรการที่ดำเนินการแล้ว: Containment, การแก้ไข, การลดผลกระทบ
- มาตรการที่จะดำเนินการต่อไป: การเยียวยา การป้องกันการเกิดซ้ำ
- ข้อมูล DPO: ชื่อ ช่องทางติดต่อ DPO หรือผู้ประสานงาน
10 ตัวอย่างกรณีจริง — ประเภทและการตอบสนอง10 Real-World Scenarios — Classification and Response
ตัวอย่างต่อไปนี้จัดทำขึ้นโดยอิงจากรูปแบบเหตุการณ์ที่พบบ่อยในทางปฏิบัติและแนวทางของ PDPC เพื่อช่วยให้ DPO และทีมกฎหมายเข้าใจวิธีจำแนกประเภทและตอบสนองได้อย่างรวดเร็ว ชื่อองค์กรเป็นสมมติทั้งหมด
🔴 กรณีที่ 1: Ransomware Attack — โรงพยาบาล HIGH RISK
เหตุการณ์: ระบบเวชระเบียนของโรงพยาบาล A ถูก Ransomware เข้ารหัส ข้อมูลผู้ป่วย 30,000 รายเข้าถึงไม่ได้ และแฮกเกอร์อ้างว่าได้คัดลอกข้อมูลออกไปแล้ว
ประเภท: Confidentiality + Availability Breach
Risk Score: Severity 3 (ข้อมูลสุขภาพ + กลุ่มเปราะบาง) x Likelihood 3 (มีหลักฐานว่าข้อมูลถูกส่งออก) = 9 — สูงมาก
การดำเนินการ: แจ้ง สคส. ภายใน 72 ชม. + แจ้งเจ้าของข้อมูลทุกราย + แนะนำให้เปลี่ยนรหัสผ่าน + ตรวจสอบธุรกรรมการเงิน
🟡 กรณีที่ 2: อีเมลผิดคน — บริษัทที่ปรึกษา MEDIUM RISK
เหตุการณ์: พนักงานบริษัท B ส่งไฟล์สเปรดชีตที่มีข้อมูลเงินเดือนพนักงาน 200 คนไปยังอีเมลของบุคคลภายนอกโดยไม่ตั้งใจ ผู้รับยืนยันว่าลบไฟล์แล้วแต่ไม่สามารถตรวจสอบได้
ประเภท: Confidentiality Breach
Risk Score: Severity 2 (ข้อมูลการเงิน/เงินเดือน) x Likelihood 2 (ผู้รับอ้างว่าลบแต่ไม่ verify ได้) = 4 — กลาง
การดำเนินการ: แจ้ง สคส. ภายใน 72 ชม. + พิจารณาแจ้งพนักงานที่ได้รับผลกระทบ + ทบทวนมาตรการป้องกันการส่งอีเมลผิด
🟢 กรณีที่ 3: Laptop สูญหาย — พนักงานขาย LOW RISK
เหตุการณ์: Laptop ของพนักงานขายบริษัท C สูญหายระหว่างเดินทาง มีฐานข้อมูลลูกค้า 500 ราย แต่ฮาร์ดดิสก์ถูกเข้ารหัส Full Disk Encryption (BitLocker) และมีรหัสผ่านที่แข็งแรง
ประเภท: Confidentiality + Availability Breach (แม้จะมี Backup บน Cloud)
Risk Score: Severity 2 (ข้อมูลลูกค้า 500 ราย) x Likelihood 1 (ข้อมูลถูกเข้ารหัส เข้าถึงไม่ได้จริง) = 2 — ต่ำ
การดำเนินการ: บันทึกภายใน + Remote Wipe + ไม่ต้องแจ้ง สคส. (เพราะข้อมูลถูกเข้ารหัส ความเสี่ยงต่ำ) แต่ต้องมีเอกสารประกอบการตัดสินใจ
🔴 กรณีที่ 4: Database Misconfiguration — E-Commerce HIGH RISK
เหตุการณ์: เว็บไซต์ E-Commerce ของบริษัท D ปล่อยฐานข้อมูลลูกค้า 100,000 รายเปิดเข้าถึงได้โดยไม่ต้องเข้าสู่ระบบ นานกว่า 2 สัปดาห์ก่อนถูกตรวจพบ มีข้อมูลชื่อ อีเมล เบอร์โทร ที่อยู่จัดส่ง และประวัติการสั่งซื้อ
ประเภท: Confidentiality Breach
Risk Score: Severity 2 (ข้อมูลส่วนตัว + มากกว่า 10,000 ราย ปรับเป็น 3) x Likelihood 3 (เปิดเข้าถึงได้ 2 สัปดาห์ + ไม่ทราบว่ามีใครเข้าถึงหรือไม่) = 9 — สูง
การดำเนินการ: แจ้ง สคส. + แจ้งเจ้าของข้อมูลทุกราย + ว่าจ้าง Forensic Audit + ปิดช่องโหว่ทันที
🔴 กรณีที่ 5: พนักงานลาออกนำข้อมูลไป — บริษัทอสังหาริมทรัพย์ HIGH RISK
เหตุการณ์: พนักงานขายบริษัท E ลาออกและคัดลอกฐานข้อมูลลูกค้า 3,000 รายไปใช้กับบริษัทคู่แข่ง ตรวจพบจาก USB Log
ประเภท: Confidentiality Breach
Risk Score: Severity 2 x Likelihood 3 (มีหลักฐานว่านำไปใช้) = 6 — สูง
การดำเนินการ: แจ้ง สคส. + พิจารณาแจ้งเจ้าของข้อมูล + ดำเนินคดีกับพนักงาน (ทั้งทางแพ่งและอาญา)
🟢 กรณีที่ 6: ระบบ Cloud Backup ล่ม — Availability Breach LOW RISK
เหตุการณ์: Cloud Provider ของบริษัท F ระบบล่ม 48 ชั่วโมง ทำให้ข้อมูลลูกค้า 5,000 รายเข้าถึงไม่ได้ชั่วคราว ข้อมูลไม่ได้ถูกเข้าถึงจากภายนอก
Risk Score: Severity 1 x Likelihood 1 = 1 — ต่ำ (เว้นแต่ข้อมูลเป็นข้อมูลสุขภาพที่ต้องใช้เร่งด่วน)
การดำเนินการ: บันทึกภายใน + ทบทวน SLA กับ Cloud Provider + พิจารณา Multi-Cloud Strategy
🔴 กรณีที่ 7: Phishing Attack สำเร็จ — ธนาคาร HIGH RISK
เหตุการณ์: พนักงานธนาคาร G ถูก Phishing ทำให้ Credential ถูกขโมย แฮกเกอร์เข้าถึงข้อมูลบัญชีลูกค้า 800 ราย รวมเลขบัญชีและยอดเงินคงเหลือ
Risk Score: Severity 3 (ข้อมูลการเงิน) x Likelihood 3 = 9 — สูงมาก
การดำเนินการ: แจ้ง สคส. + แจ้ง ธปท. (ผู้กำกับดูแลเพิ่มเติม) + แจ้งลูกค้าทุกราย + Reset Credential + ตรวจสอบธุรกรรมย้อนหลัง
🔴 กรณีที่ 8: เอกสารกระดาษสูญหาย — คลินิก HIGH RISK
เหตุการณ์: แฟ้มเอกสารประวัติผู้ป่วย 50 รายของคลินิก H สูญหายระหว่างขนย้ายสำนักงาน
Risk Score: Severity 3 (ข้อมูลสุขภาพ) x Likelihood 2 (สูญหาย ไม่รู้ว่าใครพบ) = 6 — สูง
การดำเนินการ: แจ้ง สคส. + แจ้งผู้ป่วยที่เกี่ยวข้อง + ค้นหาเอกสาร + ทบทวนกระบวนการจัดเก็บเอกสาร
🔴 กรณีที่ 9: Data Processor ละเมิด DPA — บริษัท Outsource HIGH RISK
เหตุการณ์: บริษัท Outsource (Processor) ที่รับประมวลผลข้อมูลให้บริษัท I ถูกพบว่านำข้อมูลลูกค้าไปใช้เพื่อวัตถุประสงค์อื่นที่ไม่ได้ตกลงไว้ใน Data Processing Agreement (DPA)
Risk Score: Severity 2 x Likelihood 3 = 6 — สูง
การดำเนินการ: ผู้ควบคุมข้อมูล (บริษัท I) ต้องแจ้ง สคส. + แจ้งเจ้าของข้อมูล + ยุติ DPA + เรียกร้องค่าเสียหายจาก Processor + ทบทวนการตรวจสอบ Processor ทั้งหมด
🔴 กรณีที่ 10: Website Defacement + Data Scraping — มหาวิทยาลัย HIGH RISK
เหตุการณ์: เว็บไซต์ของมหาวิทยาลัย J ถูก Hack และข้อมูลนักศึกษา 20,000 ราย (ชื่อ รหัสนักศึกษา เกรด) ถูกเผยแพร่ใน Dark Web
Risk Score: Severity 2 (ข้อมูลการศึกษา + มากกว่า 10,000 ราย) x Likelihood 3 (เผยแพร่ใน Dark Web แล้ว) = 6 — สูง
การดำเนินการ: แจ้ง สคส. + แจ้งนักศึกษาทุกราย + ประสานตำรวจไซเบอร์ + Forensic + ปิดช่องโหว่
DPO Checklist — รายการตรวจสอบเมื่อเกิด BreachDPO Checklist — Breach Response Action Items
เมื่อเกิดเหตุการละเมิดข้อมูลส่วนบุคคล DPO (เจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล) ต้องดำเนินการตามรายการต่อไปนี้โดยเร่งด่วน
Phase 1: ภายใน 4 ชั่วโมงแรก (Detection & Containment)
- ☐ ยืนยันว่าเกิด Data Breach จริง (ไม่ใช่ False Alarm)
- ☐ เปิดใช้ Incident Response Plan (IRP) ทันที
- ☐ แจ้งทีม IT Security ให้ดำเนินการ Containment (หยุดการรั่วไหล)
- ☐ แจ้งผู้บริหาร (CEO/CFO/COO) ตามลำดับชั้นที่กำหนด
- ☐ เริ่มบันทึก Breach Register ทันที (เวลา วันที่ รายละเอียดเบื้องต้น)
- ☐ ตรวจสอบว่า Breach ยังดำเนินอยู่หรือหยุดแล้ว
Phase 2: ชั่วโมงที่ 4-24 (Investigation & Assessment)
- ☐ ระบุประเภทข้อมูลที่ได้รับผลกระทบ
- ☐ ประมาณจำนวนเจ้าของข้อมูลที่ได้รับผลกระทบ
- ☐ จำแนกประเภทการละเมิด (Confidentiality / Integrity / Availability)
- ☐ ดำเนินการ Risk Assessment ตาม Matrix (Severity x Likelihood)
- ☐ ตัดสินใจว่าต้องแจ้ง สคส. หรือไม่ — พร้อมบันทึกเหตุผล
- ☐ ตัดสินใจว่าต้องแจ้งเจ้าของข้อมูลหรือไม่ (ถ้า High Risk)
- ☐ ตรวจสอบว่ามีหน้าที่แจ้งหน่วยงานกำกับดูแลอื่นเพิ่มเติมหรือไม่ (เช่น ธปท., กลต., สำนักงาน กสทช.)
Phase 3: ชั่วโมงที่ 24-72 (Notification & Remediation)
- ☐ ร่างรายงานแจ้งเหตุต่อ สคส. (ตามรูปแบบที่กำหนด)
- ☐ ตรวจสอบความถูกต้องของรายงานโดยทีมกฎหมาย
- ☐ ผู้บริหารอนุมัติรายงาน
- ☐ ส่งรายงานแจ้ง สคส. ผ่านช่องทางที่กำหนด
- ☐ ร่างหนังสือแจ้งเจ้าของข้อมูล (ถ้าจำเป็น) พร้อมแนวทางเยียวยา
- ☐ เริ่มมาตรการเยียวยา (เปลี่ยนรหัสผ่าน, Credit Monitoring, Hotline)
Phase 4: หลัง 72 ชั่วโมง (Post-Incident)
- ☐ ส่งรายงานเพิ่มเติมต่อ สคส. (ถ้าข้อมูลในรายงานแรกยังไม่ครบ)
- ☐ จัดทำ Post-Incident Review (Lessons Learned)
- ☐ ปรับปรุง Incident Response Plan ตามบทเรียนที่ได้
- ☐ ทบทวนมาตรการรักษาความมั่นคงปลอดภัยทั้งหมด
- ☐ อัปเดต Data Protection Impact Assessment (DPIA) ถ้าจำเป็น
- ☐ จัดฝึกอบรมพนักงานเพิ่มเติม (ถ้าสาเหตุมาจากความผิดพลาดของคน)
- ☐ บันทึก Breach Register ให้ครบถ้วน (สำหรับ Audit Trail)
ข้อควรระวัง: Breach Register เป็นหน้าที่ตามกฎหมายและแนวทาง สคส.
พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 39 กำหนดให้ผู้ควบคุมข้อมูลต้องบันทึกรายการกิจกรรมการประมวลผลข้อมูล (Records of Processing Activities — ROPA) ซึ่งเป็นบันทึกทั่วไปของกิจกรรมประมวลผลทั้งหมด ส่วนหน้าที่จัดทำ Breach Register โดยเฉพาะ (บันทึกเหตุการณ์ Data Breach ทุกครั้ง) มาจาก ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2565 และคู่มือแนวทางของ สคส. แม้จะเป็นเหตุการณ์ที่ประเมินว่า "ความเสี่ยงต่ำ" ไม่ต้องแจ้ง สคส. ก็ต้องบันทึกใน Breach Register เพราะ สคส. อาจขอตรวจสอบได้ทุกเมื่อ
บทลงโทษและผลกระทบทางกฎหมายPenalties and Legal Consequences
การไม่ปฏิบัติตามหน้าที่แจ้งเหตุการละเมิดข้อมูลส่วนบุคคลมีผลทางกฎหมายหลายมิติ ทั้งทางปกครอง ทางแพ่ง และทางอาญา
โทษทางปกครอง
| ฐานความผิด | มาตรา | โทษปรับสูงสุด |
|---|---|---|
| ไม่แจ้งเหตุการละเมิดตามมาตรา 37(4) | พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 83 | ปรับทางปกครองไม่เกิน 3,000,000 บาท |
| ไม่จัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม (มาตรา 37(1)) | พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 83 | ปรับทางปกครองไม่เกิน 3,000,000 บาท |
| ไม่จัดทำบันทึกรายการกิจกรรม (มาตรา 39) | พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 82 | ปรับทางปกครองไม่เกิน 1,000,000 บาท |
ความรับผิดทางแพ่ง
ตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 77 ผู้ควบคุมข้อมูลหรือผู้ประมวลผลข้อมูลที่ฝ่าฝืนหรือไม่ปฏิบัติตาม ต้องชดใช้ค่าสินไหมทดแทนสำหรับความเสียหายที่เกิดขึ้น ไม่ว่าจะเป็นความเสียหายที่แท้จริงหรือความเสียหายต่อชื่อเสียง และศาลมีอำนาจสั่งให้ชดใช้ค่าสินไหมทดแทนเพิ่มขึ้นได้ตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 78 ได้ถึง 2 เท่าของค่าเสียหายที่แท้จริง (Punitive Damages)
ความรับผิดทางอาญา
ในกรณีที่การละเมิดข้อมูลเข้าข่ายความผิดฐานเปิดเผยข้อมูลส่วนบุคคลโดยไม่ได้รับความยินยอม อาจมีโทษจำคุกไม่เกิน 6 เดือน หรือปรับไม่เกิน 500,000 บาท หรือทั้งจำทั้งปรับ ตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 79 และหากเป็นการเปิดเผยข้อมูลอ่อนไหว โทษจำคุกเพิ่มเป็นไม่เกิน 1 ปี หรือปรับไม่เกิน 1,000,000 บาท หรือทั้งจำทั้งปรับ
ผลกระทบที่เงินซื้อไม่ได้: ชื่อเสียง
นอกเหนือจากโทษทางกฎหมาย ผลกระทบด้านชื่อเสียง (Reputational Damage) มักสร้างความเสียหายมากกว่าค่าปรับ การที่ข่าว Data Breach ถูกรายงานในสื่อ ความเชื่อมั่นของลูกค้าที่สูญเสีย และผลกระทบต่อราคาหุ้น (สำหรับบริษัทจดทะเบียน) เป็นต้นทุนที่ไม่สามารถคำนวณได้ง่าย การตอบสนองที่รวดเร็ว โปร่งใส และมืออาชีพ คือวิธีเดียวที่จะรักษาความเชื่อมั่นไว้ได้
LAS Risk Methodology กับ Data BreachLAS Risk Methodology Applied to Data Breach
LAS Risk Methodology ใช้หลัก Eliminate → Reduce → Distribute ในการจัดการความเสี่ยง ซึ่งสามารถนำมาประยุกต์ใช้กับการป้องกันและตอบสนองต่อ Data Breach ได้โดยตรง
LAS Risk Shield: 3 ระดับ สำหรับ Data Breach
| ระดับ | หลักการ | การประยุกต์ใช้กับ Data Breach |
|---|---|---|
| Eliminate | กำจัดความเสี่ยง | Data Minimization — เก็บข้อมูลเท่าที่จำเป็น / ลบข้อมูลที่ไม่ต้องใช้ / Pseudonymization ข้อมูลอ่อนไหว |
| Reduce | ลดความเสี่ยง | Encryption ทุก Layer / Access Control / MFA / Network Segmentation / Incident Response Plan |
| Distribute | กระจายความเสี่ยง | Cyber Insurance / DPA กับ Processor (กำหนด Indemnity + Liability) / Backup หลาย Location |
ข้อสัญญาที่ต้องมีใน DPA (Data Processing Agreement)
จากมุมมองของ LAS C&C Series สัญญาประมวลผลข้อมูล (DPA) ที่ดีต้องมีข้อสัญญาที่ปกป้ององค์กรในกรณี Breach อย่างน้อยดังต่อไปนี้:
- Breach Notification Obligation: Processor ต้องแจ้ง Controller ภายในเวลาที่กำหนด (เช่น 24 ชั่วโมงหลังทราบเหตุ) เพื่อให้ Controller มีเวลาเพียงพอในการแจ้ง สคส. ภายใน 72 ชั่วโมง
- Cooperation Obligation: Processor ต้องให้ความร่วมมือในการสอบสวนอย่างเต็มที่
- Indemnification: Processor ต้องชดใช้ค่าเสียหายหาก Breach เกิดจากความบกพร่องของ Processor
- Audit Rights: Controller มีสิทธิตรวจสอบมาตรการรักษาความมั่นคงปลอดภัยของ Processor
- Sub-Processing Controls: Processor ต้องได้รับอนุญาตก่อนใช้ Sub-Processor และต้องทำให้ Sub-Processor ปฏิบัติตามมาตรฐานเดียวกัน
สัญญา DPA ที่ดีไม่ได้แค่คัดลอก Template มา แต่ต้อง "คิดล่วงหน้า" ว่าถ้า Breach เกิดขึ้นจริง ข้อสัญญาแต่ละข้อจะทำงานอย่างไร — Notification Timeline ของ Processor สั้นพอที่ Controller จะแจ้ง สคส. ทันไหม? Indemnity ครอบคลุม Punitive Damages 2 เท่าตามมาตรา 78 หรือเปล่า? นี่คือ "C&C Thinking" ที่ต้องใส่ลงในทุก DPA
คำถามที่พบบ่อยFrequently Asked Questions
กฎหมายและแหล่งอ้างอิงLegal References
บทความนี้จัดทำขึ้นเพื่อเผยแพร่ความรู้ทางกฎหมายเท่านั้น ไม่ถือเป็นความเห็นทางกฎหมายหรือคำแนะนำเฉพาะเจาะจง ผู้อ่านควรปรึกษาทนายความก่อนดำเนินการใดๆ ผู้เขียนและ Legal Advance Solution Co., Ltd. ไม่รับผิดชอบต่อความเสียหายใดๆ ที่อาจเกิดจากการนำข้อมูลไปใช้
This article is published for educational purposes only and does not constitute legal advice. The author and Legal Advance Solution Co., Ltd. accept no liability for any loss arising from reliance on this content.