เข้ารหัสแล้วยังต้องแจ้งเหตุหรือไม่ เป็นคำถามที่คู่มือประเมินความเสี่ยงของ สคส. ตอบด้วยตัวอย่าง 10 กรณี ซึ่งมีเพียง 2 กรณีที่ไม่ต้องแจ้งใคร เพราะเข้ารหัสช่วยได้เฉพาะเหตุที่กระทบความลับ เหมาะกับ DPO และฝ่ายไอที ได้แนวประเมินเหตุละเมิด คู่มือเป็นแนวทาง ไม่ใช่กฎหมาย
- ใน 10 ตัวอย่างของคู่มือ สคส. มีแค่ 2 กรณีที่ไม่ต้องแจ้งใคร คือ USB ที่เข้ารหัสแล้วหาย กับไฟดับชั่วคราว
- การเข้ารหัสช่วยได้เฉพาะเหตุที่กระทบความลับ ไม่ช่วยเมื่อข้อมูลถูกล็อก ถูกทำลาย หรือถูกแก้ไข
- Ransomware ที่ไม่มีข้อมูลสำรอง (ตัวอย่างที่ 4) ต้องแจ้งทั้ง สคส. และเจ้าของข้อมูล แม้ข้อมูลจะถูกเข้ารหัสอยู่
- จะขอยกเว้นตามประกาศฯ 2565 ข้อ 9 ต้องพิสูจน์ได้ว่าไม่มีความเสี่ยง และส่งหลักฐานมาตรการรักษาความปลอดภัยให้ สคส.
- คู่มือเป็นแนวทาง ไม่ใช่กฎหมาย หน้าที่แจ้งมาจาก PDPA มาตรา 37 (4) และผู้ควบคุมข้อมูลเป็นผู้ตัดสิน
ถามทีมไอทีว่า "ถ้าเราเข้ารหัสข้อมูลไว้หมดแล้ว ยังต้องแจ้ง สคส. อีกไหม" ส่วนใหญ่จะตอบว่าไม่ต้อง คำตอบนี้ถูกแค่ครึ่งเดียว และครึ่งที่ผิดเป็นครึ่งที่องค์กรต้องจ่ายแพง
คู่มือของสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) เองมีตัวอย่างที่ข้อมูลทั้งระบบถูกเข้ารหัส แต่องค์กรยังต้องแจ้งทั้ง สคส. และเจ้าของข้อมูล เพราะคนที่เข้ารหัสคือแฮกเกอร์ ไม่ใช่องค์กร
คู่มือนี้ชื่อ "คู่มือแนวทางการประเมินความเสี่ยงและแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล" เวอร์ชัน 1.0 ลงวันที่ 15 ธันวาคม 2565 ตรงกับวันที่ประกาศคณะกรรมการเรื่องการแจ้งเหตุ พ.ศ. 2565 มีผล ในเล่มมีตัวอย่าง 10 กรณี แต่ละกรณีบอกว่าต้องแจ้งใครและเพราะอะไร
บทความนี้ไล่ครบทั้ง 10 กรณีตามถ้อยคำของคู่มือ แล้วอ่านคู่กับประกาศฯ 2565 ข้อ 4 และข้อ 12 เพื่อสรุปหลักที่องค์กรนำไปใช้กับเหตุของตัวเองได้
เหตุละเมิดข้อมูลส่วนบุคคลแบ่งเป็นกี่ประเภท?
ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่องหลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565 ข้อ 4 แบ่งไว้ 3 ประเภท เหตุเดียวอาจเข้าได้หลายประเภทพร้อมกัน ประเภทแรกคือการละเมิดความลับ
(1) การละเมิดความลับของข้อมูลส่วนบุคคล (Confidentiality Breach) ซึ่งมีการเข้าถึงหรือเปิดเผยข้อมูลส่วนบุคคล โดยปราศจากอำนาจหรือโดยมิชอบ หรือเกิดจากข้อผิดพลาดบกพร่องหรืออุบัติเหตุ
ประเภทที่สองคือข้อมูลถูกแก้จนผิด เช่น ยอดหนี้ในระบบถูกเปลี่ยน หรือประวัติแพ้ยาถูกลบไปบางบรรทัด ข้อมูลไม่ได้ออกไปไหน แต่คนที่ตัดสินใจจากข้อมูลนั้นอาจทำให้เจ้าของข้อมูลเสียหายโดยไม่รู้ตัว
(2) การละเมิดความถูกต้องครบถ้วนของข้อมูลส่วนบุคคล (Integrity Breach) ซึ่งมีการเปลี่ยนแปลง แก้ไขข้อมูลส่วนบุคคลให้ไม่ถูกต้อง ไม่สมบูรณ์ หรือไม่ครบถ้วน โดยปราศจากอำนาจหรือโดยมิชอบ หรือเกิดจากข้อผิดพลาดบกพร่องหรืออุบัติเหตุ
ประเภทที่สามเป็นเรื่องที่องค์กรมักไม่นับว่าข้อมูลรั่ว เพราะไม่มีอะไรรั่วออกไป เพียงแต่เปิดใช้ข้อมูลไม่ได้
(3) การละเมิดความพร้อมใช้งานของข้อมูลส่วนบุคคล (Availability Breach) ซึ่งทำให้ไม่สามารถเข้าถึงข้อมูลส่วนบุคคลได้ หรือมีการทำลายข้อมูลส่วนบุคคล ทำให้ข้อมูลส่วนบุคคลไม่อยู่ในสภาพที่พร้อมใช้งานได้ตามปกติ
เนื้อหาทั้งบทความนี้วนอยู่กับสามประเภทนี้ การเข้ารหัสมีไว้กันคนอื่นอ่าน ไม่ได้กันข้อมูลหายหรือถูกแก้ ถ้าจัดประเภทเหตุผิดตั้งแต่แรก ข้ออ้างว่า "เราเข้ารหัสแล้ว" ก็จะถูกยกมาใช้ผิดเรื่อง
สคส. ตัดสิน 10 ตัวอย่างไว้อย่างไร?
รายการข้างล่างเรียงตามลำดับในคู่มือ แต่ละข้อบอกคำตอบของคู่มือว่าต้องแจ้ง สคส. และเจ้าของข้อมูลหรือไม่ พร้อมเหตุผลโดยย่อ ส่วนประเภทเหตุในวงเล็บ เราจัดเองตามประกาศฯ 2565 ข้อ 4 คู่มือไม่ได้เขียนไว้
ความเสี่ยงต่ำ ข้อมูลที่เข้ารหัสแล้วเปิดใช้ไม่ได้ USB หายจึงไม่เป็นความเสี่ยงต่อเจ้าของข้อมูล
ข้อมูลยังใช้งานได้และระบุตัวคนได้ อาจสร้างความเสียหายให้เจ้าของข้อมูลจำนวนมาก
ไฟกลับมาเมื่อไร ข้อมูลก็ใช้ได้ตามเดิม จึงไม่ถือว่าเป็นเหตุที่เสี่ยงต่อสิทธิและเสรีภาพ
ข้อมูลระบุตัวคนได้ ใช้งานไม่ได้ ไม่มีข้อมูลสำรอง และอาจเสียหายทั้งต่อธุรกิจและต่อเจ้าของข้อมูล
ข้อมูลรั่วจริง แต่เบื้องต้นกระทบแค่ 10 ราย ธนาคารต้องตรวจต่อว่ามีรายอื่นอีกหรือไม่ ถ้าพบต้องแจ้งเพิ่ม
เป็นความผิดตามกฎหมายคอมพิวเตอร์ ข้อมูลที่หลุดมีข้อมูลสำคัญของผู้ใช้ และเสี่ยงสูงที่จะถูกเอาไปทำธุรกรรมผิดกฎหมาย
เบื้องต้นเป็นความผิดพลาดของโปรแกรม ยังไม่พบการโจมตี แต่กระทบลูกค้าพอสมควร ถ้าตรวจต่อแล้วพบการโจมตี ต้องรีบแจ้งทั้ง สคส. และเจ้าของข้อมูล
ประวัติผู้ป่วยมีข้อมูลสุขภาพ ซึ่งเป็นข้อมูลอ่อนไหวและระบุตัวคนได้ ต้องแจ้งและตรวจสอบเพิ่มเติม
ส่งโดยไม่เข้ารหัส เป็นข้อมูลของคนจำนวนมาก อาจมีทั้งข้อมูลทั่วไปและข้อมูลอ่อนไหว และผู้รับเหมาอาจเอาไปใช้โดยมิชอบ
ข้อมูลของคนจำนวนมากถูกส่งออกไปและอาจถูกนำไปใช้ภายหลัง จะแจ้งเจ้าของข้อมูลหรือไม่ขึ้นกับปริมาณและลักษณะข้อมูล ถ้าเข้ารหัสทั้งหมดอาจถือว่าเสี่ยงต่ำ
นับดูแล้ว มีแค่ตัวอย่างที่ 1 และ 3 ที่ไม่ต้องแจ้งใครเลย อีก 8 กรณีต้องแจ้ง สคส. (ตัวอย่างที่ 7 แจ้งผ่านผู้ควบคุมข้อมูล) และ 7 ใน 8 กรณีนั้นต้องแจ้งเจ้าของข้อมูลอย่างน้อยบางส่วนด้วย ยกเว้นตัวอย่างที่ 7 ที่ยังไม่มีเจ้าของข้อมูลรายใดได้รับผลกระทบ
อีกเรื่องที่น่าสังเกตคือ คู่มือไม่ได้มองแค่ว่าต้องแจ้งทุกคนหรือไม่แจ้งเลย ในตัวอย่างที่ 5 และ 6 สคส. ให้แจ้งเฉพาะคนที่ข้อมูลรั่วจริง
ตัวอย่างการประเมินความเสี่ยงของการละเมิดข้อมูลส่วนบุคคลดังกล่าว เป็นเพียงแนวทางในการประเมินความเสี่ยงเท่านั้น หลักเกณฑ์ในการพิจารณาประเมินความเสี่ยงจะต้องพิจารณาจากข้อเท็จจริงตามปัจจัยที่เกี่ยวข้องเป็นกรณี ๆ ไป
เข้ารหัสไว้แล้ว ไม่ต้องแจ้งเหตุจริงหรือ?
จริงเฉพาะเหตุที่กระทบความลับ คือข้อมูลไปอยู่ในมือคนอื่น แต่เขาเปิดอ่านไม่ได้เพราะเข้ารหัสไว้ ตัวอย่างที่ 1 คือกรณีแบบนี้ และคู่มือให้เหตุผลว่า
ความเสี่ยงต่ำ เนื่องจากเมื่อมีการเข้ารหัสด้วยมาตรการทางเทคโนโลยีที่น่าเชื่อถือแล้ว ข้อมูลดังกล่าวไม่สามารถเปิดใช้งานได้ การที่ USB Drive สูญหายไปจึงไม่มีความเสี่ยงกับเจ้าของข้อมูลส่วนบุคคล
เหตุผลนี้ไปทางเดียวกับประกาศฯ 2565 ข้อ 9 ซึ่งให้ผู้ควบคุมข้อมูลขอยกเว้นไม่ต้องแจ้ง สคส. ได้ ถ้าพิสูจน์ได้ว่าเหตุนั้นไม่มีความเสี่ยง หนึ่งในกรณีที่ประกาศเขียนไว้คือ
ข้อมูลส่วนบุคคลนั้นไม่อยู่ในสภาพที่ใช้งานได้เนื่องจากมีมาตรการทางเทคโนโลยีที่เพียงพอ
ทำไม ransomware จึงได้คำตอบตรงกันข้าม
เอาตัวอย่างที่ 4 มาวางเทียบกับตัวอย่างที่ 1 ข้อมูลในตัวอย่างที่ 4 ก็ถูกเข้ารหัสทั้งหมดเหมือนกัน ต่างกันตรงที่คนถือกุญแจคือผู้โจมตี องค์กรจึงใช้ข้อมูลของตัวเองไม่ได้
คู่มือตัดสินกรณีนี้ตรงข้ามกับตัวอย่างที่ 1 เหตุผลไม่ได้อยู่ที่ว่าใครอ่านข้อมูลได้ แต่อยู่ที่ว่าข้อมูลยังใช้งานได้หรือไม่
การถูกโจมตีจากมัลแวร์เรียกค่าไถ่ทำให้ข้อมูลดังกล่าวไม่อยู่ในสภาพที่พร้อมใช้งาน และไม่มีข้อมูลสำรอง
ความเห็นของเรา (คู่มือไม่ได้เขียนไว้ตรง ๆ) คือ ต่อให้องค์กรในตัวอย่างที่ 4 เข้ารหัสฐานข้อมูลของตัวเองไว้ก่อน ผลก็ไม่ต่างกัน เพราะ ransomware ไม่ต้องอ่านข้อมูล แค่ทำให้เจ้าของเปิดไม่ได้ก็พอ สิ่งที่ทำให้คู่มือตัดสินว่าต้องแจ้งคือ "ไม่มีข้อมูลสำรอง"
ตัวอย่างที่ 8 ก็เช่นกัน ประวัติผู้ป่วยเปิดไม่ได้ 30 ชั่วโมง การเข้ารหัสไม่ได้ช่วยให้แพทย์เปิดประวัติได้เร็วขึ้นเลย และคู่มือให้เหตุผลจากความอ่อนไหวของข้อมูลสุขภาพ ไม่ใช่เพราะมีใครแอบอ่าน
| ประเภทเหตุ | การเข้ารหัสช่วยอะไร | ตัวอย่างในคู่มือ | มาตรการที่ตรงกว่า |
|---|---|---|---|
| ความลับ (Confidentiality) | ช่วยมาก ถ้าใช้เทคโนโลยีที่น่าเชื่อถือ และคนที่ได้ข้อมูลไปไม่มีกุญแจ | ตัวอย่างที่ 1 (ไม่ต้องแจ้ง) · ตัวอย่างที่ 9 (ไม่ได้เข้ารหัส จึงต้องแจ้ง) · ตัวอย่างที่ 10 (ถ้าเข้ารหัสอาจได้รับยกเว้น) | เข้ารหัสอุปกรณ์และไฟล์แนบ เก็บกุญแจแยกไว้ ใช้ BCC หรือระบบส่งอีเมลทีละคน |
| ความถูกต้องครบถ้วน (Integrity) | แทบไม่ช่วย ข้อมูลที่เข้ารหัสยังถูกลบหรือเขียนทับได้ ถ้าคนทำมีสิทธิแก้ไข | คู่มือไม่มีตัวอย่างตรง | จำกัดสิทธิแก้ไข เก็บประวัติการแก้ไข ตรวจความถูกต้องของข้อมูลสำคัญ |
| ความพร้อมใช้งาน (Availability) | ไม่ช่วย ข้อมูลที่เข้ารหัสแล้วยังถูกล็อกหรือถูกทำลายได้เหมือนเดิม | ตัวอย่างที่ 3 (ไม่ต้องแจ้ง) · ตัวอย่างที่ 4, 7, 8 (ต้องแจ้ง) | มีข้อมูลสำรองแยกจากระบบหลักและซ้อมกู้คืนจริง มีระบบสำรอง และมีแผนรับมือเหตุ |
เหตุขององค์กรคุณใกล้กับตัวอย่างไหน และต้องแจ้งใคร?
เริ่มจากถามว่าเหตุนี้กระทบความลับ ความถูกต้องครบถ้วน หรือความพร้อมใช้งาน แล้วหาตัวอย่างในคู่มือที่ใกล้ที่สุด ตารางข้างล่างใช้เป็นจุดตั้งต้นเท่านั้น ช่องขวาสุดคือเรื่องที่อาจทำให้เหตุของคุณต่างจากตัวอย่าง
| ถ้าเหตุเป็นแบบนี้ | ตัวอย่างที่ใกล้ที่สุด | คู่มือมีแนวโน้มว่า | ตรวจก่อนตัดสิน |
|---|---|---|---|
| อุปกรณ์หรือไฟล์สำรองหาย แต่เข้ารหัสด้วยเทคโนโลยีที่น่าเชื่อถือ | 1 | ไม่ต้องแจ้ง สคส. และเจ้าของข้อมูล | กุญแจหรือรหัสผ่านหายไปด้วยหรือไม่ มีหลักฐานการเข้ารหัสพอยื่นตามข้อ 9 หรือไม่ |
| ส่งไฟล์หรืออีเมลที่มีข้อมูลคนจำนวนมากไปผิดคน โดยไม่ได้เข้ารหัส | 9 | แจ้งทั้ง สคส. และเจ้าของข้อมูล | มีข้อมูลอ่อนไหวหรือไม่ ผู้รับเป็นใคร ยืนยันได้ไหมว่าลบแล้ว |
| อีเมลกลุ่มที่ผู้รับเห็นอีเมลของกันและกัน | 10 | แจ้ง สคส. และเจ้าของข้อมูล เว้นแต่เข้ารหัสด้วยเทคโนโลยีที่น่าเชื่อถือ | มีผู้รับกี่คน และอีเมลเปิดเผยอะไรอีกนอกจากที่อยู่อีเมล |
| ลูกค้าร้องเรียนว่าได้เอกสารของคนอื่น | 5 | แจ้ง สคส. และแจ้งเฉพาะผู้ที่ได้รับผลกระทบ | ตรวจต่อว่ามีรายอื่นอีกหรือไม่ ถ้าพบต้องแจ้งเพิ่ม |
| ระบบถูกเจาะ ข้อมูลถูกดึงออกไปหรือถูกโพสต์ | 2 · 6 | แจ้งทั้ง สคส. และเจ้าของข้อมูล (ตัวอย่างที่ 6 แจ้งเฉพาะผู้ที่ข้อมูลรั่ว) | มีรหัสผ่าน ข้อมูลการเงิน หรือข้อมูลที่ใช้ทำธุรกรรมได้หรือไม่ |
| Ransomware ล็อกข้อมูลและไม่มีข้อมูลสำรอง | 4 | แจ้งทั้ง สคส. และเจ้าของข้อมูล | ผู้โจมตีดึงข้อมูลออกไปด้วยหรือไม่ ถ้าใช่ เหตุนี้เป็นการละเมิดความลับด้วย |
| ระบบล่มชั่วคราวเพราะไฟฟ้าหรือฮาร์ดแวร์ แล้วกลับมาครบ | 3 | ไม่ต้องแจ้ง | มีร่องรอยการโจมตีหรือไม่ ข้อมูลกลับมาครบจริงหรือไม่ |
| ผู้ให้บริการภายนอกมีบั๊ก ลูกค้าเข้าถึงข้อมูลไม่ได้ | 7 | ผู้ประมวลผลแจ้งผู้ควบคุม แล้วผู้ควบคุมแจ้ง สคส. | ตรวจต่อว่ามีการโจมตีหรือไม่ ถ้าพบต้องแจ้งเจ้าของข้อมูลด้วย |
| ข้อมูลสุขภาพหรือข้อมูลอ่อนไหวเปิดไม่ได้เพราะถูกโจมตี | 8 | แจ้งทั้ง สคส. และเจ้าของข้อมูล | เปิดไม่ได้นานเท่าไร มีข้อมูลรั่วออกไปด้วยหรือไม่ |
มีสองกรณีที่คู่มือไม่มีตัวอย่างตรงและควรระวังเป็นพิเศษ กรณีแรกคือ ransomware ที่มีข้อมูลสำรองและกู้คืนได้เร็ว ตัวอย่างที่ 4 ให้น้ำหนักกับการไม่มีข้อมูลสำรอง แต่ ransomware ทุกวันนี้จำนวนมากดึงข้อมูลออกไปก่อนแล้วค่อยล็อก ถ้ามีหลักฐานว่าข้อมูลถูกดึงออก เหตุนั้นก็เป็นการละเมิดความลับแบบตัวอย่างที่ 2 ทันที
กรณีที่สองคือการละเมิดความถูกต้องครบถ้วน ซึ่งคู่มือไม่มีตัวอย่างเลย องค์กรต้องกลับไปประเมินตามปัจจัยในประกาศฯ 2565 ข้อ 12 โดยตรง
ปัจจัย 8 ข้อตามประกาศฯ 2565 ข้อ 12 อยู่ในตัวอย่างไหนบ้าง?
ประกาศฯ 2565 ข้อ 12 เป็นรายการปัจจัยที่ผู้ควบคุมข้อมูล "อาจพิจารณา" เมื่อประเมินความเสี่ยง คำนำของคู่มือ สคส. บอกไว้เองว่าทำตัวอย่างขึ้นจากข้อ 4 และข้อ 12 ถ้าอ่านเหตุผลในคู่มือย้อนกลับไปหาปัจจัยทีละข้อ ก็จะเห็นว่า สคส. ให้น้ำหนักกับเรื่องใด
ในการประเมินความเสี่ยงสำหรับการละเมิดข้อมูลส่วนบุคคล ว่ามีความเสี่ยงที่จะมีผลกระทบต่อสิทธิและเสรีภาพของบุคคลเพียงใด ผู้ควบคุมข้อมูลส่วนบุคคลอาจพิจารณาจากปัจจัยดังต่อไปนี้
- ลักษณะและประเภทของการละเมิด ไฟดับในตัวอย่างที่ 3 กับ ransomware ในตัวอย่างที่ 4 เป็นเหตุด้านความพร้อมใช้งานทั้งคู่ แต่ผลต่างกัน เพราะกรณีไฟดับ ข้อมูลกลับมาเองเมื่อไฟมา
- ประเภทของข้อมูล ตัวอย่างที่ 8 คู่มือระบุตรง ๆ ว่าข้อมูลสุขภาพเป็นข้อมูลอ่อนไหว อ่านเพิ่มที่ คู่มือข้อมูลอ่อนไหว
- ปริมาณข้อมูล ตัวอย่างที่ 9 และ 10 ใช้คำว่า "จำนวนมาก" เป็นเหตุผล ส่วนตัวอย่างที่ 5 แจ้งเจ้าของข้อมูลเฉพาะ 10 รายที่ได้รับผลกระทบจริง
- สถานะของเจ้าของข้อมูล เช่น ผู้เยาว์หรือคนเปราะบาง คู่มือไม่ได้ยกปัจจัยนี้ในตัวอย่างที่ 9 แต่ถ้านักเรียนเป็นผู้เยาว์ ปัจจัยข้อ (4) ก็ใช้กับเหตุของโรงเรียนได้ด้วย
- ความร้ายแรงและผลของมาตรการ ในตัวอย่างที่ 6 รหัสผ่านที่ถูกโพสต์เสี่ยงต่อการทำธุรกรรมผิดกฎหมาย ส่วนตัวอย่างที่ 1 การเข้ารหัสได้ผลจนความเสี่ยงต่ำ
- ผลกระทบวงกว้างต่อธุรกิจหรือสาธารณะ ตัวอย่างที่ 4 คู่มือระบุว่าอาจเสียหายต่อธุรกิจของผู้ควบคุมข้อมูลด้วย
- ระบบจัดเก็บและมาตรการรักษาความมั่นคงปลอดภัย การไม่มีข้อมูลสำรองในตัวอย่างที่ 4 และการส่งโดยไม่เข้ารหัสในตัวอย่างที่ 9 ตรงกับปัจจัยข้อนี้
- สถานะทางกฎหมายและขนาดกิจการของผู้ควบคุมข้อมูล ไม่มีตัวอย่างใดยกปัจจัยนี้ขึ้นมาตรง ๆ แต่ สคส. ยังนำมาพิจารณาได้
ใครเป็นผู้ตัดสินว่าต้องแจ้งหรือไม่?
ผู้ควบคุมข้อมูลส่วนบุคคลเป็นผู้ตัดสิน โดยมี DPO ให้ความเห็น ไม่ใช่คู่มือ ไม่ใช่ซอฟต์แวร์ และไม่ใช่ทีมไอทีตัดสินกันเอง หน้าที่ตาม พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล มาตรา 37 (4) เป็นของผู้ควบคุมข้อมูล และเกณฑ์แจ้งเจ้าของข้อมูลสูงกว่าเกณฑ์แจ้ง สคส. อีกขั้นหนึ่ง
ในกรณีที่การละเมิดมีความเสี่ยงสูงที่จะมีผลกระทบต่อสิทธิและเสรีภาพของบุคคล ให้แจ้งเหตุการละเมิดให้เจ้าของข้อมูลส่วนบุคคลทราบพร้อมกับแนวทางการเยียวยาโดยไม่ชักช้าด้วย
ประโยชน์ของ 10 ตัวอย่างนี้คือทำให้ทีมไอที ฝ่ายกฎหมาย และผู้บริหารคุยกันรู้เรื่อง เมื่อทุกฝ่ายชี้ไปที่ตัวอย่างเดียวกันได้ การถกเถียงก็สั้นลงมาก
แต่ถ้าตัดสินว่า "ไม่ต้องแจ้ง" ต้องมีเหตุผลและหลักฐานรองรับตามประกาศฯ 2565 ข้อ 9 และควรจดไว้ว่าใครตัดสิน เมื่อไร จากข้อเท็จจริงชุดไหน ถ้าข้อเท็จจริงเปลี่ยน เช่น พบภายหลังว่าผู้โจมตีดึงข้อมูลออกไปด้วย ก็ต้องตัดสินใหม่ ขณะที่กำหนด 72 ชั่วโมงยังนับต่อไป ดูวิธีจัดลำดับงานได้ใน 72 ชั่วโมงแรกหลังข้อมูลรั่ว
ถ้าจะเริ่มจากการป้องกัน มีสามมาตรการที่ตรงกับเหตุสามประเภทในข้อ 4 คือ เข้ารหัสอุปกรณ์พกพา เก็บข้อมูลสำรองแยกจากระบบหลัก และจำกัดสิทธิแก้ไขข้อมูล ดูมาตรการขั้นต่ำได้ที่ คู่มือมาตรการรักษาความมั่นคงปลอดภัย และขั้นตอนแจ้งเหตุแบบย่อที่ คู่มือแจ้งเหตุภายใน 72 ชั่วโมง
คำถามที่พบบ่อย
เข้ารหัสข้อมูลไว้แล้ว ถ้าหลุดไปไม่ต้องแจ้ง สคส. ใช่ไหม?
ไม่เสมอไป ตัวอย่างที่ 1 ในคู่มือ สคส. ไม่ต้องแจ้งเพราะข้อมูลที่หลุดไปเปิดใช้ไม่ได้ แต่ประกาศฯ 2565 ข้อ 9 กำหนดให้ผู้ควบคุมข้อมูลต้องพิสูจน์และส่งหลักฐานเรื่องมาตรการ และถ้าเหตุกระทบความพร้อมใช้งาน เช่น ransomware ที่ไม่มีข้อมูลสำรองในตัวอย่างที่ 4 การเข้ารหัสก็ไม่ช่วยลดความเสี่ยงเลย
ระบบล่มจนลูกค้าใช้บริการไม่ได้ ถือเป็นเหตุละเมิดข้อมูลไหม?
อาจเป็นการละเมิดความพร้อมใช้งานตามประกาศฯ 2565 ข้อ 4 (3) คู่มือ สคส. ตัดสินต่างกันตามข้อเท็จจริง ไฟดับชั่วคราวในตัวอย่างที่ 3 ไม่ต้องแจ้ง บั๊กของผู้รับจ้างในตัวอย่างที่ 7 ต้องแจ้ง สคส. ผ่านผู้ควบคุม ส่วนโรงพยาบาลที่ถูกแฮกในตัวอย่างที่ 8 ต้องแจ้งทั้ง สคส. และเจ้าของข้อมูล
คู่มือ 10 ตัวอย่างนี้มีผลบังคับเป็นกฎหมายไหม?
ไม่มี เป็นแนวทางของสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เวอร์ชัน 1.0 ลงวันที่ 15 ธันวาคม 2565 และหมายเหตุในคู่มือเองระบุว่าต้องดูข้อเท็จจริงเป็นกรณี ๆ ไป หน้าที่ที่ผูกพันจริงมาจาก PDPA มาตรา 37 (4) และประกาศคณะกรรมการ พ.ศ. 2565
ต้องแจ้งเจ้าของข้อมูลทุกคนในระบบไหม?
ไม่จำเป็น ในตัวอย่างที่ 5 คู่มือให้แจ้งเฉพาะ 10 รายที่ได้รับผลกระทบ และในตัวอย่างที่ 6 ให้แจ้งเฉพาะลูกค้าที่ข้อมูลถูกโพสต์บนอินเทอร์เน็ต แต่ต้องตรวจต่อว่ามีผู้ได้รับผลกระทบเพิ่มหรือไม่ ถ้าพบก็ต้องแจ้งเพิ่ม
ใครควรเป็นคนตัดสินว่าเหตุนี้ต้องแจ้งหรือไม่?
หน้าที่ตาม PDPA มาตรา 37 (4) เป็นของผู้ควบคุมข้อมูลส่วนบุคคล ในทางปฏิบัติ DPO ให้ความเห็น และผู้บริหารที่มีอำนาจเป็นผู้ตัดสิน ซอฟต์แวร์หรือ AI ช่วยจับคู่ตัวอย่างและเตรียมเหตุผลได้ แต่ไม่ควรตัดสินแทนคน
ตัวบทและแหล่งอ้างอิง
- คู่มือแนวทางการประเมินความเสี่ยงและแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล เวอร์ชัน 1.0 (สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล · 15 ธันวาคม 2565) — แนวทาง ไม่ใช่กฎหมาย — ตัวอย่างที่ 1–10 · หมายเหตุ
- ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565 — ข้อ 4 · ข้อ 9 · ข้อ 12
- พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 — มาตรา 37 (4)
ตัวบทที่ยกมาในกรอบ "ตัวบท" คัดคำต่อคำจากคลังกฎหมายของ AIPDPA ซึ่งถอดจากราชกิจจานุเบกษาและเอกสารของหน่วยงานรัฐ แล้วระบบตรวจทุกครั้งที่แก้บทความว่าตรงกับคลังทุกตัวอักษร · บทความนี้เป็นความรู้ทั่วไป ไม่ใช่คำปรึกษากฎหมายสำหรับกรณีใดกรณีหนึ่ง
ลงมือในระบบได้ที่
ใครรับผิดชอบเนื้อหานี้?
เรียบเรียงโดยทีมกฎหมาย AIPDPA · ผู้รับผิดชอบเนื้อหา ภูวรา ครอบตะคุ ทนายความ · เนติบัณฑิตไทย · ที่ปรึกษากฎหมายเทคโนโลยีและทรัพย์สินทางปัญญา
ใบอนุญาตทนายความ 477/2558 · เนติบัณฑิตไทย · นิติศาสตรมหาบัณฑิต กฎหมายทรัพย์สินทางปัญญาและสารสนเทศ (เหรียญทอง)