ข้อมูลรั่ว 6 ชั่วโมงแรกต้องทำอะไร เช็กลิสต์ 10 ข้อ ฉบับทนาย

ตอนบ่ายสามโมง พนักงานคนหนึ่งเดินมาบอกว่าเผลอส่งไฟล์รายชื่อลูกค้าเข้ากลุ่มผิดกลุ่ม หรือฝ่ายไอทีแจ้งว่าพบการเข้าถึงฐานข้อมูลที่ผิดปกติ สิ่งที่เกิดขึ้นต่อจากนั้นในองค์กรส่วนใหญ่คือการประชุมหาว่าใครผิด ทั้งที่6 ชั่วโมงแรกควรถูกใช้ไปกับอย่างอื่นทั้งหมด เพราะเป็นช่วงเดียวที่ทำบางอย่างได้ และเมื่อผ่านไปแล้วจะย้อนกลับมาทำไม่ได้อีก

ทำไมต้องเป็น 6 ชั่วโมง ทั้งที่กฎหมายให้ 72 ชั่วโมง

ภาพรวมหน้าที่แจ้งเหตุทั้งหมดอยู่ที่คู่มือข้อมูลรั่วไหล ต้องแจ้งใครภายใน 72 ชั่วโมง · กรอบ 72 ชั่วโมงคือกำหนดการแจ้งเหตุ ไม่ใช่กำหนดการเริ่มลงมือ และในทางปฏิบัติเวลาที่เหลือจริงน้อยกว่าที่คิดมาก เพราะเหตุมักเกิดตอนเย็นวันศุกร์หรือช่วงวันหยุด ผู้มีอำนาจตัดสินใจติดต่อไม่ได้ทันที และการรวบรวมข้อเท็จจริงให้พอจะตัดสินใจได้ใช้เวลาหลายชั่วโมง

ที่สำคัญกว่านั้นคือหลักฐานบางอย่างมีอายุ บันทึกการเข้าใช้งานระบบ ข้อความในกลุ่มแชท และไฟล์ชั่วคราวจำนวนมากถูกลบตามรอบอัตโนมัติ องค์กรที่ใช้เวลาหกชั่วโมงแรกไปกับการหาคนผิด มักพบว่าตอนจะรวบรวมหลักฐานจริง สิ่งที่ต้องการหายไปแล้ว

ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565 วางลำดับไว้ชัดว่า เมื่อได้รับแจ้งว่ามีหรือน่าจะมีเหตุละเมิด ให้ประเมินความน่าเชื่อถือของข้อมูลและตรวจสอบข้อเท็จจริงก่อน แล้วจึงประเมินความเสี่ยง และหากพบว่าเสี่ยงสูงต้องดำเนินการป้องกัน ระงับ หรือแก้ไขโดยทันทีเท่าที่จะทำได้ — คำว่าโดยทันทีนี้เองที่ทำให้หกชั่วโมงแรกมีความหมาย

เช็กลิสต์ 10 ข้อที่ต้องทำให้เสร็จใน 6 ชั่วโมงแรก

#	สิ่งที่ต้องทำ	ผลลัพธ์ที่ต้องได้
1	จดวันและเวลาที่ทราบเหตุ พร้อมชื่อผู้แจ้งและช่องทางที่แจ้ง	บรรทัดแรกของ Incident Timeline ซึ่งเป็นจุดเริ่มนับ 72 ชั่วโมง
2	สั่งหยุดทำลายและแก้ไขข้อมูลที่เกี่ยวข้อง เป็นลายลักษณ์อักษร ครอบคลุมบันทึกระบบ อีเมล แชท และเอกสาร	หนังสือสั่งการภายในที่มีวันเวลา
3	ตั้งผู้รับผิดชอบเรื่องหนึ่งคน และผู้มีอำนาจตัดสินใจหนึ่งคน แจ้งภายในว่าห้ามสื่อสารออกนอกองค์กรก่อน	ชื่อสองชื่อที่ทุกคนรู้ตรงกัน
4	ระงับไม่ให้ลุกลาม เช่น ตัดสิทธิเข้าถึง เปลี่ยนรหัสผ่าน ปิดลิงก์แชร์ ถอนไฟล์จากกลุ่ม เท่าที่ทำได้ทันที	บันทึกว่าทำอะไรไปแล้วบ้าง เวลาใด โดยใคร
5	เก็บหลักฐานทางเทคนิคทันที เช่น บันทึกการเข้าใช้งาน ภาพหน้าจอกลุ่มแชท รายชื่อผู้อยู่ในกลุ่ม	ไฟล์หลักฐานพร้อมวิธีและเวลาที่เก็บ
6	ระบุว่าข้อมูลอะไรรั่ว ประเภทใด ปริมาณเท่าใด และกระทบคนกี่ราย	ตัวเลขเบื้องต้นที่ใช้ประเมินความเสี่ยง
7	ประเมินว่ามีกลุ่มเปราะบางได้รับผลกระทบหรือไม่ และมีข้อมูลอ่อนไหวปนอยู่หรือเปล่า	ข้อสรุปที่มีผลต่อระดับความเสี่ยงโดยตรง
8	เริ่มประเมินความเสี่ยงตามปัจจัยที่ประกาศกำหนด โดยยังไม่ต้องสรุปผล แต่ต้องเริ่มบันทึก	ร่างการประเมินความเสี่ยงพร้อมเหตุผล
9	ตรวจว่าเหตุมาจากคู่ค้าหรือไม่ ถ้าใช่ ให้ติดต่อขอข้อเท็จจริงและตรวจข้อสัญญาเรื่องการแจ้งเหตุ	ความชัดเจนว่าใครเป็นผู้ควบคุมและใครต้องแจ้ง
10	ติดต่อทนายเพื่อประเมินหน้าที่แจ้งเหตุ ก่อนที่จะสื่อสารกับใครนอกองค์กร	แนวการตัดสินใจเรื่องแจ้งหรือไม่แจ้ง พร้อมเหตุผลที่บันทึกได้

สังเกตว่าข้อ 1 ถึง 5 ทำได้โดยไม่ต้องรู้ว่าเกิดอะไรขึ้นครบถ้วน ซึ่งเป็นข้อดี เพราะองค์กรมักรอจนเข้าใจเหตุทั้งหมดก่อนจึงเริ่มลงมือ ทั้งที่ห้าข้อแรกนี้ควรเริ่มภายในชั่วโมงแรก

ประเมินความเสี่ยงจากอะไรบ้าง

ประกาศฉบับปี 2565 วางปัจจัยการประเมินความเสี่ยงไว้ 8 ข้อ ซึ่งเป็นสิ่งที่องค์กรควรใช้เป็นโครงในการบันทึกตั้งแต่ชั่วโมงแรก ไม่ใช่เพิ่งมานั่งเขียนตอนใกล้ครบ 72 ชั่วโมง

• ลักษณะและประเภทของการละเมิด
• ลักษณะและประเภทของข้อมูลส่วนบุคคลที่เกี่ยวข้อง
• ปริมาณของข้อมูล โดยพิจารณาจำนวนข้อมูลและจำนวนรายการที่เกี่ยวข้อง
• ลักษณะ ประเภท และสถานะของเจ้าของข้อมูล โดยพิจารณาว่าเป็นกลุ่มเปราะบางหรือไม่
• ความร้ายแรงของผลกระทบและความเสียหายที่จะเกิดกับเจ้าของข้อมูล และประสิทธิภาพของมาตรการป้องกัน ระงับ แก้ไข หรือการเยียวยา
• ผลกระทบในวงกว้างต่อธุรกิจหรือการดำเนินการขององค์กรหรือต่อสาธารณะ
• ลักษณะของระบบเก็บข้อมูลที่เกี่ยวกับการละเมิด และมาตรการรักษาความมั่นคงปลอดภัยที่มีอยู่
• สถานะทางกฎหมายและขนาดของผู้ควบคุมข้อมูลส่วนบุคคล

ข้อสังเกตเชิงปฏิบัติคือ ปัจจัยข้อที่ห้าพูดถึงประสิทธิภาพของมาตรการระงับและเยียวยาด้วย ซึ่งแปลว่าสิ่งที่องค์กรทำในหกชั่วโมงแรกส่งผลต่อระดับความเสี่ยงที่ประเมินได้โดยตรง ไม่ใช่แค่เป็นการทำความดีเก็บไว้

คนส่วนใหญ่มักเข้าใจผิดตรงไหน

เข้าใจผิดที่ 1: "ต้องรู้ให้ครบก่อนถึงเริ่มนับเวลา" — ความจริง คือประกาศพูดถึงกรณี "มีหรือน่าจะมี" เหตุละเมิด และให้เริ่มตรวจสอบข้อเท็จจริงทันที · ผลเสีย คือรอจนแน่ใจแล้วเหลือเวลาไม่พอ

เข้าใจผิดที่ 2: "รีบบอกลูกค้าไปก่อนจะได้ดูจริงใจ" — ความจริง คือการแจ้งเจ้าของข้อมูลมีรายละเอียดที่กฎหมายกำหนดไว้ และการสื่อสารก่อนรู้ข้อเท็จจริงมักต้องแก้คำพูดภายหลัง · ผลเสีย คือคำแถลงแรกกลายเป็นหลักฐานที่ขัดกับข้อเท็จจริงที่พบทีหลัง

เข้าใจผิดที่ 3: "ประเมินแล้วว่าไม่เสี่ยง ก็ไม่ต้องทำอะไรต่อ" — ความจริง คือแม้ไม่ต้องแจ้ง ก็ต้องบันทึกเหตุผลของการตัดสินใจไว้ให้ใช้ยันได้ · ผลเสีย คือเมื่อถูกตรวจภายหลัง องค์กรมีแค่คำพูดว่าประเมินแล้ว แต่ไม่มีเอกสาร

เข้าใจผิดที่ 4: "เป็นเรื่องของฝ่ายไอที" — ความจริง คือการตัดสินใจว่าต้องแจ้งหรือไม่เป็นการตัดสินใจทางกฎหมายที่อาศัยข้อเท็จจริงทางเทคนิค · ผลเสีย คือได้รายงานทางเทคนิคที่ละเอียดมาก แต่ตอบไม่ได้ว่าองค์กรมีหน้าที่อะไร

เลนส์ทนายยอดทิพย์ธรรม

คนทั่วไปมักเข้าใจว่า… การรับมือเหตุข้อมูลรั่วที่ดีคือการอุดช่องโหว่ให้เร็วที่สุด แล้วเรื่องก็จบ

แต่ในทางคดี กฎหมายและศาลมักมองว่า… การอุดช่องโหว่เป็นเพียงครึ่งเดียว อีกครึ่งคือองค์กรพิสูจน์ได้หรือไม่ว่าทำอะไรไปบ้าง เมื่อไร และตัดสินใจบนพื้นฐานอะไร เพราะทั้งการกำหนดโทษและการประเมินความเสี่ยงล้วนอิงกับหลักฐานเหล่านี้

จุดเสี่ยงจริงอยู่ตรงนี้… องค์กรที่รับมือได้ดีมากในทางเทคนิค แต่ไม่มีใครจดอะไรเลยระหว่างนั้น จะกลับมาเขียนรายงานย้อนหลังจากความทรงจำ ซึ่งมักมีช่องว่างและขัดกันเอง และเป็นจุดที่ถูกโจมตีได้ง่ายที่สุด

ทางเลือกที่ควรทำต่อคือ… ให้คนหนึ่งคนทำหน้าที่จดอย่างเดียวตั้งแต่นาทีแรก โดยไม่ต้องทำอย่างอื่น จดเวลา จดสิ่งที่ทำ จดคนที่ตัดสินใจ เท่านี้ก็เปลี่ยนคุณภาพของสำนวนทั้งเรื่องได้แล้ว

ปลายทางถ้าพลาดในหกชั่วโมงแรก

1. หลักฐานทางเทคนิคหายไปตามรอบอัตโนมัติ ทำให้พิสูจน์ไม่ได้ว่าเหตุมีขอบเขตแค่ไหน
2. เมื่อประเมินขอบเขตไม่ได้ การตัดสินใจเรื่องแจ้งเหตุก็ทำบนข้อมูลที่ไม่ครบ และมีความเสี่ยงทั้งการแจ้งเกินจำเป็นและการไม่แจ้งทั้งที่ต้องแจ้ง
3. หากเลยกรอบ 72 ชั่วโมง จะกลายเป็นประเด็นเพิ่มอีกหนึ่งประเด็นแยกจากประเด็นเดิมเรื่องมาตรการรักษาความมั่นคงปลอดภัย ซึ่งเคยปรากฏในคำสั่งจริงมาแล้วว่าถูกวินิจฉัยเป็นสองฐาน
4. ในการพิจารณาโทษ ปัจจัยเรื่องการเยียวยาและบรรเทาความเสียหายเมื่อทราบเหตุ เป็นสิ่งที่ต้องแสดงด้วยหลักฐานที่มีวันเวลา ไม่ใช่ด้วยคำอธิบาย
5. และหากผู้เสียหายเป็นพนักงาน เรื่องมักเดินต่อที่ศาลแรงงานอีกทางหนึ่ง

หลักฐานที่ต้องเก็บ

• Incident Timeline ที่เริ่มจากวันเวลาที่ทราบเหตุ พร้อมชื่อผู้แจ้ง
• หนังสือสั่งหยุดทำลายข้อมูล พร้อมขอบเขตและรายชื่อผู้รับทราบ
• บันทึกมาตรการระงับที่ทำไปแล้ว ระบุเวลาและผู้ดำเนินการ
• หลักฐานทางเทคนิคที่เก็บไว้ พร้อมวิธีและเวลาที่เก็บ
• เอกสารประเมินความเสี่ยงที่อ้างอิงปัจจัยตามประกาศ พร้อมข้อสรุปและเหตุผล
• บันทึกการตัดสินใจว่าจะแจ้งหรือไม่แจ้ง พร้อมชื่อผู้ตัดสินใจ
• สำเนาการติดต่อคู่ค้า หากเหตุเกี่ยวข้องกับผู้ให้บริการภายนอก

ถ้าเป็นฝ่ายองค์กร ต้องเตรียมอะไรไว้ก่อนเกิดเหตุ

• รายชื่อทีมรับมือพร้อมเบอร์ติดต่อนอกเวลาทำการ
• แบบฟอร์ม Incident Timeline ที่กรอกได้ทันทีโดยไม่ต้องออกแบบใหม่
• แบบฟอร์มประเมินความเสี่ยงที่วางตามปัจจัย 8 ข้อของประกาศ
• หนังสือสั่งหยุดทำลายข้อมูลแบบสำเร็จรูปที่แค่เติมขอบเขตก็ใช้ได้
• รายชื่อระบบและผู้ดูแลแต่ละระบบ พร้อมข้อมูลว่าบันทึกแต่ละประเภทเก็บไว้กี่วัน
• ข้อสัญญากับคู่ค้าเรื่องกรอบเวลาแจ้งเหตุกลับมาที่องค์กร
• ช่องทางติดต่อทนายนอกเวลาทำการ
• การซ้อมอย่างน้อยปีละครั้งกับสถานการณ์สมมติที่ใกล้เคียงงานจริง

อีกฝ่ายอาจโต้แย้งอย่างไร

• "ทราบเหตุก่อนวันที่อ้าง" — ยกข้อความในกลุ่มแชทหรืออีเมลที่มีคนพูดถึงเหตุก่อนหน้านั้น
• "หลักฐานหายหลังทราบเหตุ" — เมื่อไม่มีคำสั่งหยุดทำลาย จะอธิบายได้ยากมาก
• "ประเมินว่าไม่เสี่ยงโดยไม่มีเอกสาร" — การประเมินที่ไม่มีบันทึก มักถูกมองว่าไม่ได้ประเมินจริง
• "ระงับเหตุช้า" — เทียบเวลาที่ทราบเหตุกับเวลาที่เริ่มระงับ ซึ่งเป็นตัวเลขที่ตรวจสอบได้จากบันทึกระบบ
• "แถลงต่อสาธารณะไม่ตรงกับที่แจ้งหน่วยงาน" — เกิดขึ้นเมื่อองค์กรรีบสื่อสารก่อนตั้งหลัก

ลำดับที่ควรทำถ้าเกิดเหตุวันนี้

1. จดเวลาที่ทราบเหตุเป็นสิ่งแรก ก่อนทำอย่างอื่นทั้งหมด
2. ตั้งผู้รับผิดชอบและผู้จดบันทึก โดยผู้จดไม่ต้องทำงานอื่น
3. ออกคำสั่งหยุดทำลายข้อมูลเป็นลายลักษณ์อักษร
4. ระงับไม่ให้ความเสียหายลุกลามเท่าที่ทำได้ทันที พร้อมจดทุกอย่างที่ทำ
5. เก็บหลักฐานทางเทคนิคก่อนที่รอบการลบอัตโนมัติจะมาถึง
6. ติดต่อทนายเพื่อประเมินหน้าที่แจ้งเหตุ ก่อนสื่อสารกับบุคคลภายนอก

กรณีแบบไหนที่ควรปรึกษาทนายทันที

• ไม่แน่ใจว่าเหตุที่เกิดเข้าข่ายต้องแจ้งหรือไม่ หรือไม่แน่ใจว่าต้องเริ่มนับ 72 ชั่วโมงจากเมื่อใด
• ข้อมูลที่รั่วมีเลขบัตรประจำตัวประชาชน ข้อมูลสุขภาพ หรือข้อมูลอ่อนไหวอื่น
• ข้อมูลถูกเผยแพร่ต่อในสื่อสังคมออนไลน์หรือเว็บไซต์แล้ว
• เหตุเกิดจากคู่ค้าหรือผู้ให้บริการภายนอก หรือเกิดจากการส่งไฟล์ผ่านแอปแชท
• มีผู้เสียหายจำนวนมาก หรือมีกลุ่มเปราะบางรวมอยู่ด้วย
• เหตุเกิดจากพนักงานที่กำลังมีข้อพิพาทกับองค์กร
• ใกล้ครบ 72 ชั่วโมงแล้วแต่ยังตัดสินใจไม่ได้

สำนักงานกฎหมายยอดทิพย์ธรรม ช่วยอะไรได้บ้าง

บริการประเมินเหตุข้อมูลรั่วไหลเร่งด่วน ซึ่งเป็นส่วนหนึ่งของงานที่ปรึกษากฎหมาย PDPA สำหรับองค์กร ออกแบบมาสำหรับช่วงเวลานี้โดยเฉพาะ คือจัดทำ Incident Timeline ตรวจข้อเท็จจริงเบื้องต้น ประเมินระดับความเสี่ยง จัดรายการสิ่งที่ต้องทำทันที และบันทึกเหตุผลประกอบการตัดสินใจแจ้งเหตุ ซึ่งเป็นเอกสารที่ต้องใช้ยันในชั้นชี้แจงภายหลัง

สิ่งที่เราเน้นคือการจัดระบบเอกสารและพยานหลักฐานตั้งแต่ต้น เพื่อลดความเสี่ยงที่องค์กรจะเสียเปรียบเพราะเริ่มผิดทาง และเราจะบอกตรง ๆ ว่ากรณีไหนที่ประเมินแล้วไม่เข้าเกณฑ์ต้องแจ้ง เพราะการแจ้งเกินความจำเป็นก็สร้างภาระและความเสี่ยงด้านชื่อเสียงเช่นกัน

สรุป

6 ชั่วโมงแรกคือช่วงที่ตัดสินคุณภาพของทั้งเรื่อง ไม่ใช่เพราะกฎหมายกำหนดไว้ แต่เพราะเป็นช่วงเดียวที่ยังเก็บหลักฐานได้ทัน ยังระงับความเสียหายได้ และยังบันทึกเวลาที่ทราบเหตุได้อย่างตรงไปตรงมา

สิ่งที่ต้องทำเป็นอันดับแรกไม่ใช่การหาว่าใครผิด แต่คือการจดว่าทราบเหตุตอนกี่โมง เพราะเป็นคำถามแรกที่จะถูกถาม และเป็นคำถามที่องค์กรจำนวนมากตอบไม่ได้

หากคุณกำลังเจอปัญหาลักษณะนี้ ปรึกษาทีมทนายของสำนักงานกฎหมายยอดทิพย์ธรรม โทร 081-327-8551 | LINE @995iqtpa หรือนัดหมายปรึกษาที่นี่

ข้อกฎหมายที่เกี่ยวข้อง

• พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 37 (4) — หน้าที่แจ้งเหตุการละเมิดข้อมูลส่วนบุคคลแก่สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลโดยไม่ชักช้าภายใน 72 ชั่วโมงนับแต่ทราบเหตุเท่าที่จะสามารถกระทำได้ และหากมีความเสี่ยงสูงต่อสิทธิและเสรีภาพของบุคคล ต้องแจ้งเจ้าของข้อมูลพร้อมแนวทางเยียวยาด้วย
• ประกาศ กคส. เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565 — เผยแพร่ 15 ธันวาคม 2565 ออกตามมาตรา 16 (4) และมาตรา 37 (4)
• ประกาศฯ · นิยาม — การละเมิดข้อมูลส่วนบุคคลหมายถึงการละเมิดมาตรการรักษาความมั่นคงปลอดภัยที่ทำให้เกิดการสูญหาย เข้าถึง ใช้ เปลี่ยนแปลง แก้ไข หรือเปิดเผยข้อมูลโดยปราศจากอำนาจหรือโดยมิชอบ ไม่ว่าเกิดจากเจตนา ความจงใจ ความประมาทเลินเล่อ ภัยคุกคามทางไซเบอร์ ข้อผิดพลาด อุบัติเหตุ หรือเหตุอื่นใด
• ประกาศฯ · ขั้นตอนเมื่อทราบว่ามีหรือน่าจะมีเหตุ — ประเมินความน่าเชื่อถือของข้อมูลและตรวจสอบข้อเท็จจริง · ป้องกัน ระงับ แก้ไขโดยทันทีเท่าที่ทำได้เมื่อพบว่าเสี่ยงสูง · แจ้งเหตุเมื่อมีเหตุอันควรเชื่อว่ามีการละเมิดจริง · แจ้งเจ้าของข้อมูลเมื่อเสี่ยงสูง · และดำเนินมาตรการป้องกันไม่ให้เกิดซ้ำพร้อมทบทวนมาตรการ
• ประกาศฯ · ปัจจัยประเมินความเสี่ยง 8 ข้อ — ลักษณะและประเภทของการละเมิด · ลักษณะและประเภทของข้อมูล · ปริมาณข้อมูลและจำนวนรายการ · ลักษณะและสถานะของเจ้าของข้อมูลรวมถึงกลุ่มเปราะบาง · ความร้ายแรงของผลกระทบและประสิทธิภาพของมาตรการเยียวยา · ผลกระทบในวงกว้าง · ลักษณะระบบเก็บข้อมูลและมาตรการที่มีอยู่ · สถานะทางกฎหมายและขนาดของผู้ควบคุมข้อมูล
• ประกาศฯ · รายละเอียดที่ต้องแจ้งเจ้าของข้อมูล — ลักษณะของการละเมิดโดยสังเขป · ช่องทางติดต่อเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคลหรือผู้ประสานงาน · ผลกระทบที่อาจเกิดขึ้น · แนวทางเยียวยาและข้อแนะนำมาตรการที่เจ้าของข้อมูลดำเนินการได้เอง
• มาตรา 37 (1) — หน้าที่จัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม ซึ่งมักถูกวินิจฉัยเป็นอีกฐานหนึ่งแยกจากหน้าที่แจ้งเหตุ

คำถามที่พบบ่อย

เพิ่งรู้ว่าอาจมีข้อมูลรั่ว แต่ยังไม่แน่ใจ ต้องเริ่มนับ 72 ชั่วโมงเลยไหม

ประกาศฉบับปี 2565 พูดถึงกรณีที่ได้รับแจ้งว่า "มีหรือน่าจะมี" เหตุละเมิด ซึ่งหมายความว่าหน้าที่ตรวจสอบข้อเท็จจริงและประเมินความเสี่ยงเริ่มตั้งแต่ตอนนั้น ไม่ใช่รอจนยืนยันได้ครบถ้วน แนวทางที่ปลอดภัยกว่าคือบันทึกวันเวลาที่ได้รับแจ้งไว้ทันที เริ่มตรวจสอบและระงับความเสียหายควบคู่กันไป แล้วให้ทนายประเมินจุดเริ่มนับที่ถูกต้องเป็นรายกรณี

ระหว่าง 6 ชั่วโมงแรก ควรบอกลูกค้าหรือพนักงานที่ได้รับผลกระทบหรือยัง

โดยหลักยังไม่ควรสื่อสารออกไปก่อนจะทราบข้อเท็จจริงพอสมควร เพราะประกาศกำหนดรายละเอียดที่ต้องแจ้งเจ้าของข้อมูลไว้ ทั้งลักษณะของการละเมิด ช่องทางติดต่อผู้รับผิดชอบ ผลกระทบที่อาจเกิดขึ้น และแนวทางเยียวยา ซึ่งต้องอาศัยข้อเท็จจริงที่ตรวจสอบแล้ว การรีบสื่อสารก่อนตั้งหลักมักทำให้ต้องแก้คำพูดภายหลัง และคำแถลงแรกอาจกลายเป็นหลักฐานที่ขัดกับข้อเท็จจริงที่พบทีหลัง

ประเมินแล้วว่าไม่มีความเสี่ยง ไม่ต้องแจ้ง ต้องทำอะไรต่อไหม

ต้องบันทึกการประเมินและเหตุผลไว้ให้ใช้ยันได้ เพราะการอ้างว่าประเมินแล้วโดยไม่มีเอกสารรองรับ มักถูกมองว่าไม่ได้ประเมินจริง เอกสารที่ควรมีคือการประเมินที่อ้างอิงปัจจัยตามประกาศ ข้อสรุปว่าเหตุใดจึงเห็นว่าไม่มีความเสี่ยงต่อสิทธิและเสรีภาพของบุคคล และชื่อผู้ตัดสินใจพร้อมวันเวลา รวมทั้งควรดำเนินมาตรการป้องกันไม่ให้เกิดซ้ำและทบทวนมาตรการที่มีอยู่ด้วย

ใครควรเป็นคนจดบันทึกในช่วงนี้

ควรกำหนดคนหนึ่งคนให้ทำหน้าที่จดอย่างเดียวโดยไม่ต้องทำงานอื่น และควรเป็นผู้ที่ไม่มีส่วนได้เสียในเหตุนั้น เพราะบันทึกที่จัดทำโดยผู้ที่ถูกกล่าวหาว่าเป็นต้นเหตุ มักถูกตั้งคำถามเรื่องความน่าเชื่อถือ สิ่งที่ต้องจดคือเวลาที่ทราบเหตุ สิ่งที่ทำในแต่ละช่วง ชื่อผู้ตัดสินใจ และเหตุผลของการตัดสินใจแต่ละครั้ง

อ่านต่อ: ข้อมูลรั่วไหลและการแจ้งเหตุ 72 ชั่วโมง

• ข้อมูลรั่วไหล ต้องแจ้งใครภายใน 72 ชั่วโมง? คู่มือรับมือ PDPA สำหรับองค์กร
• บัญชีแอดมินถูกยึด ต้องตรวจขอบเขตข้อมูลรั่วอย่างไร
• ส่งอีเมลผิดคนหรือแนบไฟล์ผิด ถือเป็นเหตุละเมิดข้อมูลที่ต้องแจ้งหรือไม่
• ลิงก์แชร์ไฟล์เปิดสาธารณะ ไม่พบดาวน์โหลดต้องทำอย่างไร
• เหตุข้อมูลรั่วแบบไหนที่ไม่ต้องแจ้ง และต้องบันทึกเหตุผลอย่างไรให้ใช้ยันได้
• รายงานปิดเหตุข้อมูลรั่ว กู้ระบบได้แล้วต้องตรวจอะไรต่อ
• ต้องแจ้งเจ้าของข้อมูลเมื่อใด และเขียนคำแจ้งอย่างไรไม่ให้กลายเป็นหลักฐานมัดตัว

ดูบทความ PDPA ทั้งหมดแยกตามสถานการณ์

ผู้เขียน นายเอกราช ทิพย์แมม คดีครอบครัว มรดก หนี้สิน และ PDPA

สาขาที่เชี่ยวชาญ: ครอบครัว · มรดกและพินัยกรรม · หนี้สินและบังคับคดี · คุ้มครองข้อมูลส่วนบุคคล (PDPA)

ดูประวัติและช่องทางติดต่อผู้เขียน →

บทความนี้เป็นความรู้กฎหมายทั่วไปเพื่อความเข้าใจเบื้องต้น ไม่ใช่คำปรึกษาทางกฎหมายเฉพาะคดี ผลทางกฎหมายขึ้นอยู่กับข้อเท็จจริง เอกสาร และพยานหลักฐานของแต่ละกรณี ควรปรึกษาทนายความเพื่อประเมินเรื่องของท่านโดยเฉพาะ