รายงานปิดเหตุข้อมูลรั่ว กู้ระบบได้แล้วต้องตรวจอะไรต่อ

สรุปประเด็นสำคัญ
รายงานปิดเหตุข้อมูลรั่วควรยืนยันขอบเขตที่ตรวจ มาตรการหยุดเหตุ และผลทดสอบฟื้นระบบ พร้อมแยกสถานะการแจ้งและงานที่ยังค้าง การปิดเหตุภายในไม่ใช่การรับรองว่าความรับผิดตามกฎหมายจบแล้ว และต้องมีเกณฑ์เปิดตรวจใหม่เมื่อพบข้อเท็จจริงที่เปลี่ยนความเสี่ยงหรือขอบเขตเดิม
รายงานปิดเหตุข้อมูลรั่วต้องอธิบายได้ว่าเหตุหยุดอย่างไร ระบบกลับมาใช้งานได้ด้วยเงื่อนไขใด และงานคุ้มครองเจ้าของข้อมูลยังเหลืออะไร การกู้ระบบสำเร็จเป็นหลักฐานด้านหนึ่ง แต่ยังต้องตรวจการเข้าถึงที่ค้างอยู่ การแจ้งเหตุ และมาตรการป้องกันเหตุซ้ำก่อนอนุมัติปิดงาน
รายงานปิดเหตุข้อมูลรั่วควรยืนยันอะไรบ้าง?
ควรยืนยันขอบเขตเหตุ มาตรการหยุดเหตุ ผลทดสอบการฟื้นระบบ และสถานะการแจ้งผู้เกี่ยวข้อง พร้อมแยกงานที่ยังติดตามต่อ การปิดเหตุเป็นการตัดสินใจบริหารภายในที่ต้องมีหลักฐาน ไม่ใช่ใบรับรองว่าความรับผิดตามกฎหมายสิ้นสุด หรือไม่มีหน้าที่ต้องดำเนินการอีกเมื่อพบข้อมูลใหม่
พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 37 (1) กำหนดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม และทบทวนเมื่อจำเป็นหรือเทคโนโลยีเปลี่ยนแปลงเพื่อให้มีประสิทธิภาพ ส่วนมาตรา 37 (4) กำหนดหน้าที่แจ้งเหตุตามความเสี่ยง การเปิดระบบได้จึงไม่ตอบว่าหน้าที่แจ้งเหตุครบหรือว่ามาตรการที่ใช้เหมาะสมแล้ว
ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565 ข้อ 5 (5) กำหนดให้ใช้มาตรการที่จำเป็นและเหมาะสมเพื่อระงับ ตอบสนอง แก้ไข หรือฟื้นฟู และป้องกันหรือลดผลกระทบจากเหตุลักษณะเดียวกันในอนาคต รวมถึงทบทวนมาตรการความปลอดภัย รายงานปิดเหตุจึงควรเชื่อมผลการตรวจเข้ากับงานปรับปรุงที่วัดผลได้
คำว่า “ปิดเหตุ” ควรนิยามในแผนขององค์กร เช่น หยุดการเข้าถึงโดยมิชอบแล้ว กู้ข้อมูลตามเกณฑ์ที่อนุมัติ และมอบหมายงานค้างชัดเจน ไม่ควรใช้คำนี้แทนการยืนยันว่าไม่เคยมีข้อมูลถูกนำออก หากหลักฐานยังไม่เพียงพอ หรือถือว่าเป็นผลรับรองจากสำนักงานเพียงเพราะรายงานถูกส่งสำเร็จ
ตัวอย่างสมมติ: บริษัทกู้ระบบลูกค้าจากสำรองได้ แต่ยังไม่ตรวจว่าบัญชีที่ถูกยึดมีสิทธิเข้าถึงคลังไฟล์อีกแห่งหรือไม่ ทีมงานอาจรับรองการกู้บริการส่วนที่ทดสอบแล้ว แต่ยังไม่ควรสรุปขอบเขตเหตุทั้งหมดจบ เพราะต้องตรวจสิทธิและบันทึกในคลังไฟล์นั้น รวมถึงประเมินผลต่อเจ้าของข้อมูลเพิ่ม
ตรวจเงื่อนไขจาก ประกาศการแจ้งเหตุละเมิดข้อมูล พ.ศ. 2565 และอ่าน แนวทางตอบสนองเหตุข้อมูลรั่ว เพื่อเชื่อมการปิดงานกับการดำเนินการตั้งแต่เริ่มเหตุ
ถ้าระบบใช้ได้แต่ยังมีงานค้าง ควรปิดแบบไหน?
ถ้าบริการกลับมาแต่ยังตรวจขอบเขตไม่ครบ ให้ระบุว่าฟื้นบริการส่วนใดแล้วและงานตรวจใดยังดำเนินต่อ การอนุมัติเปิดบริการอาจมีเงื่อนไขจำกัดสิทธิหรือเพิ่มการเฝ้าระวัง โดยต้องให้ผู้มีอำนาจรับทราบข้อจำกัด ไม่ใช้สถานะสีเขียวของระบบแทนผลประเมินทุกด้าน
ถ้าคู่ค้ายังไม่ยืนยันผล ให้เปิดรายการติดตามแยก ระบุหลักฐานที่ต้องการและผู้ประสานงาน หากงานนั้นเป็นเงื่อนไขสำคัญของการหยุดเหตุ ไม่ควรทำเครื่องหมายเสร็จเพียงเพราะส่งอีเมลขอไปแล้ว
ถ้าแจ้งเจ้าของข้อมูลบางรายไม่สำเร็จ ให้ตรวจช่องทางและความจำเป็นของการดำเนินการเพิ่มเติมตามกฎหมาย อย่านับอีเมลตีกลับเป็นการเข้าถึงผู้รับสำเร็จ และต้องระวังไม่เผยแพร่รายชื่อผู้ได้รับผลกระทบเพื่อแก้ปัญหาการติดต่อจนเกิดความเสียหายเพิ่ม
ถ้าพบหลักฐานใหม่หลังปิด ให้ใช้เกณฑ์เปิดเหตุทบทวนที่กำหนดไว้ เช่น พบการเข้าถึงต่อเนื่องหรือข้อมูลประเภทใหม่ การเปิดตรวจซ้ำไม่ใช่การยอมรับว่าทุกมาตรการเดิมไร้ผล แต่เป็นการปรับการตัดสินใจตามข้อเท็จจริงที่เพิ่มขึ้น
เลนส์ทนายยอดทิพย์ธรรม: ระบบพร้อมใช้กับความเสี่ยงสิ้นสุดต่างกัน
คนมักเข้าใจว่า: เมื่อผู้ใช้เข้าสู่ระบบได้และไม่พบแจ้งเตือนใหม่ ก็ถือว่าปลอดภัยและปิดเหตุได้ แต่ระบบอาจไม่มีบันทึกเพียงพอ หรือผู้ไม่เกี่ยวข้องอาจยังมีสิทธิผ่านบัญชีหรือช่องทางอีกชุดหนึ่ง
กฎหมายมองว่า: มาตรการต้องเหมาะกับความเสี่ยงและมีการตอบสนองผลกระทบต่อบุคคล ไม่ได้ประเมินเฉพาะความพร้อมใช้งานของธุรกิจ การแจ้งเหตุ การช่วยผู้ได้รับผลกระทบ และการป้องกันเหตุซ้ำจึงควรได้รับการตรวจต่างหากจากการทดสอบว่าระบบทำธุรกรรมได้
จุดเสี่ยงจริง: รายงานปิดเหตุเขียนว่าไม่มีข้อมูลรั่วโดยอาศัยคำว่าไม่พบในบันทึกที่ไม่ครบ ควรเขียนให้ตรงว่าตรวจแหล่งใด ช่วงเวลาใด และมีข้อจำกัดอะไร หากยังไม่อาจสรุป ให้กำหนดการติดตามและผู้ตัดสินใจแทนการเติมคำรับรองเด็ดขาด
มองสองฝั่ง: ทีมระบบกับผู้ได้รับผลกระทบคาดหวังอะไร?
| ประเด็น | องค์กรและทีมระบบ | เจ้าของข้อมูล |
|---|---|---|
| หน้าที่และสิทธิ | ฟื้นบริการอย่างเหมาะสมและจัดการหน้าที่คุ้มครองข้อมูล | ได้รับคำแนะนำที่ช่วยลดผลกระทบและช่องทางติดตาม |
| ความเสี่ยง | เปิดระบบโดยยังมีช่องทางเข้าถึงที่ไม่ควรเหลือ | ข้อมูลที่ถูกนำออกอาจยังถูกใช้แม้ระบบต้นทางแก้แล้ว |
| ควรทำตอนนี้ | ทดสอบผลและแยกงานค้างก่อนลงนามปิด | เก็บการแจ้งและหลักฐานผลกระทบที่พบภายหลัง |
| ไม่ควรทำ | รับรองว่าทุกความเสี่ยงเป็นศูนย์โดยไม่มีหลักฐาน | เชื่อข้อความขอข้อมูลเพิ่มจากแหล่งที่ยังไม่ยืนยัน |
รายงานที่ดีควรตอบความต้องการทั้งสองด้าน คือให้ธุรกิจตัดสินใจเปิดใช้งานได้ และให้ผู้ได้รับผลกระทบทราบว่ายังต้องป้องกันตนเองเรื่องใด ไม่ควรใช้ภาษาทางเทคนิคกลบงานเยียวยาที่ค้างอยู่
ควรเฝ้าระวังกี่วันก่อนปิดเหตุ?
ไม่มีกำหนดจำนวนวันเดียวที่ใช้รับรองว่าทุกเหตุข้อมูลรั่วปิดได้อย่างปลอดภัย ต้องกำหนดตามลักษณะเหตุ ความเสี่ยง ช่วงเวลาที่หลักฐานครอบคลุม และข้อกำหนดของกิจการหรือคำสั่งที่เกี่ยวข้อง โดยให้ผู้รับผิดชอบอนุมัติเกณฑ์ก่อนใช้
เช่น องค์กรอาจเสนอเฝ้าระวังเข้มข้นเจ็ดวันหลังเปลี่ยนสิทธิเป็นแผนภายใน แต่ต้องอธิบายว่าช่วงเวลานั้นตรวจอะไรได้และไม่ได้ ตัวเลขเจ็ดวันไม่ใช่ระยะปลอดความรับผิดตาม PDPA และการไม่พบเหตุในช่วงดังกล่าวไม่ยืนยันว่าข้อมูลที่เคยหลุดออกไปถูกลบทั้งหมด
กำหนดแจ้งเหตุ 72 ชั่วโมงตามมาตรา 37 (4) เป็นอีกเรื่องหนึ่ง ไม่ต้องรอครบระยะเฝ้าระวังจึงแจ้ง หลังปิดงานภายใน หากมีคำขอข้อมูลหรือคำสั่งจากหน่วยงานยังต้องดำเนินการตามกำหนดจริงและเก็บหลักฐานตอบกลับ
งบหลังปิดเหตุควรรวมงานอะไร?
แยกต้นทุนกู้ระบบที่เกิดแล้วออกจากงบทดสอบซ้ำ เฝ้าระวัง และปรับมาตรการระยะต่อไป สูตรวางงบงานค้างคือ ผลรวมค่าใช้จ่ายของรายการที่ยังต้องทำตามเจ้าของงาน โดยต้องหลีกเลี่ยงนับงานเดียวซ้ำในงบของหลายฝ่าย
ตัวอย่างสมมติ: ค่าทดสอบซ้ำ 12,000 บาท ค่าเฝ้าระวังเพิ่มเติม 8,000 บาท และค่าทบทวนขั้นตอนกับอบรมเฉพาะทีม 5,000 บาท รวม 25,000 บาท หากค่ากู้ระบบที่จ่ายไปแล้ว 40,000 บาท ต้นทุนสองส่วนรวม 65,000 บาท แต่ยอดงบที่ยังต้องอนุมัติในตัวอย่างคือ 25,000 บาท ไม่ใช่ 65,000 บาทอีกครั้ง
ยอดดังกล่าวเป็นตัวอย่างจัดงบ ไม่ใช่ค่าบริการจริงหรือค่าสินไหมที่เจ้าของข้อมูลมีสิทธิได้รับ หากจะเรียกค่าใช้จ่ายจากคู่ค้า ต้องตรวจฐานสัญญา เหตุผิด และหลักฐานความเสียหาย ไม่ถือว่ารายงานปิดเหตุที่อนุมัติภายในผูกพันคู่ค้าให้จ่ายทุกยอด
รายงานปิดเหตุควรแนบหลักฐานอะไร?
- ลำดับเหตุและเวลาสำคัญ ตั้งแต่พบเหตุจนถึงผลทดสอบล่าสุด
- ขอบเขตระบบและประเภทข้อมูลที่ตรวจ พร้อมข้อจำกัดของการตรวจ
- มาตรการหยุดเหตุและผลยืนยัน เช่น การถอนสิทธิหรือปิดช่องทางที่เกี่ยวข้อง
- ผลกู้คืนและทดสอบความถูกต้องของข้อมูลที่จำเป็นต่อการใช้งาน
- สถานะการแจ้งสำนักงานและเจ้าของข้อมูล พร้อมหลักฐานรับหรือส่ง
- รายการงานค้าง เจ้าของงาน กำหนดติดตาม และเกณฑ์เปิดตรวจใหม่
ผู้ตรวจควรแยกคนที่ดำเนินงานกับคนที่ตรวจรับตามทรัพยากรและความเสี่ยงขององค์กร เพื่อไม่ให้ใช้คำยืนยันของผู้แก้ไขเป็นหลักฐานเพียงอย่างเดียว หากต้องจ้างผู้เชี่ยวชาญภายนอก ให้ระบุขอบเขตผลตรวจ ไม่ขยายข้อสรุปไปนอกระบบหรือช่วงเวลาที่ตรวจ
เก็บหลักฐานต้นฉบับตามแผนที่มีฐานและระยะเวลาเหมาะสม โดยจำกัดสิทธิและรักษาความครบถ้วน อ่าน แนวทางรักษาหลักฐานหลังถูกโจมตี ประกอบก่อนลบเครื่องทดสอบหรือข้อมูลสำเนาที่อาจจำเป็นต่อการพิสูจน์เหตุ
สัญญา คดีแพ่ง และกฎหมายเฉพาะยังเกี่ยวข้องอย่างไร?
สัญญาคู่ค้า: การตรวจรับบริการกู้ระบบอาจมีผลต่อสิทธิเรียกร้องตามสัญญา จึงควรแยกการรับมอบงานเฉพาะส่วนจากการสละสิทธิทั้งหมด ข้อความส่งมอบและหน้าที่ช่วยตรวจเหตุควรตรวจผ่าน งานสัญญาธุรกิจ ให้ตรงขอบเขตจริง
ความเสียหายทางแพ่ง: เจ้าของข้อมูลอาจเพิ่งพบผลกระทบภายหลังระบบกลับมาใช้ได้ การปิดเหตุภายในไม่ใช่คำตอบว่าไม่มีความเสียหาย หากมีข้อเรียกร้อง ต้องตรวจเหตุและหลักฐานแยกใน งานข้อพิพาททางแพ่ง
กฎหมายเฉพาะกิจการ: ระบบที่เกี่ยวข้องกับบริการที่มีผู้กำกับอาจมีเงื่อนไขรายงานหรือฟื้นบริการเพิ่มเติม ต้องตรวจหน้าที่นั้นโดยเฉพาะ ไม่ใช้คำว่าปิดเหตุ PDPA เป็นหลักฐานว่าได้ปฏิบัติตามกฎหมายทุกด้านแล้ว
ทางไปต่อ: อนุมัติปิดเหตุพร้อมงานติดตามอย่างไร?
- ตรวจเกณฑ์ปิดเหตุและขอบเขตที่รายงานจะรับรอง
- ทดสอบมาตรการหยุดเหตุและการกู้คืนโดยมีหลักฐาน
- ทบทวนการแจ้งและความเสี่ยงต่อเจ้าของข้อมูล
- มอบหมายงานค้างพร้อมกำหนดติดตามและงบที่จำเป็น
- ให้ผู้มีอำนาจอนุมัติ พร้อมระบุเหตุที่จะต้องเปิดตรวจใหม่
| ทางเลือก | ใช้เมื่อ | หลักฐานสำคัญ |
|---|---|---|
| ปิดเหตุและติดตามการปรับปรุง | หยุดเหตุได้และเกณฑ์ที่กำหนดครบ | ผลทดสอบและทะเบียนงานป้องกันซ้ำ |
| ฟื้นบริการแบบมีเงื่อนไข | ธุรกิจต้องใช้ระบบแต่ยังมีข้อจำกัดที่ควบคุมได้ | เงื่อนไขสิทธิ เฝ้าระวัง และผู้อนุมัติ |
| ตรวจเหตุเพิ่มเติม | ขอบเขตหรือการหยุดเหตุยังไม่แน่นอน | ข้อสงสัย แผนตรวจ และมาตรการชั่วคราว |
ควรตรวจร่วมกับผู้เชี่ยวชาญเมื่อบันทึกไม่ครบ มีข้อมูลอ่อนไหว คู่ค้ายังไม่ยืนยัน หรือรายงานกำลังรับรองว่าไม่มีข้อมูลถูกนำออก หากต้องการตรวจรายงานและงานค้าง สามารถดู งานรับมือเหตุข้อมูลรั่ว ใน บริการกฎหมาย PDPA และ ติดต่อยอดทิพย์ธรรม พร้อมรายงานเทคนิคและสถานะล่าสุด
ข้อกฎหมายที่เกี่ยวข้อง
- พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 37 (1): มาตรการรักษาความมั่นคงปลอดภัยและการทบทวน
- พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 37 (4): หน้าที่แจ้งเหตุตามระดับความเสี่ยง
- ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565 ข้อ 5 (5) และข้อ 10–12: ฟื้นฟู ป้องกันเหตุซ้ำ และประเมินผลกระทบต่อบุคคล
ตรวจสอบข้อกฎหมายเมื่อ ตุลาคม 2569
คำถามที่พบบ่อย
ผลทดสอบจากผู้รับจ้างใช้ปิดเหตุได้ทันทีไหม?
ไม่มีแจ้งเตือนใหม่แปลว่าผู้โจมตีออกไปแล้วไหม?
งานค้างหลังปิดเหตุควรให้ใครรับผิดชอบ?
ต้องแจ้งลูกค้าว่าปิดเหตุแล้วทุกครั้งหรือไม่?
สาขาที่เชี่ยวชาญ: ครอบครัว · มรดกและพินัยกรรม · หนี้สินและบังคับคดี
ดูประวัติทีมทนายความ →บทความนี้เป็นความรู้กฎหมายทั่วไปเพื่อความเข้าใจเบื้องต้น ไม่ใช่คำปรึกษาทางกฎหมายเฉพาะคดี ผลทางกฎหมายขึ้นอยู่กับข้อเท็จจริง เอกสาร และพยานหลักฐานของแต่ละกรณี ควรปรึกษาทนายความเพื่อประเมินเรื่องของท่านโดยเฉพาะ
บทความที่เกี่ยวข้อง
PDPA คุ้มครองข้อมูล
AI Agent เข้าถึงอีเมลและ CRM ต้องจำกัดอำนาจอย่างไร
AI Agent เข้าถึงอีเมลและ CRM ควรแยกสิทธิอ่าน ส่ง แก้ และลบ ตรวจจุดอนุมัติ อายุสิทธิ และหลักฐานผลจริง ก่อนให้ระบบทำงานแทนพนักงาน
นายเอกราช ทิพย์แมม
·อ่าน 7 นาที
PDPA คุ้มครองข้อมูล
AI สร้างข้อมูลผิดเกี่ยวกับลูกค้า บริษัทต้องตามแก้อย่างไร
AI สร้างข้อมูลผิดแล้วถูกส่งเข้า CRM ต้องตรวจต้นทางและตามแก้จุดใช้จริง ดูสิทธิแก้ไข การระงับระหว่างตรวจ และหลักฐานตอบคำร้องของลูกค้า
นายเอกราช ทิพย์แมม
·อ่าน 7 นาที
PDPA คุ้มครองข้อมูล
AI ค้นเอกสารภายใน ต้องป้องกันข้อมูลข้ามสิทธิอย่างไร
AI ค้นเอกสารภายในอาจตอบข้อมูลที่ผู้ถามไม่มีสิทธิ ดูวิธีตรวจแหล่งข้อมูล ดัชนี ประวัติ และผลทดสอบก่อนเปิดให้พนักงานค้นด้วยบัญชีจริง
นายเอกราช ทิพย์แมม
·อ่าน 7 นาที
ปรึกษาทีมทนาย PDPAของเรา
เราพร้อมรับฟังและประเมินแนวทางที่เหมาะกับกรณีของท่าน ทุกเรื่องเป็นความลับ